<div dir="ltr">Hi all,<div><br></div><div>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.</div><div><br></div><div>The use cases covered in that discussion appeared to me to be</div><div>  (a) Process for not allowing takeover a not-really/not-fully abandoned project</div><div>  (b) Process for taking over a (really) abandoned but useful project</div><div>  (c) Establishing graceful handover request processes and matchmaking</div><div><br></div><div>I would like to suggest another edge case:</div><div>  (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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>I'd appreciate it if this group could consider putting some wording around handling exceptional circumstances, and/or dealing with "squatter" type scenarios.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>-Tennessee</div><div><br clear="all"><div><br></div>-- <br>--------------------------------------------------<br>Tennessee Leeuwenburg<br><a href="http://myownhat.blogspot.com/">http://myownhat.blogspot.com/</a><br>"Don't believe everything you think"
</div></div>