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?