Thank you Brian! I like the brevity. It covers everything I can think of at the moment.
On Fri, Jun 1, 2018 at 3:49 PM, Brian Bouterse <[email protected]> wrote: > I've put together a draft PUP6 - Commit Bit Assignment. I've tried to > incorporate the ideas from this thread. Also you'll see a clear-and-present > notion of subsystem owners. > > https://github.com/pulp/pups/pull/10/files > > Please send ideas, questions, revisions, etc via the list or directly on > the PR now through June 10th. I'll try to respond and call out any > significant changes back on the list. A formal vote will be called some > time after June 10th if blocking concerns haven't been expressed by then. > > Thank you, > Brian > > > On Tue, May 22, 2018 at 3:45 PM, Robin Chan <[email protected]> wrote: > >> To simplify my request and to get the ball rolling on the process, >> perhaps we can boil this down to the an existing holder of the commit >> bit can sponsor the candidate by means of initiating the email. The >> candidate and sponsor should collaborate to list >> qualifications/justifications which can be a means of providing some >> guidance on minimum requirements until we agree on them. It would also >> ensure that we have at least one +1 before starting the vote process. >> This sponsor would also be responsible for tallying votes/ensure >> quorum vote on the deadline & granting the git permissions/settings. >> >> +1 on plugins adopting same rule unless they choose to adopt their own >> +1 on cool down re-application - 60 days would be my suggestion >> >> >> On Tue, May 22, 2018 at 11:44 AM, Ina Panova <[email protected]> wrote: >> > Brian, >> > >> > thanks for spending time and writing down this email. >> > >> > +1 for submitting pup for for commit bit acquisition. >> > >> > 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. >> > >> > * 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. >> > * 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. >> > Project in this case i am referring the repository( >> > pulp/<core><devel><plugin> ) which is part of organization (Pulp) >> > * 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 >> > * 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. >> > * chance of re-applying for commit bit with some cooldown >> > >> > >> > >> > -------- >> > Regards, >> > >> > Ina Panova >> > Software Engineer| Pulp| Red Hat Inc. >> > >> > "Do not go where the path may lead, >> > go instead where there is no path and leave a trail." >> > >> > On Tue, May 22, 2018 at 3:27 PM, Robin Chan <[email protected]> wrote: >> >> >> >> We should also have a process to remove a commit bit from a >> contributor. >> >> >> >> I believe it would be helpful to come up with an initial proposal for >> >> granting the commit bit, then a proposal for removing, and then going >> >> to a vote for the grant or both. I don't want to confuse the subject, >> >> so I'll stay on the subject of granting. >> >> >> >> Any proposal on terminology for terms would be helpful so we can >> >> communicate clearly. >> >> >> >> Process >> >> - I think the contributor should request the commit bit via an email >> >> call for vote on the pulp-dev list. Reason here is that this is a lot >> >> of responsibility and they have to be willing to accept that >> >> responsibility. >> >> >> >> Criteria >> >> I am fine with the lack of hard requirements for getting the commit >> >> bit. I wonder if it would be helpful to add some minimal requirements >> >> such as length of time of involvement or # of PRs reviewed/merged to >> >> be considered or ask for a vote? Or perhaps this that guidance it >> >> listed more as expectations for responsibilities held as a commit bit >> >> holder. The gist here would be that you let the requestor know what >> >> would be expected of them and some guidance on what what our >> >> expectations are vs. other projects. >> >> >> >> >> >> On Tue, May 22, 2018 at 4:34 AM, Milan Kovacik <[email protected]> >> >> wrote: >> >> > Brian, >> >> > >> >> > thanks for the proposal! >> >> > I agree with the proposed process to gain the commit bit because of >> it >> >> > being based on the trust folks have to each other and the project and >> >> > because of its positive feedback loop effect on the trust building, >> >> > this process I believe will bring. >> >> > I'd like to suggest we adopt a process to relieve a commit bit too. >> >> > >> >> > Thanks, >> >> > milan >> >> > >> >> > >> >> > On Mon, May 21, 2018 at 11:48 PM, Brian Bouterse < >> [email protected]> >> >> > wrote: >> >> >> For core and it's related tools, we don't have a written process to >> >> >> describe >> >> >> giving the commit bit to a contributor. We've been wanting to agree >> on >> >> >> and >> >> >> document that process for a while, so I'm facilitating thread >> gathering >> >> >> ideas to inform the writing of a PUP. >> >> >> >> >> >> This starter email gives a brief history of what we've done and >> >> >> outlines a >> >> >> simple proposal to get us started. We can throw that proposal away >> in >> >> >> favor >> >> >> of any other idea. >> >> >> >> >> >> # History >> >> >> >> >> >> Historically if you were hired onto the Pulp team at Red Hat you >> >> >> received >> >> >> the commit bit day 0. In Oct 2017 we decided to stop doing that and >> >> >> instead >> >> >> document an open process. Engineers hired on the pulp time since Oct >> >> >> '17 >> >> >> have not received commit bit. We have not yet documented an open >> >> >> process of >> >> >> which to give it to them or any other proven contributor. >> >> >> >> >> >> # Current State >> >> >> >> >> >> The current core devs as shown on github are: asmacdo, bizhang, >> >> >> bmbouter, >> >> >> daviddavis, dkliban, dalley, ipanova, jortel, pcreech, ttereshc >> >> >> >> >> >> # Scope of this discussion >> >> >> >> >> >> pulp/pulp, pulp/devel, and any repos for the Pulp3 Ansible >> installer. >> >> >> It >> >> >> applies to both Pulp2 and Pulp3. Plugins will do what they want. >> >> >> >> >> >> # Process Idea >> >> >> >> >> >> One process idea is to add a new core committer upon a vote with >> +1's >> >> >> received from all current core developers. The thinking is that all >> >> >> current >> >> >> core devs needs to be 100% comfortable for the new person to handle >> any >> >> >> issue in place of themselves. >> >> >> >> >> >> # Criteria >> >> >> >> >> >> Overall I believe someone who has demonstrated commitment and care >> >> >> towards >> >> >> the needs of all Pulp users and not only their own interests. Also >> they >> >> >> must >> >> >> have the experience to be trusted with major aspects of Pulp >> >> >> functionality. >> >> >> >> >> >> These requirements are somewhat vague by design. Any process with >> hard >> >> >> requirements will be gamed so I believe leaving it to the judgement >> of >> >> >> the >> >> >> existing devs is a safe approach. Anyone who specifically wants to >> get >> >> >> more >> >> >> involved should approach the core devs about mentorship. I think the >> >> >> right >> >> >> time will be obvious, and if there are doubts those can be expressed >> >> >> ahead >> >> >> of time or at vote time. >> >> >> >> >> >> # Code owners >> >> >> >> >> >> This commit bit vote could be for entire core repos, or it could be >> for >> >> >> a >> >> >> subsystem of Pulp enforced using github's "code owners" feature >> >> >> (https://blog.github.com/2017-07-06-introducing-code-owners/). >> >> >> >> >> >> >> >> >> ^ is starter content, please send ideas and discussion that will be >> >> >> incorporated into a first draft PEP at some point. >> >> >> >> >> >> -Brian >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Pulp-dev mailing list >> >> >> [email protected] >> >> >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >> >> >> > >> >> > _______________________________________________ >> >> > Pulp-dev mailing list >> >> > [email protected] >> >> > https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >> >> _______________________________________________ >> >> Pulp-dev mailing list >> >> [email protected] >> >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > >> > >> > >> > _______________________________________________ >> > Pulp-dev mailing list >> > [email protected] >> > https://www.redhat.com/mailman/listinfo/pulp-dev >> > >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
