pip/warehouse feature idea: "help needed"
Guido mentioned in his PyCon keynote this morning that we don't currently have a great way for package authors to ask for help from their user base. It occurred to me that it could be useful to have a "Help needed" feature on PyPI (after the Warehouse migration) where package maintainers could register requests for assistance, such as: * looking for new maintainers * requests for help with Python 3 support * links to specific issues a maintainer would like help with * links to donation pages (including links to Patreon, Gratipay, etc) * links to crowdfunding campaigns for specific new features * links to CVs/LinkedIn if folks are looking for work Given a requirements.txt file, pip could then gain a "help-needed" command that pulled the "help needed" entries for the named projects. The general idea would be to provide a direct channel from project maintainers that may need help to their users who may be in a position to provide that help. It wouldn't need to be too complicated, just a Markdown field that maintainers could edit. In some cases, software is backed by folks that already have a sustainable support model. For these it could be nice if the Markdown field could be used to say "Help not needed", and give credit to the people or orgs supporting them. It's not something we can do anything about until after the Warehouse migration, but I figured I'd mention it while I was thinking about it :) Cheers, Nick.
Is the package index really the best place to put this? This is a very social-networking feature for the authoritative repository of just about all the third party module, and it feels like either it could corrupt the 'sanctity' of the repository (in the absolute worst case), or simply be totally ineffective because we all only see the cheese shop through pip and twin (in the best case). I am not saying the PSF shouldn't do this, but is pypi REALLY the best part of python.org to put it? On 4/11/2015 10:46, Nick Coghlan wrote:
Guido mentioned in his PyCon keynote this morning that we don't currently have a great way for package authors to ask for help from their user base.
It occurred to me that it could be useful to have a "Help needed" feature on PyPI (after the Warehouse migration) where package maintainers could register requests for assistance, such as:
* looking for new maintainers * requests for help with Python 3 support * links to specific issues a maintainer would like help with * links to donation pages (including links to Patreon, Gratipay, etc) * links to crowdfunding campaigns for specific new features * links to CVs/LinkedIn if folks are looking for work
Given a requirements.txt file, pip could then gain a "help-needed" command that pulled the "help needed" entries for the named projects.
The general idea would be to provide a direct channel from project maintainers that may need help to their users who may be in a position to provide that help. It wouldn't need to be too complicated, just a Markdown field that maintainers could edit.
In some cases, software is backed by folks that already have a sustainable support model. For these it could be nice if the Markdown field could be used to say "Help not needed", and give credit to the people or orgs supporting them.
It's not something we can do anything about until after the Warehouse migration, but I figured I'd mention it while I was thinking about it :)
Cheers, Nick.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Sat, Apr 11, 2015 at 9:53 AM, Alexander Walters <tritium-list@sdamon.com> wrote:
Is the package index really the best place to put this? This is a very social-networking feature for the authoritative repository of just about all the third party module, and it feels like either it could corrupt the 'sanctity' of the repository (in the absolute worst case), or simply be totally ineffective because we all only see the cheese shop through pip and twin (in the best case).
I am not saying the PSF shouldn't do this, but is pypi REALLY the best part of python.org to put it?
There would need to be an additional application parsing egg/wheel metadata onupload.
On 4/11/2015 10:46, Nick Coghlan wrote:
Guido mentioned in his PyCon keynote this morning that we don't currently have a great way for package authors to ask for help from their user base.
It occurred to me that it could be useful to have a "Help needed" feature on PyPI (after the Warehouse migration) where package maintainers could register requests for assistance, such as:
* looking for new maintainers * requests for help with Python 3 support * links to specific issues a maintainer would like help with * links to donation pages (including links to Patreon, Gratipay, etc) * links to crowdfunding campaigns for specific new features * links to CVs/LinkedIn if folks are looking for work
Given a requirements.txt file, pip could then gain a "help-needed" command that pulled the "help needed" entries for the named projects.
The general idea would be to provide a direct channel from project maintainers that may need help to their users who may be in a position to provide that help. It wouldn't need to be too complicated, just a Markdown field that maintainers could edit.
In some cases, software is backed by folks that already have a sustainable support model. For these it could be nice if the Markdown field could be used to say "Help not needed", and give credit to the people or orgs supporting them.
It's not something we can do anything about until after the Warehouse migration, but I figured I'd mention it while I was thinking about it :)
Cheers, Nick.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.orghttps://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
-- Wes Turner https://westurner.org https://wrdrd.com/docs/consulting/knowledge-engineering
On 11 Apr 2015 12:22, "Alexander Walters" <tritium-list@sdamon.com> wrote:
Is the package index really the best place to put this? This is a very
or simply be totally ineffective because we all only see the cheese shop
I am not saying the PSF shouldn't do this, but is pypi REALLY the best
social-networking feature for the authoritative repository of just about all the third party module, and it feels like either it could corrupt the 'sanctity' of the repository (in the absolute worst case) If you're concerned that this feature might weaken the comforting illusion that PyPI published software is contributed and maintained by faceless automatons rather than living, breathing human beings, then yes, encouraging folks to think more about where the software they use is coming from would be a large part of the point of adding such a feature. through pip and twin (in the best case). Hence the idea of making the feature accessible through the command line clients, not just the web service. part of python.org to put it? I personally believe so, yes - sustaining software over the long term is expensive in people's time, but it's often something we take for granted. The specific example Guido brought up in his keynote was the challenge of communicating a project's openness to Python 3 porting assistance. In the current user experience, if a project we use stops getting updated, resentment at the lack of updates is a more likely reaction for most of us than concern for whether or not the maintainer is OK. Regards, Nick.
On 4/12/2015 21:08, Nick Coghlan wrote:
Hence the idea of making the feature accessible through the command line clients, not just the web service.
For the love of... Can we get packaging fixed before we start jamming crap onto the tools? Enough already. No. Just No. Never. Stop. Just stop. No. As a user of these things, just stop right there.
I personally believe so, yes - sustaining software over the long term is expensive in people's time, but it's often something we take for granted. The specific example Guido brought up in his keynote was the challenge of communicating a project's openness to Python 3 porting assistance.
In the current user experience, if a project we use stops getting updated, resentment at the lack of updates is a more likely reaction for most of us than concern for whether or not the maintainer is OK.
Again, great idea. Does not need to be on the index. Does not even need to be on the same infrastructure as the index. I can think of at least four other places on the web where it will be better suited. If the PSF wants to take charge of that, then super. Put it next to the job board. But if you really want to solve the problem through the index, just make the link to SCM repos mandatory, and thats all you have to, and even should, do.
Nick Coghlan <ncoghlan@gmail.com> writes:
On 11 Apr 2015 12:22, "Alexander Walters" <tritium-list@sdamon.com> wrote:
Is the package index really the best place to put this? This is a very social-networking feature for the authoritative repository of just about all the third party module, and it feels like either it could corrupt the 'sanctity' of the repository (in the absolute worst case)
If you're concerned that this feature might weaken the comforting illusion that PyPI published software is contributed and maintained by faceless automatons rather than living, breathing human beings, then yes, encouraging folks to think more about where the software they use is coming from would be a large part of the point of adding such a feature.
I can't speak for Alexander, but I'm also −1 to have this *on PyPI*. I'm all for such features existing. What is at issue is whether PyPI is the place to put them. We have been gradually improving the function of PyPI as an authoritative *index* of packages; that's possible because it is a repository of uncontroversial facts, not opinions (i.e. “what is the packaging metadata of this distribution”, “where is its documentation”, “where is its VCS”, etc.).
I am not saying the PSF shouldn't do this, but is pypi REALLY the best part of python.org to put it?
I personally believe so, yes - sustaining software over the long term is expensive in people's time, but it's often something we take for granted. The specific example Guido brought up in his keynote was the challenge of communicating a project's openness to Python 3 porting assistance.
The people doing the work of maintaining PyPI have said many times in recent years that there just isn't enough person-power to add a whole bunch of features that have been requested. Why would we think moderating a social-networking rating, opinion, discussion, or other non-factual database is something reasonable to ask of the PyPI maintainers? Conversely, if we are under the impression that adding ratings, feedback, reviews, discussion, and other features to PyPI is *not* going to be a massive increase in workload for the maintainers, I think that's a foolish delusion which will be quite costly to the reputation PyPI has recently gained through hard effort to clarify its role. By all means, set up a well-maintained social ecosystem around Python packages. But not on PyPI itself: The Python Package Index is feasible in part because it has a clear and simple job, though, and that's not it. -- \ “If you can't hear me sometimes, it's because I'm in | `\ parentheses.” —Steven Wright | _o__) | Ben Finney
On Apr 13, 2015, at 8:57 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
Nick Coghlan <ncoghlan@gmail.com> writes:
On 11 Apr 2015 12:22, "Alexander Walters" <tritium-list@sdamon.com> wrote:
Is the package index really the best place to put this? This is a very social-networking feature for the authoritative repository of just about all the third party module, and it feels like either it could corrupt the 'sanctity' of the repository (in the absolute worst case)
If you're concerned that this feature might weaken the comforting illusion that PyPI published software is contributed and maintained by faceless automatons rather than living, breathing human beings, then yes, encouraging folks to think more about where the software they use is coming from would be a large part of the point of adding such a feature.
I can't speak for Alexander, but I'm also −1 to have this *on PyPI*.
I'm all for such features existing. What is at issue is whether PyPI is the place to put them.
We have been gradually improving the function of PyPI as an authoritative *index* of packages; that's possible because it is a repository of uncontroversial facts, not opinions (i.e. “what is the packaging metadata of this distribution”, “where is its documentation”, “where is its VCS”, etc.).
I am not saying the PSF shouldn't do this, but is pypi REALLY the best part of python.org to put it?
I personally believe so, yes - sustaining software over the long term is expensive in people's time, but it's often something we take for granted. The specific example Guido brought up in his keynote was the challenge of communicating a project's openness to Python 3 porting assistance.
The people doing the work of maintaining PyPI have said many times in recent years that there just isn't enough person-power to add a whole bunch of features that have been requested. Why would we think moderating a social-networking rating, opinion, discussion, or other non-factual database is something reasonable to ask of the PyPI maintainers?
Conversely, if we are under the impression that adding ratings, feedback, reviews, discussion, and other features to PyPI is *not* going to be a massive increase in workload for the maintainers, I think that's a foolish delusion which will be quite costly to the reputation PyPI has recently gained through hard effort to clarify its role.
By all means, set up a well-maintained social ecosystem around Python packages. But not on PyPI itself: The Python Package Index is feasible in part because it has a clear and simple job, though, and that's not it.
-- \ “If you can't hear me sometimes, it's because I'm in | `\ parentheses.” —Steven Wright | _o__) | Ben Finney
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I don’t see any problem with the general idea of adding features to PyPI to enable package maintainers to find more help maintaining specific parts of their projects. I do have a problem with expecting the PyPI administrators to fill out or otherwise populate this information. Saying “Here’s a place you can donate to me” is still a fact, it’s just a more social fact than what we currently enable. I’m kind of down on the idea of linking to CVs or linkedin as part of the project metadata because that’s not project specific and is really more maintainer specific. I think that particular feature would be better suited to some sort of global “Python profile” that could then be linked to from PyPI instead of trying to bake it into PyPI itself. However things like “Looking for New Maintainers / Orphan a Project”, or some call to actions on “here are some issues that need fixed” or other things doesn’t seem unreasonable to me. Particularly the ability to orphan a project or look for new maintainers seems like a useful thing to me that really can’t live anywhere other than PyPI reasonably. The other items can live elsewhere if we wanted them to since they would be easy to add to the long_description of a project which would get added to the PyPI page but that has some drawbacks. For things like crowdfunding campaigns the long_description is set when you upload a release, however it’d be useful to have the campaigns update as the campaign progresses (or even ultimately be removed once the campaign has finished). I think an important part of this idea here is that this doesn’t enable anything that authors can’t already do, it just presents the information in a way that is easier for other tooling to take advantage of it as well as allow us to make more informed decisions about how to show it and when to show it without requiring authors to update the long_description of their projects. I think it will also be a strong signal that it’s OK for projects to ask for help (whether of the man power or monetary kind) and will also help lead more projects to be more sustainable for the long term. As far as man power goes, part of that problem is that adding *anything* to the current PyPI code base is a massive headache because there are zero tests and the code base itself is horribly factored and a pain in the ass to work with. However what we’re doing now is rewriting PyPI using a modern framework with modern practices (test coverage, CSS frameworks, etc). When this gets completed adding new features will be easier, especially for people who don’t regularly work on PyPI itself. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Mon, Apr 13, 2015 at 10:13 PM Donald Stufft <donald@stufft.io> wrote:
On Apr 13, 2015, at 8:57 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
Nick Coghlan <ncoghlan@gmail.com> writes:
On 11 Apr 2015 12:22, "Alexander Walters" <tritium-list@sdamon.com> wrote:
Is the package index really the best place to put this? This is a very social-networking feature for the authoritative repository of just about all the third party module, and it feels like either it could corrupt the 'sanctity' of the repository (in the absolute worst case)
If you're concerned that this feature might weaken the comforting illusion that PyPI published software is contributed and maintained by faceless automatons rather than living, breathing human beings, then yes, encouraging folks to think more about where the software they use is coming from would be a large part of the point of adding such a feature.
I can't speak for Alexander, but I'm also −1 to have this *on PyPI*.
I'm all for such features existing. What is at issue is whether PyPI is the place to put them.
We have been gradually improving the function of PyPI as an authoritative *index* of packages; that's possible because it is a repository of uncontroversial facts, not opinions (i.e. “what is the packaging metadata of this distribution”, “where is its documentation”, “where is its VCS”, etc.).
I am not saying the PSF shouldn't do this, but is pypi REALLY the best part of python.org to put it?
I personally believe so, yes - sustaining software over the long term is expensive in people's time, but it's often something we take for granted. The specific example Guido brought up in his keynote was the challenge of communicating a project's openness to Python 3 porting assistance.
The people doing the work of maintaining PyPI have said many times in recent years that there just isn't enough person-power to add a whole bunch of features that have been requested. Why would we think moderating a social-networking rating, opinion, discussion, or other non-factual database is something reasonable to ask of the PyPI maintainers?
Conversely, if we are under the impression that adding ratings, feedback, reviews, discussion, and other features to PyPI is *not* going to be a massive increase in workload for the maintainers, I think that's a foolish delusion which will be quite costly to the reputation PyPI has recently gained through hard effort to clarify its role.
By all means, set up a well-maintained social ecosystem around Python packages. But not on PyPI itself: The Python Package Index is feasible in part because it has a clear and simple job, though, and that's not it.
-- \ “If you can't hear me sometimes, it's because I'm in | `\ parentheses.” —Steven Wright | _o__) | Ben Finney
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I don’t see any problem with the general idea of adding features to PyPI to enable package maintainers to find more help maintaining specific parts of their projects. I do have a problem with expecting the PyPI administrators to fill out or otherwise populate this information. Saying “Here’s a place you can donate to me” is still a fact, it’s just a more social fact than what we currently enable.
I’m kind of down on the idea of linking to CVs or linkedin as part of the project metadata because that’s not project specific and is really more maintainer specific. I think that particular feature would be better suited to some sort of global “Python profile” that could then be linked to from PyPI instead of trying to bake it into PyPI itself.
However things like “Looking for New Maintainers / Orphan a Project”, or some call to actions on “here are some issues that need fixed” or other things doesn’t seem unreasonable to me. Particularly the ability to orphan a project or look for new maintainers seems like a useful thing to me that really can’t live anywhere other than PyPI reasonably.
I agree. Even something as simple as a boolean that triggers a banner saying "this project is looking for a new maintainer" would be useful both from the perspective of project owners who want to move on or from the perspective of users who can't tell if a project is maintained based on how long it has been since a project uploaded a new version (which is why I think someone suggested sending an annual email asking for a human action to say "alive and kicking" to help determine if a project is completely abandoned). -Brett
On 14 April 2015 at 11:16, Brett Cannon <brett@python.org> wrote:
I agree. Even something as simple as a boolean that triggers a banner saying "this project is looking for a new maintainer" would be useful both from the perspective of project owners who want to move on or from the perspective of users who can't tell if a project is maintained based on how long it has been since a project uploaded a new version (which is why I think someone suggested sending an annual email asking for a human action to say "alive and kicking" to help determine if a project is completely abandoned).
Yeah, I think Guido said something to this effect in his keynote.
Trishank Karthik Kuppusamy <trishank@nyu.edu> writes:
Yeah, I think Guido said something to this effect in his keynote.
Apparently I'm missing that context, then. The original post didn't help me understand why this proposal is significantly different from past “add a bunch of social to PyPI” rejected in the past. Can someone help by distinguishing this from past proposals of that kind? -- \ “I am as agnostic about God as I am about fairies and the | `\ Flying Spaghetti Monster.” —Richard Dawkins, 2006-10-13 | _o__) | Ben Finney
On Apr 14, 2015, at 6:46 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
Trishank Karthik Kuppusamy <trishank@nyu.edu> writes:
Yeah, I think Guido said something to this effect in his keynote.
Apparently I'm missing that context, then. The original post didn't help me understand why this proposal is significantly different from past “add a bunch of social to PyPI” rejected in the past.
Can someone help by distinguishing this from past proposals of that kind?
I think one of the distinguishing characteristics is that we’ve (as a community) changed and we’re more willing to evolve PyPI to do more and be a more central part of the life of a project than previously. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 14 April 2015 at 11:19, Trishank Karthik Kuppusamy <trishank@nyu.edu> wrote:
On 14 April 2015 at 11:16, Brett Cannon <brett@python.org> wrote:
I agree. Even something as simple as a boolean that triggers a banner saying "this project is looking for a new maintainer" would be useful both from the perspective of project owners who want to move on or from the perspective of users who can't tell if a project is maintained based on how long it has been since a project uploaded a new version (which is why I think someone suggested sending an annual email asking for a human action to say "alive and kicking" to help determine if a project is completely abandoned).
Yeah, I think Guido said something to this effect in his keynote.
Yep, Guido's keynote was the genesis of the thread. For folks that haven't seen it, the specific points of concern raised were: * seeking a new maintainer from amongst their users * seeking help with enabling Python 3 support Past suggestions for social features have related to providing users with a standard way to reach maintainers and each other, and I'd prefer to leave maintainers in full control of that aspect of the maintainer experience. I'm not alone in feeling that way, hence why such features tend not to be viewed especially positively. The one thing that *only* PyPI can provide is the combination of a publication channel for maintainers to reach their user base without either side needing to share contact information they aren't already sharing, together with the creation of the clear understanding that providing sustaining engineering for a piece of software represents a significant time commitment that users benefiting from an open source maintainer's generosity should respect. This thread regarding maintainers being able to more clearly communicate maintenance status to users also relates to my blog post ( http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html) regarding the fact that folks that: a) don't personally need to ensure software they maintain works on old versions of Python; and b) aren't getting paid to ensure it works on old versions of Python; c) shouldn't feel obliged to provide such support for free Supporting legacy platforms is generally tedious work that isn't inherently interesting or rewarding. Folks that want such legacy platform support should thus be expecting to have to pay for it, and demanding it for free is unreasonable. The perception that open source software is provided by magic internet pixies that don't need to eat (or at the very least to be thanked for the time their generosity has saved us) is unfortunately widespread and pernicious [1], and PyPI is in a position to help shift that situation to one where open source maintainers at least have the opportunity to clearly explain the sustaining engineering model backing their software while deflecting any criticism for the mere existence of such explanations onto the PyPI maintainers rather than having to cope with any negative feedback themselves. Regards, Nick. [1] As far as *how* that mistaken perception that failing to adequately compensate open source developers is OK became so widespread, my own theory is that it stems from the fact that open source was popularised first in the context of Linux, which relies heavily on the corporate patronage model where companies like Red Hat make money from customers that often aren't interested in technology for its own sake, while making the underlying software freely available as a basis for shared collaboration and experimentation. I personally like that model [2], but plenty of folks have entirely reasonable concerns about it and hence need to support their open source work in other ways. My view is that appropriately addressing that complex situation involves actively challenging the common assumption that adequately compensating the project developers for their work is somebody else's problem, and thus that it makes sense to eventually build the ability to issue that challenge directly into the software distribution infrastructure. It's not at the top of the priority list right now, but Guido's keynote made me realise it should be on the list somewhere. [2] http://community.redhat.com/blog/2015/02/the-quid-pro-quo-of-open-infrastruc... -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Nick Coghlan <ncoghlan@gmail.com> writes:
Yep, Guido's keynote was the genesis of the thread.
I can't find it online, can you give a URL so we can see the talk?
Past suggestions for social features have related to providing users with a standard way to reach maintainers and each other, and I'd prefer to leave maintainers in full control of that aspect of the maintainer experience. I'm not alone in feeling that way, hence why such features tend not to be viewed especially positively.
Thanks for this detailed response differentiating this proposal from previous ones, it's exactly what I was asking for. -- \ “For mad scientists who keep brains in jars, here's a tip: why | `\ not add a slice of lemon to each jar, for freshness?” —Jack | _o__) Handey | Ben Finney
On Tue, Apr 14, 2015 at 8:34 PM Ben Finney <ben+python@benfinney.id.au> wrote:
Nick Coghlan <ncoghlan@gmail.com> writes:
Yep, Guido's keynote was the genesis of the thread.
I can't find it online, can you give a URL so we can see the talk?
https://www.youtube.com/watch?v=G-uKNd5TSBw
Past suggestions for social features have related to providing users with a standard way to reach maintainers and each other, and I'd prefer to leave maintainers in full control of that aspect of the maintainer experience. I'm not alone in feeling that way, hence why such features tend not to be viewed especially positively.
Thanks for this detailed response differentiating this proposal from previous ones, it's exactly what I was asking for.
-- \ “For mad scientists who keep brains in jars, here's a tip: why | `\ not add a slice of lemon to each jar, for freshness?” —Jack | _o__) Handey | Ben Finney
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Apr 14, 2015 7:15 PM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 14 April 2015 at 11:19, Trishank Karthik Kuppusamy <trishank@nyu.edu>
On 14 April 2015 at 11:16, Brett Cannon <brett@python.org> wrote:
I agree. Even something as simple as a boolean that triggers a banner saying "this project is looking for a new maintainer" would be useful both from the perspective of project owners who want to move on or from the perspective of users who can't tell if a project is maintained based on how long it has been since a project uploaded a new version (which is why I think someone suggested sending an annual email asking for a human action to say "alive and kicking" to help determine if a project is completely abandoned).
Yeah, I think Guido said something to this effect in his keynote.
Yep, Guido's keynote was the genesis of the thread. For folks that haven't seen it, the specific points of concern raised were:
* seeking a new maintainer from amongst their users * seeking help with enabling Python 3 support
Past suggestions for social features have related to providing users with a standard way to reach maintainers and each other, and I'd prefer to leave
wrote: maintainers in full control of that aspect of the maintainer experience. I'm not alone in feeling that way, hence why such features tend not to be viewed especially positively.
The one thing that *only* PyPI can provide is the combination of a
If only there was a way to add RDFa metadata to the <a> tags in the HTML output of a pypa/readme-rendered long_description. FOAF RDFa and/or a /users/<username> https://warehouse.readthedocs.org/application/ Recently I learned about pyramid_autodoc. publication channel for maintainers to reach their user base without either side needing to share contact information they aren't already sharing, together with the creation of the clear understanding that providing sustaining engineering for a piece of software represents a significant time commitment that users benefiting from an open source maintainer's generosity should respect.
This thread regarding maintainers being able to more clearly communicate
maintenance status to users also relates to my blog post ( http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html) regarding the fact that folks that:
a) don't personally need to ensure software they maintain works on old
b) aren't getting paid to ensure it works on old versions of Python; c) shouldn't feel obliged to provide such support for free
Supporting legacy platforms is generally tedious work that isn't inherently interesting or rewarding. Folks that want such legacy platform support should thus be expecting to have to pay for it, and demanding it for free is unreasonable.
The perception that open source software is provided by magic internet
versions of Python; and pixies that don't need to eat (or at the very least to be thanked for the time their generosity has saved us) is unfortunately widespread and pernicious [1], and PyPI is in a position to help shift that situation to one where open source maintainers at least have the opportunity to clearly explain the sustaining engineering model backing their software while deflecting any criticism for the mere existence of such explanations onto the PyPI maintainers rather than having to cope with any negative feedback themselves. So, is this a new ENUM field and something over and above mtime?
On Apr 14, 2015 7:15 PM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
[...]
The perception that open source software is provided by magic internet
pixies that don't need to eat (or at the very least to be thanked for the time their generosity has saved us) https://en.wikipedia.org/wiki/Business_models_for_open-source_software https://gist.github.com/ndarville/4295324
On 16 April 2015 at 17:42, Wes Turner <wes.turner@gmail.com> wrote:
On Apr 14, 2015 7:15 PM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
[...]
The perception that open source software is provided by magic internet pixies that don't need to eat (or at the very least to be thanked for the time their generosity has saved us)
https://en.wikipedia.org/wiki/Business_models_for_open-source_software
Right, there *are* for-profit business models and non-profit fundraising models that can support sustainable development and maintenance of open source software. However, it can also be hard to tell the difference between supported and unsupported software until low level infrastructure shifts like Python 3 or Linux containerisation come along - in those cases, the software without a good sustaining development story runs a high risk of getting trapped in the old model. Unfortunately, "Do you know and understand the sustaining engineering model for all of your dependencies?" is a question most of us will be forced to say "No" to, even those of us that really should know better. It's very easy to assume that a popular open source project has a well-funded sustainable development process backing it without actually checking that that assumption is accurate. When I first started working there, I used to think Boeing's risk management folks were overly paranoid for demanding to know the answer to that question before agreeing to depend on a new supplier, but I eventually came to understand that it's mostly a matter of being able to quantify risk - if you have 10 key dependencies, each with a 10% chance of going away in a given time period, then you end up facing a 2/3rds chance of having to replace at least one of those components with an alternative. As a result, these days *I* tend to be the one wanting to know the long term sustaining engineering plans for new services and dependencies (and sometimes a service or dependency will be valuable enough to be worth taking a chance on). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Apr 11, 2015 9:46 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
Guido mentioned in his PyCon keynote this morning that we don't currently
have a great way for package authors to ask for help from their user base.
It occurred to me that it could be useful to have a "Help needed" feature
on PyPI (after the Warehouse migration) where package maintainers could register requests for assistance, such as:
* looking for new maintainers * requests for help with Python 3 support * links to specific issues a maintainer would like help with * links to donation pages (including links to Patreon, Gratipay, etc) * links to crowdfunding campaigns for specific new features * links to CVs/LinkedIn if folks are looking for work
Given a requirements.txt file, pip could then gain a "help-needed"
command that pulled the "help needed" entries for the named projects. We currently have https://pypi.python.org/pypi/pyline/json So, ideally: lookup("https://pypi.python.org/pypi/pyline") lookup("https://github.com/westurner/pypi") lookup(<project_uri : unicode>) : JSON-LD dict { PEP 426 Metadata 2.0 JSON (pydist.json), doap:Project, schema.org/SoftwareApplication, [{ "id": "#kickstarter-one", "type": "kickstarter-campaign", "url": <URL>, "description": "...", "date": "...", }, { "id": #donations-one", "type": "donations-xyz", "url": <URL>", } # ... } Unique ids/types made adding service-specific favicons, #anchors (and structured lookup) a bit easier. JSON-LD can also be easily displayed in RDFa in the primary HTML page.
The general idea would be to provide a direct channel from project
maintainers that may need help to their users who may be in a position to provide that help. It wouldn't need to be too complicated, just a Markdown field that maintainers could edit. There is a patch to add Markdown support to pypa/readme ( https://github.com/pypa/readme/issues/1). A structured (JSON-LD) vocabulary for these links (predicates) would also be immensely useful. Use cases: * what are all of the RSS feeds for [my] project * cross-domain project search * devbots * ( you name it ) This ties in with some work on a "Tools Schema" over in the W3C RDFJS group: * https://text.allmende.io/p/rdfjs As well as a Mailing List Extractor ("devbot"): https://westurner.org/wiki/ideas#open-source-mailing-list-extractor) And a general focus on tool / project documentation: https://westurner.org/wiki/tools ( https://westurner.github.io/tools/ )
In some cases, software is backed by folks that already have a
sustainable support model. For these it could be nice if the Markdown field could be used to say "Help not needed", and give credit to the people or orgs supporting them.
Absolutely. Even a link to a 'Contributing' docs page (such as created by cookiecutter-pypackage for ReadTheDocs or pythonhosted)
It's not something we can do anything about until after the Warehouse migration, but I figured I'd mention it while I was thinking about it :)
Getting setuptools/wheel/pypi/warehouse metadata as RDFa would require: * a JSON-LD context (and/or proper RDFS/OWL) * updates to the warehouse templates * new "reified" edges with a schema:url, schema:name/rdfs:label, and schema:descriptions Here's an example of updating pyvideo.org app with RDFa metadata (without migrating the database schema at all): * "Add Schema.org VideoObject RDFa metadata" https://github.com/pyvideo/richard/pull/213
From "Implement "hook" support for package signature verification" https://github.com/pypa/pip/issues/1035#issuecomment-39012414 :
Is this a signed graph with typed edges?
I would love to work on this; with free time or paid time wherever.
Interesting. One of the things that would help with getting people to help and is in the PEPs but last I checked wasn't yet implemented is the metadata that allows putting in all kinds of URLs and the ones I'm primarily thinking of here are the source code repository URL and the issue tracker URL. I personally sigh when I see a PyPI page that lists its URL as said PyPI page as this seems redundant and not useful and I'd rather see a GitHub or Bitbucket URL (or maybe a foo-project.org or readthedocs URL, but I the repo URL is usually what I'm most interested in). If we had the metadata with all the different kinds of URLs and the tools to show it and search it, then it would be clearer what to put where and would make it easier for consumers to find what they're looking for. Another thought I had while reading your email was the OpenHatch project and if there could be some tie-in with that. It also would be interesting if package maintainers had a channel to communicate with their user base. Back when I was at Yahoo, our proprietary package tool kept track of all installs of packages and stored the information in a centralized database. As a result, a package maintainer could see how many people had installed each version of their package and could send emails to folks who had installed a particular version or folks who had installed any version. A lot of folks used this to warn user bases about security issues, bugs, deprecations, etc. and to encourage folks to upgrade to newer versions and monitor the progress of such efforts. This is a pretty big architectural change of course. I can imagine an easier route could be to have the metadata have a link to a mailing list so a user could easily check a box, press a button, specify an option to pip install, etc. that would subscribe them to a project mailing list, hosted elsewhere. This obviates the need for PyPI/Warehouse to have a big database of who is interested in what by distributing out that responsibility to other tools like Mailman and what not. -Marc http://marc-abramowitz.com Sent from my iPhone 4S
On Apr 11, 2015, at 7:46 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Guido mentioned in his PyCon keynote this morning that we don't currently have a great way for package authors to ask for help from their user base.
It occurred to me that it could be useful to have a "Help needed" feature on PyPI (after the Warehouse migration) where package maintainers could register requests for assistance, such as:
* looking for new maintainers * requests for help with Python 3 support * links to specific issues a maintainer would like help with * links to donation pages (including links to Patreon, Gratipay, etc) * links to crowdfunding campaigns for specific new features * links to CVs/LinkedIn if folks are looking for work
Given a requirements.txt file, pip could then gain a "help-needed" command that pulled the "help needed" entries for the named projects.
The general idea would be to provide a direct channel from project maintainers that may need help to their users who may be in a position to provide that help. It wouldn't need to be too complicated, just a Markdown field that maintainers could edit.
In some cases, software is backed by folks that already have a sustainable support model. For these it could be nice if the Markdown field could be used to say "Help not needed", and give credit to the people or orgs supporting them.
It's not something we can do anything about until after the Warehouse migration, but I figured I'd mention it while I was thinking about it :)
Cheers, Nick.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Sat, Apr 11, 2015 at 12:29 PM, Marc Abramowitz <msabramo@gmail.com> wrote:
Interesting. One of the things that would help with getting people to help and is in the PEPs but last I checked wasn't yet implemented is the metadata that allows putting in all kinds of URLs and the ones I'm primarily thinking of here are the source code repository URL and the issue tracker URL.
http://legacy.python.org/dev/peps/pep-0459/: PEP:459Title:Standard Metadata Extensions for Python Software Packages Version:471651c1fe20Last-Modified:2014-07-02 22:55:34 -0700 (Wed, 02 Jul 2014) <http://hg.python.org/peps/file/tip/pep-0459.txt>Author:Nick Coghlan <ncoghlan at gmail.com>BDFL-Delegate:Nick Coghlan <ncoghlan@gmail.com> Discussions-To:Distutils SIG <distutils-sig at python.org <distutils-sig@python.org?subject=PEP%20459>>Status:DraftType:Standards TrackContent-Type:text/x-rst <http://legacy.python.org/dev/peps/pep-0012> Requires:426 <http://legacy.python.org/dev/peps/pep-0426>Created:11 Nov 2013 Post-History:21 Dec 2013 A JSON-LD context would be outstanding. - [ ] Additional properties for {...} (see RDFJS https://text.allmende.io/p/rdfjs ## Tools Schema)
I personally sigh when I see a PyPI page that lists its URL as said PyPI page as this seems redundant and not useful and I'd rather see a GitHub or Bitbucket URL (or maybe a foo-project.org or readthedocs URL, but I the repo URL is usually what I'm most interested in).
If we had the metadata with all the different kinds of URLs and the tools to show it and search it, then it would be clearer what to put where and would make it easier for consumers to find what they're looking for.
Another thought I had while reading your email was the OpenHatch project and if there could be some tie-in with that.
It also would be interesting if package maintainers had a channel to communicate with their user base. Back when I was at Yahoo, our proprietary package tool kept track of all installs of packages and stored the information in a centralized database. As a result, a package maintainer could see how many people had installed each version of their package and could send emails to folks who had installed a particular version or folks who had installed any version. A lot of folks used this to warn user bases about security issues, bugs, deprecations, etc. and to encourage folks to upgrade to newer versions and monitor the progress of such efforts.
Links to e.g. cvedetails, lists, and RSS feeds would be super helpful. Links to e.g. IRC, Slack, Gitter would be super helpful. Where Links == {edges, predicates, new metadata properties}
This is a pretty big architectural change of course. I can imagine an easier route could be to have the metadata have a link to a mailing list so a user could easily check a box, press a button, specify an option to pip install, etc. that would subscribe them to a project mailing list, hosted elsewhere. This obviates the need for PyPI/Warehouse to have a big database of who is interested in what by distributing out that responsibility to other tools like Mailman and what not.
There are a number of web-based pip management applications. Really, upgrading to Mailman 3 w/ the message archive links auto-appended would also be great. The applications are much broader than just Python packages (eggs, wheels, condabuilds) and pip/peep dependency resolution. (... RDFJS https://text.allmende.io/p/rdfjs ## Tools Schema )
On Sat, Apr 11, 2015 at 1:14 PM, Wes Turner <wes.turner@gmail.com> wrote:
On Sat, Apr 11, 2015 at 12:29 PM, Marc Abramowitz <msabramo@gmail.com> wrote:
Interesting. One of the things that would help with getting people to help and is in the PEPs but last I checked wasn't yet implemented is the metadata that allows putting in all kinds of URLs and the ones I'm primarily thinking of here are the source code repository URL and the issue tracker URL.
http://legacy.python.org/dev/peps/pep-0459/:
PEP:459Title:Standard Metadata Extensions for Python Software Packages Version:471651c1fe20Last-Modified:2014-07-02 22:55:34 -0700 (Wed, 02 Jul 2014) <http://hg.python.org/peps/file/tip/pep-0459.txt>Author:Nick Coghlan <ncoghlan at gmail.com>BDFL-Delegate:Nick Coghlan < ncoghlan@gmail.com>Discussions-To:Distutils SIG <distutils-sig at python.org <distutils-sig@python.org?subject=PEP%20459>>Status:DraftType:Standards TrackContent-Type:text/x-rst <http://legacy.python.org/dev/peps/pep-0012> Requires:426 <http://legacy.python.org/dev/peps/pep-0426>Created:11 Nov 2013Post-History:21 Dec 2013
A JSON-LD context would be outstanding.
- [ ] Additional properties for {...} (see RDFJS https://text.allmende.io/p/rdfjs ## Tools Schema)
I personally sigh when I see a PyPI page that lists its URL as said PyPI page as this seems redundant and not useful and I'd rather see a GitHub or Bitbucket URL (or maybe a foo-project.org or readthedocs URL, but I the repo URL is usually what I'm most interested in).
If we had the metadata with all the different kinds of URLs and the tools to show it and search it, then it would be clearer what to put where and would make it easier for consumers to find what they're looking for.
Another thought I had while reading your email was the OpenHatch project and if there could be some tie-in with that.
It also would be interesting if package maintainers had a channel to communicate with their user base. Back when I was at Yahoo, our proprietary package tool kept track of all installs of packages and stored the information in a centralized database. As a result, a package maintainer could see how many people had installed each version of their package and could send emails to folks who had installed a particular version or folks who had installed any version. A lot of folks used this to warn user bases about security issues, bugs, deprecations, etc. and to encourage folks to upgrade to newer versions and monitor the progress of such efforts.
Links to e.g. cvedetails, lists, and RSS feeds would be super helpful.
Links to e.g. IRC, Slack, Gitter would be super helpful.
Where Links == {edges, predicates, new metadata properties}
Links to downstream packages (and their RSS feeds) would also be helpful. * Debian has RDF (and also more structured link types that would be useful for project metadata) * changelog / "release notes" * build lods * https://wiki.debian.org/RDF * https://packages.qa.debian.org/p/python3-defaults.html * https://packages.qa.debian.org/p/python3-defaults.ttl What URI should pypi:readme or warehouse:readme expand to? @prefix pypi: <https://pypi.python.org/pypi/> ; @prefix warehouse: <https://warehouse.python.org/project/> ; @prefix github: <https://github.com/> ; * pypi:json["info"]["name"] ( + ".json" ) * warehouse:json["info"]["name"] * github:json["info"]["name"] @prefix doap: <http://usefulinc.com/ns/doap#> ; * http://lov.okfn.org/dataset/lov/vocabs/doap @prefix schema: <http://schema.org/> ; * schema:SoftwareApplication -> https://schema.org/SoftwareApplication * schema:Code -> https://schema.org/Code * schema:Project -> TODO (new framework for extension vocabularies) Should/could there be a pypa: namespace? @prefix pypa: <https://pypa.github.io/ns/pypa/#> ; * [ ] { PEP Metadata -> JSON-LD, pypa.ttl RDF Ontology }
participants (9)
-
Alexander Walters -
Ben Finney -
Brett Cannon -
Donald Stufft -
Marc Abramowitz -
Nick Coghlan -
Olivier Grisel -
Trishank Karthik Kuppusamy -
Wes Turner