<div dir="ltr">Hi folks, sorry for the delay, I was on vacation and then catching up on stuff. I've composed a draft of the policy and I welcome your comments (in the doc, please):<div><br></div><div><a href="https://docs.google.com/document/d/1elum7ENjQb0dLB4ATfYNtnXYVLUzsKacc0VWnHHJb2A/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1elum7ENjQb0dLB4ATfYNtnXYVLUzsKacc0VWnHHJb2A/edit?usp=sharing</a><br></div><div><br></div><div>My apologies if I've missed some nuance in a particular contribution to this discussion: please just leave a comment in the doc :)</div><div><br></div><div><br></div><div>    Richard</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 September 2014 07:49, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr"><br>
On 23 Sep 2014 00:19, "Antoine Pitrou" <<a href="mailto:antoine@python.org" target="_blank">antoine@python.org</a>> wrote:<br>
><br>
> Donald Stufft <donald <at> <a href="http://stufft.io" target="_blank">stufft.io</a>> writes:<br>
> ><br>
> > PyPI inherinently has complete control over who owns what name on PyPI.<br>
><br>
> Political authority does not derive from technical control, though.<br>
><br>
> > As Toshio said that are situations where it makes *obvious* sense to transfer<br>
> > ownership of a project. Using Django as an pretty good example here, There are<br>
> > four people able to make releases there, until fairly recently there were only<br>
> > two if I recall. I don't think anyone would be against PyPI transfering<br>
> > ownership of Django to another active core developer of Django in the event<br>
> > that all of the people with permissions on PyPI were gone in some fashion.<br>
><br>
> Assuming the remaining Django core developers agree on it, then, yes, that<br>
> can make sense. That's because they are the primary authors of the project<br>
> (even though they might not have been listed as such on PyPI).<br>
><br>
> The case people are worried about is whether someone who is not part of the<br>
> original project author(s) or maintainer(s) can get assigned the PyPI project.<br>
> In that case people should use one of the forks; there's no reason for PyPI<br>
> to crown a successor.</p>
</span><p dir="ltr">That's why I consider it important to get the original project's issue tracker involved in the transfer process. I'd also be OK with a process that required an affirmative "Yes" from the project community, defaulting to "No transfer" in the case of a lack of response.</p>
<p dir="ltr">Transfers are most needed for highly active projects where a fork could have a lot of ripple effects. I think it's reasonable to interpret "nobody cared enough to say yes or no" as "nobody cares enough for a transfer to be needed - just fork it rather than claiming the name".</p>
<p dir="ltr">Regards,<br>
Nick.</p>
<br>_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div><br></div>