<div dir="ltr"><div><div><div><div><div><div>Brian,<br><br></div> thanks for spending time and writing down this email.<br><br></div>+1 for submitting pup for for commit bit acquisition.<br><br></div>W/r to commit bit relieve/loss/removal i would make a separate pup just because we'd need to deal with a lot of conditions and usecases.<br><br></div>* i suggest the process we'd adopt would be default one and plugins would follow those by default unless they would write their own process.<br></div>* i suggest we list at least some kind of criteria like X time involved in project development, has demonstrated to provide good form and useful code reviews, has submitted code that was accepted into main parts of the project.<br></div><div>Project in this case i am referring the repository( pulp/<core><devel><plugin> ) which is part of organization (Pulp)<br></div><div>* the candidate would whether apply himself for commit bit or an existing core member would nominate the candidate through the email list, for example pulp-dev<br></div><div>* voting willbe open and public via email, with majority of core-devs voted and no -1. Some time limit on voting would be set as well.<br></div><div>* chance of re-applying for commit bit with some cooldown<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div>
<br><div class="gmail_quote">On Tue, May 22, 2018 at 3:27 PM, Robin Chan <span dir="ltr"><<a href="mailto:rchan@redhat.com" target="_blank">rchan@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We should also have a process to remove a commit bit from a contributor.<br>
<br>
I believe it would be helpful to come up with an initial proposal for<br>
granting the commit bit, then a proposal for removing, and then going<br>
to a vote for the grant or both. I don't want to confuse the subject,<br>
so I'll stay on the subject of granting.<br>
<br>
Any proposal on terminology for terms would be helpful so we can<br>
communicate clearly.<br>
<br>
Process<br>
- I think the contributor should request the commit bit via an email<br>
call for vote on the pulp-dev list. Reason here is that this is a lot<br>
of responsibility and they have to be willing to accept that<br>
responsibility.<br>
<br>
Criteria<br>
I am fine with the lack of hard requirements for getting the commit<br>
bit. I wonder if it would be helpful to add some minimal requirements<br>
such as length of time of involvement or # of PRs reviewed/merged to<br>
be considered or ask for a vote? Or perhaps this that guidance it<br>
listed more as expectations for responsibilities held as a commit bit<br>
holder. The gist here would be that you let the requestor know what<br>
would be expected of them and some guidance on what what our<br>
expectations are vs. other projects.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Tue, May 22, 2018 at 4:34 AM, Milan Kovacik <<a href="mailto:mkovacik@redhat.com">mkovacik@redhat.com</a>> wrote:<br>
> Brian,<br>
><br>
> thanks for the proposal!<br>
> I agree with the proposed process to gain the commit bit because of it<br>
> being based on the trust folks have to each other and the project and<br>
> because of its positive feedback loop effect on the trust building,<br>
> this process I believe will bring.<br>
> I'd like to suggest we adopt a process to relieve a commit bit too.<br>
><br>
> Thanks,<br>
> milan<br>
><br>
><br>
> On Mon, May 21, 2018 at 11:48 PM, Brian Bouterse <<a href="mailto:bbouters@redhat.com">bbouters@redhat.com</a>> wrote:<br>
>> For core and it's related tools, we don't have a written process to describe<br>
>> giving the commit bit to a contributor. We've been wanting to agree on and<br>
>> document that process for a while, so I'm facilitating thread gathering<br>
>> ideas to inform the writing of a PUP.<br>
>><br>
>> This starter email gives a brief history of what we've done and outlines a<br>
>> simple proposal to get us started. We can throw that proposal away in favor<br>
>> of any other idea.<br>
>><br>
>> # History<br>
>><br>
>> Historically if you were hired onto the Pulp team at Red Hat you received<br>
>> the commit bit day 0. In Oct 2017 we decided to stop doing that and instead<br>
>> document an open process. Engineers hired on the pulp time since Oct '17<br>
>> have not received commit bit. We have not yet documented an open process of<br>
>> which to give it to them or any other proven contributor.<br>
>><br>
>> # Current State<br>
>><br>
>> The current core devs as shown on github are: asmacdo, bizhang, bmbouter,<br>
>> daviddavis, dkliban, dalley, ipanova, jortel, pcreech, ttereshc<br>
>><br>
>> # Scope of this discussion<br>
>><br>
>> pulp/pulp, pulp/devel, and any repos for the Pulp3 Ansible installer. It<br>
>> applies to both Pulp2 and Pulp3. Plugins will do what they want.<br>
>><br>
>> # Process Idea<br>
>><br>
>> One process idea is to add a new core committer upon a vote with +1's<br>
>> received from all current core developers. The thinking is that all current<br>
>> core devs needs to be 100% comfortable for the new person to handle any<br>
>> issue in place of themselves.<br>
>><br>
>> # Criteria<br>
>><br>
>> Overall I believe someone who has demonstrated commitment and care towards<br>
>> the needs of all Pulp users and not only their own interests. Also they must<br>
>> have the experience to be trusted with major aspects of Pulp functionality.<br>
>><br>
>> These requirements are somewhat vague by design. Any process with hard<br>
>> requirements will be gamed so I believe leaving it to the judgement of the<br>
>> existing devs is a safe approach. Anyone who specifically wants to get more<br>
>> involved should approach the core devs about mentorship. I think the right<br>
>> time will be obvious, and if there are doubts those can be expressed ahead<br>
>> of time or at vote time.<br>
>><br>
>> # Code owners<br>
>><br>
>> This commit bit vote could be for entire core repos, or it could be for a<br>
>> subsystem of Pulp enforced using github's "code owners" feature<br>
>> (<a href="https://blog.github.com/2017-07-06-introducing-code-owners/" rel="noreferrer" target="_blank">https://blog.github.com/2017-<wbr>07-06-introducing-code-owners/</a><wbr>).<br>
>><br>
>><br>
>> ^ is starter content, please send ideas and discussion that will be<br>
>> incorporated into a first draft PEP at some point.<br>
>><br>
>> -Brian<br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Pulp-dev mailing list<br>
>> <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
>> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
>><br>
><br>
> ______________________________<wbr>_________________<br>
> Pulp-dev mailing list<br>
> <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br>
______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
</div></div></blockquote></div><br></div>