Process for taking over abandoned packages
Hi all, I have just finished reading through most of the prior discussion on this issue, but as I read it in one sitting, I can't promise to have covered every nuance. I would like to propose that the pendulum has swung too far for some use cases. The use cases covered in that discussion appeared to me to be (a) Process for not allowing takeover a not-really/not-fully abandoned project (b) Process for taking over a (really) abandoned but useful project (c) Establishing graceful handover request processes and matchmaking I would like to suggest another edge case: (d) Taking over an abandoned project which does not have any code, hasn't been touched for years and doesn't do anything. That is to say, squatting. The projects which fill some use provide value to people because regardless of what maintainer politics may be happening, they are still installable, useful things. Squatter packages don't do any good to anyone. Mostly, these will have been created with good intentions to "get round to it" or otherwise provide some value to the community. However for whatever reason, they get left behind. If the original creator is still on email, then this can be handled through normal process and the wishes of the original author can be identified. However, I am in the middle of a situation where that's not the case, and the current formalities don't allow any wriggle room (as written, anyway). One possibility would be to allow take-over in non-contactable situations where the utility of the namespace is being wasted (subject to the administrator's interpretation). Another would be to use the "Development Status" flag to put different controls in place. Regardless, I am currently in a situation where I would like to register a particular name, and make use of it for at least somewhat valuable code. Someone registered the same name ages ago (over a year) and there's no code in it, and the github repo for the project is similarly inactive. They can't be reached. I've just posted to the issue tracker in case that reaches them, but my hopes are not high. I think it's a shame if the policy is written such that there is no recourse for exceptions and no way to avoid "locking in" cruft and accumulation of bad packages with no clear future use. I think it's also a reasonable requirement that maintainers and authors be contactable (within some definition of time period etc) In this case, I can consider another name, of course. Unfortunately (for me), this whole policy discussion has only come up after I started the process of looking into a pypi name takeover. I've put energy into setting up the project with its current name, and have now put a fair bit of time into trying to meet everyone's needs with regards to the PyPI entry. Changing the pypi name means changing all kinds of other information systems in order to have naming consistency, it's not just a trivial matter for me. It's hard for me to see how anyone is benefiting from this situation -- the current nameholder isn't actually doing anything, and it's just putting the brakes on getting things done and wasting namespace. I'd appreciate it if this group could consider putting some wording around handling exceptional circumstances, and/or dealing with "squatter" type scenarios. I realise I have simplified a few things, but I did so in the interest of getting to what I thought the most important aspects were. Let me know if you'd like any more information. Regards, -Tennessee -- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think"
Thanks for raising squatting as a concern. I have added what I think is a reasonable method of handling squatting (or otherwise unused name registrations): https://docs.google.com/document/d/1elum7ENjQb0dLB4ATfYNtnXYVLUzsKacc0VWnHHJ... Richard On 14 October 2014 12:40, Tennessee Leeuwenburg <tleeuwenburg@gmail.com> wrote:
Hi all,
I have just finished reading through most of the prior discussion on this issue, but as I read it in one sitting, I can't promise to have covered every nuance. I would like to propose that the pendulum has swung too far for some use cases.
The use cases covered in that discussion appeared to me to be (a) Process for not allowing takeover a not-really/not-fully abandoned project (b) Process for taking over a (really) abandoned but useful project (c) Establishing graceful handover request processes and matchmaking
I would like to suggest another edge case: (d) Taking over an abandoned project which does not have any code, hasn't been touched for years and doesn't do anything. That is to say, squatting.
The projects which fill some use provide value to people because regardless of what maintainer politics may be happening, they are still installable, useful things.
Squatter packages don't do any good to anyone. Mostly, these will have been created with good intentions to "get round to it" or otherwise provide some value to the community. However for whatever reason, they get left behind. If the original creator is still on email, then this can be handled through normal process and the wishes of the original author can be identified. However, I am in the middle of a situation where that's not the case, and the current formalities don't allow any wriggle room (as written, anyway).
One possibility would be to allow take-over in non-contactable situations where the utility of the namespace is being wasted (subject to the administrator's interpretation). Another would be to use the "Development Status" flag to put different controls in place.
Regardless, I am currently in a situation where I would like to register a particular name, and make use of it for at least somewhat valuable code. Someone registered the same name ages ago (over a year) and there's no code in it, and the github repo for the project is similarly inactive. They can't be reached. I've just posted to the issue tracker in case that reaches them, but my hopes are not high.
I think it's a shame if the policy is written such that there is no recourse for exceptions and no way to avoid "locking in" cruft and accumulation of bad packages with no clear future use. I think it's also a reasonable requirement that maintainers and authors be contactable (within some definition of time period etc)
In this case, I can consider another name, of course. Unfortunately (for me), this whole policy discussion has only come up after I started the process of looking into a pypi name takeover. I've put energy into setting up the project with its current name, and have now put a fair bit of time into trying to meet everyone's needs with regards to the PyPI entry. Changing the pypi name means changing all kinds of other information systems in order to have naming consistency, it's not just a trivial matter for me. It's hard for me to see how anyone is benefiting from this situation -- the current nameholder isn't actually doing anything, and it's just putting the brakes on getting things done and wasting namespace.
I'd appreciate it if this group could consider putting some wording around handling exceptional circumstances, and/or dealing with "squatter" type scenarios.
I realise I have simplified a few things, but I did so in the interest of getting to what I thought the most important aspects were. Let me know if you'd like any more information.
Regards, -Tennessee
-- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think"
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Tue, Oct 14, 2014 at 13:38 +1100, Richard Jones wrote:
Thanks for raising squatting as a concern. I have added what I think is a reasonable method of handling squatting (or otherwise unused name registrations):
https://docs.google.com/document/d/1elum7ENjQb0dLB4ATfYNtnXYVLUzsKacc0VWnHHJ...
thanks for going through the effort! I added some suggestions - do you see them in the doc? Also i'd suggest to change the order of sections, first "Proposed Process" and then Conditions of Transfer. It's a bit unclear to me how someone starts the process, i.e. applies for getting a name that is currently taken. What about requiring that an Issue needs to be opened with the pypi tracker and the admin who does the (forceful) transfer shall close it approprirately so that we also have some permanent trail of what happened/was tried/discussed? best, holger
Richard
On 14 October 2014 12:40, Tennessee Leeuwenburg <tleeuwenburg@gmail.com> wrote:
Hi all,
I have just finished reading through most of the prior discussion on this issue, but as I read it in one sitting, I can't promise to have covered every nuance. I would like to propose that the pendulum has swung too far for some use cases.
The use cases covered in that discussion appeared to me to be (a) Process for not allowing takeover a not-really/not-fully abandoned project (b) Process for taking over a (really) abandoned but useful project (c) Establishing graceful handover request processes and matchmaking
I would like to suggest another edge case: (d) Taking over an abandoned project which does not have any code, hasn't been touched for years and doesn't do anything. That is to say, squatting.
The projects which fill some use provide value to people because regardless of what maintainer politics may be happening, they are still installable, useful things.
Squatter packages don't do any good to anyone. Mostly, these will have been created with good intentions to "get round to it" or otherwise provide some value to the community. However for whatever reason, they get left behind. If the original creator is still on email, then this can be handled through normal process and the wishes of the original author can be identified. However, I am in the middle of a situation where that's not the case, and the current formalities don't allow any wriggle room (as written, anyway).
One possibility would be to allow take-over in non-contactable situations where the utility of the namespace is being wasted (subject to the administrator's interpretation). Another would be to use the "Development Status" flag to put different controls in place.
Regardless, I am currently in a situation where I would like to register a particular name, and make use of it for at least somewhat valuable code. Someone registered the same name ages ago (over a year) and there's no code in it, and the github repo for the project is similarly inactive. They can't be reached. I've just posted to the issue tracker in case that reaches them, but my hopes are not high.
I think it's a shame if the policy is written such that there is no recourse for exceptions and no way to avoid "locking in" cruft and accumulation of bad packages with no clear future use. I think it's also a reasonable requirement that maintainers and authors be contactable (within some definition of time period etc)
In this case, I can consider another name, of course. Unfortunately (for me), this whole policy discussion has only come up after I started the process of looking into a pypi name takeover. I've put energy into setting up the project with its current name, and have now put a fair bit of time into trying to meet everyone's needs with regards to the PyPI entry. Changing the pypi name means changing all kinds of other information systems in order to have naming consistency, it's not just a trivial matter for me. It's hard for me to see how anyone is benefiting from this situation -- the current nameholder isn't actually doing anything, and it's just putting the brakes on getting things done and wasting namespace.
I'd appreciate it if this group could consider putting some wording around handling exceptional circumstances, and/or dealing with "squatter" type scenarios.
I realise I have simplified a few things, but I did so in the interest of getting to what I thought the most important aspects were. Let me know if you'd like any more information.
Regards, -Tennessee
-- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think"
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Yep, I get notified of comments, thanks. I'll add information on how to start the process - I always require an issue in the support tracker. On 14 October 2014 18:54, holger krekel <holger@merlinux.eu> wrote:
On Tue, Oct 14, 2014 at 13:38 +1100, Richard Jones wrote:
Thanks for raising squatting as a concern. I have added what I think is a reasonable method of handling squatting (or otherwise unused name registrations):
https://docs.google.com/document/d/1elum7ENjQb0dLB4ATfYNtnXYVLUzsKacc0VWnHHJ...
thanks for going through the effort!
I added some suggestions - do you see them in the doc?
Also i'd suggest to change the order of sections, first "Proposed Process" and then Conditions of Transfer.
It's a bit unclear to me how someone starts the process, i.e. applies for getting a name that is currently taken. What about requiring that an Issue needs to be opened with the pypi tracker and the admin who does the (forceful) transfer shall close it approprirately so that we also have some permanent trail of what happened/was tried/discussed?
best, holger
Richard
On 14 October 2014 12:40, Tennessee Leeuwenburg <tleeuwenburg@gmail.com> wrote:
Hi all,
I have just finished reading through most of the prior discussion on
issue, but as I read it in one sitting, I can't promise to have covered every nuance. I would like to propose that the pendulum has swung too far for some use cases.
The use cases covered in that discussion appeared to me to be (a) Process for not allowing takeover a not-really/not-fully abandoned project (b) Process for taking over a (really) abandoned but useful project (c) Establishing graceful handover request processes and matchmaking
I would like to suggest another edge case: (d) Taking over an abandoned project which does not have any code, hasn't been touched for years and doesn't do anything. That is to say, squatting.
The projects which fill some use provide value to people because regardless of what maintainer politics may be happening, they are still installable, useful things.
Squatter packages don't do any good to anyone. Mostly, these will have been created with good intentions to "get round to it" or otherwise
this provide
some value to the community. However for whatever reason, they get left behind. If the original creator is still on email, then this can be handled through normal process and the wishes of the original author can be identified. However, I am in the middle of a situation where that's not the case, and the current formalities don't allow any wriggle room (as written, anyway).
One possibility would be to allow take-over in non-contactable situations where the utility of the namespace is being wasted (subject to the administrator's interpretation). Another would be to use the "Development Status" flag to put different controls in place.
Regardless, I am currently in a situation where I would like to register a particular name, and make use of it for at least somewhat valuable code. Someone registered the same name ages ago (over a year) and there's no code in it, and the github repo for the project is similarly inactive. They can't be reached. I've just posted to the issue tracker in case that reaches them, but my hopes are not high.
I think it's a shame if the policy is written such that there is no recourse for exceptions and no way to avoid "locking in" cruft and accumulation of bad packages with no clear future use. I think it's also a reasonable requirement that maintainers and authors be contactable (within some definition of time period etc)
In this case, I can consider another name, of course. Unfortunately (for me), this whole policy discussion has only come up after I started the process of looking into a pypi name takeover. I've put energy into setting up the project with its current name, and have now put a fair bit of time into trying to meet everyone's needs with regards to the PyPI entry. Changing the pypi name means changing all kinds of other information systems in order to have naming consistency, it's not just a trivial matter for me. It's hard for me to see how anyone is benefiting from this situation -- the current nameholder isn't actually doing anything, and it's just putting the brakes on getting things done and wasting namespace.
I'd appreciate it if this group could consider putting some wording around handling exceptional circumstances, and/or dealing with "squatter" type scenarios.
I realise I have simplified a few things, but I did so in the interest of getting to what I thought the most important aspects were. Let me know if you'd like any more information.
Regards, -Tennessee
-- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think"
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I am currently trying to decide what to do in the case of this request: https://sourceforge.net/p/pypi/support-requests/420/ It is remarkably similar to the request which only just recently got me into trouble, with the slight difference that there may be a trademark issue which I am definitely not able to address. Therefore I am extremely hesitant to actually grant the request. It certainly falls under the final statement in the written-up policy: "Transfer will not be performed where an individual or project wishes to take ownership of a name because they feel the current owner has left it stagnating, or even broken, in the absence of the above transfer conditions." Your thoughts, as always, are welcome. Richard
I think package owners have a responsibility to be contactable, but that the time-frames should be long to allow for the fact people do go off the grid for valid reasons sometimes. I'd suggest something like 2 months is a reasonable interval to allow; if contact via email and available social media fail after 2 months, then broken packages without evidence of maintenance in the source repository should be moveable. Inactive, abandoned and nonfunctional packages could be defined as: -- Owner uncontactable via email or social media for 2 months -- No alternative representative for the package identified -- No evidence of maintenance in the source repository for 1 year (?) -- Package is not installable via pip install on 2.7 or 3.x This is as distinct from the squatter clause, which is really about never-even-started, never-did-anything registrations. If the original owner wants to keep the name, then I think they get to keep it regardless of the requesting parties desire to get a hold of it. Onus should be on the requesting party to supply evidence of the criteria via the issue tracker. Making things too complex? Maybe... On 16 October 2014 15:21, Richard Jones <richard@python.org> wrote:
I am currently trying to decide what to do in the case of this request: https://sourceforge.net/p/pypi/support-requests/420/
It is remarkably similar to the request which only just recently got me into trouble, with the slight difference that there may be a trademark issue which I am definitely not able to address. Therefore I am extremely hesitant to actually grant the request. It certainly falls under the final statement in the written-up policy:
"Transfer will not be performed where an individual or project wishes to take ownership of a name because they feel the current owner has left it stagnating, or even broken, in the absence of the above transfer conditions."
Your thoughts, as always, are welcome.
Richard
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
-- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think"
On 16 October 2014 14:41, Tennessee Leeuwenburg <tleeuwenburg@gmail.com> wrote:
I think package owners have a responsibility to be contactable, but that the time-frames should be long to allow for the fact people do go off the grid for valid reasons sometimes. I'd suggest something like 2 months is a reasonable interval to allow; if contact via email and available social media fail after 2 months, then broken packages without evidence of maintenance in the source repository should be moveable.
Inactive, abandoned and nonfunctional packages could be defined as: -- Owner uncontactable via email or social media for 2 months
The project issue tracker (if it has one) should be included here - the problem with email and social media is that they will generally lack the clear audit trail that public issue trackers automatically provide.
-- Package is not installable via pip install on 2.7 or 3.x
I'd be very wary of including technical requirements like this in the package transfer process. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 16 October 2014 14:21, Richard Jones <richard@python.org> wrote:
I am currently trying to decide what to do in the case of this request: https://sourceforge.net/p/pypi/support-requests/420/
A couple of points on the specific request: 1. http://sourceforge.net/p/py-googlemaps/bugs/4/ indicates the package owner is aware their package doesn't work anymore, and is redirecting folks to pygeocoder. 2. As noted in the draft policy, the next step would be to file an issue at http://sourceforge.net/p/py-googlemaps/bugs/ to provide a public record and timeline of attempts to contact the existing owner (I know email is a pretty unreliable way of contacting me, for example, since I don't read all of mine - if Gmail flags it as promotional, social media, or spam, I may never see it)
It is remarkably similar to the request which only just recently got me into trouble, with the slight difference that there may be a trademark issue which I am definitely not able to address. Therefore I am extremely hesitant to actually grant the request. It certainly falls under the final statement in the written-up policy:
"Transfer will not be performed where an individual or project wishes to take ownership of a name because they feel the current owner has left it stagnating, or even broken, in the absence of the above transfer conditions."
Moving on to more general comments on the draft policy, I'm inclined to agree with Holger's comment on that paragraph: if someone abandons a project entirely, but there's someone else willing and able to take it over, then it's desirable for us to have an agreed way to deal with that. His proposed thresholds of no releases for two years, and no response to a tracker issue regarding the transfer for 2 months sound reasonable to me, but I'd be quite open to bumping them higher (in the case at hand, the last py-googlemaps release and the last commit were both 5 years ago, while their last tracker activity was almost a year and a half ago).
Your thoughts, as always, are welcome.
I see Noah already raised the trademark dispute question as a comment on the draft policy, but you may want to make it explicit that in the absence of an amicable resolution at the community level, trademark related questions would need to be escalated to the Python Software Foundation as the legal entity backing the PyPI service. I'd obviously prefer to see us resolve things through the more collaborative community processes, but talking to lawyers (both ours and other people's) is one of the reasons the PSF exists. At this stage, the point of escalation would be directly to the board - dealing with *other people's* trademarks is not something that is currently delegated to anyone. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Ethan Furman -
holger krekel -
Nick Coghlan -
Richard Jones -
Tennessee Leeuwenburg