<br><br><div class="gmail_quote">On Thu, May 29, 2008 at 8:19 PM, Daniel F. Kudwien &lt;<a href="mailto:news@unleashedmind.com">news@unleashedmind.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
No kinks. &nbsp;The current process works. &nbsp;However:<br>
<br>
We should really start to think about i) project maintainership, ii)<br>
educating current maintainers, iii) educating new maintainers, and iv)<br>
encouraging co-maintainership and joining forces.<br>
</blockquote><div><br>That&#39;s really a whole different subject than the process of taking over a module.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
OTOH, if there was a prepared candidate - would you really grant CVS access?<br>
Would you grant access to me?<br>
</blockquote><div><br>Me, no. I don&#39;t want a co-maintainer on my modules at this point. In general, though, I see people taking on co-maintainers all the time. There&#39;s only been one case that I&#39;m aware of where a maintainer wasn&#39;t taking care of his module and also refused to allow anyone else access. Most of the time people are willing give access to or even to hand over modules they have no time for. If anything, there&#39;s the opposite problem that there&#39;s simply not enough people with time to take over struggling modules.<br>
</div><div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Instead of complaining, let&#39;s talk about setting up standards and guidelines<br>
to help existing projects and maintainers to evolve.<br>
</blockquote><div><br>I wasn&#39;t complaining... I was asking him what kinks he found in the process so the document could be improved.<br></div><div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What&#39;s missing in contrib is some kind of a /dynamic/ drive. &nbsp;For example,<br>
we encourage maintainers to commit patches and credit the contributor(s)<br>
using a message of the following syntax:<br>
<br>
&quot;#12345 by sun: Fixed coding-style.&quot;<br>
<br>
We are parsing the &quot;#12345&quot; bit, but why don&#39;t we also parse the &quot;by sun&quot;<br>
bit to assign &#39;contributor credits&#39; to users for the corresponding project?<br>
If my username is covered in a certain amount of commits, am I eligible to<br>
automatically get CVS access? &nbsp;Maybe?<br>
<font color="#888888"></font></blockquote><div><br>Having that parsed automatically would be nice. I tried putting a link to a UID once and it just made a mess. As for auto CVS access, no way. As long as a maintainer hasn&#39;t abandoned their module, they should have say in who gets access. Sure, it&#39;s GPL, but it&#39;s generally accepted that the person who writes a module &quot;owns&quot; it unless they actively hand it off to someone else. If someone got commit writes to my modules automatically just because they submitted X patches, I&#39;d be quite annoyed. I&#39;m very glad the system doesn&#39;t work that way.<br>
<br>Michelle<br><br></div></div><br>