> On Sept. 19, 2014, 5:24 p.m., Adam B wrote: > > I think it's valuable to outline some guidelines for anybody interested in > > becoming a committer, but I don't think we should set too many strict rules > > and regulations around it. Other thoughts below.
I think exactly the opposite. I think clear guidelines give contributors goals to attain and allow them to have an aim further than just contributing to the project. It also reduces friction when deciding who to nominate as a new committer and encourages the nomination of new committers as contributors mature. > On Sept. 19, 2014, 5:24 p.m., Adam B wrote: > > docs/becoming-a-committer.md, line 13 > > <https://reviews.apache.org/r/25785/diff/1/?file=693607#file693607line13> > > > > 10-20 non-trivial patches seems arbitrarily high. I've seen us call > > votes for contributors with as few as a dozen patches, and some of them may > > have been "trivial" by some definition. We should discuss what the actual > > (non-trivial) patch limit should be. I would be fine nominating somebody > > with 5 non-trivial patches if they are active in the community and > > committed to the project. > > > > If they are to be a docs or website committer, the requirements could > > be even less. > > > > Maybe we shouldn't even publish a hard limit publicly. Maybe anybody > > can "ask" to be nominated, and the existing committers can evaluate the > > requirements for that individual/role. I think a limit or guideline is important to avoid the decision-making seem arbitrary, however i'm completely open to changing this number based on what people are comfortable with. There's always going to be room for interpretation when actually voting regarding the triviality or otherwise of the patches. > On Sept. 19, 2014, 5:24 p.m., Adam B wrote: > > docs/becoming-a-committer.md, line 27 > > <https://reviews.apache.org/r/25785/diff/1/?file=693607#file693607line27> > > > > Why 10 days? Why not 1 week? How did you arrive at this number? I had to start somewhere. I wanted something that would give people enough time to vote and as people often go on vacation for a week, it avoids people missing the chance to give feedback. > On Sept. 19, 2014, 5:24 p.m., Adam B wrote: > > docs/becoming-a-committer.md, line 34 > > <https://reviews.apache.org/r/25785/diff/1/?file=693607#file693607line34> > > > > Does that mean we will be revoking committer status from the Berkeley > > guys who have moved on to other things and are no longer contributing to > > Mesos? i need to find better wording for this. by 'positive contributor' i only meant 'not a negative contributor'. ie, not working actively against the project or being difficult to work with. > On Sept. 19, 2014, 5:24 p.m., Adam B wrote: > > docs/becoming-a-committer.md, line 36 > > <https://reviews.apache.org/r/25785/diff/1/?file=693607#file693607line36> > > > > Has this process been used/defined previously, or are you proposing a > > new process here? How long does the revocation vote last? I believe this is a new process. - Dominic ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25785/#review54053 ----------------------------------------------------------- On Sept. 18, 2014, 10:41 a.m., Dominic Hamon wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/25785/ > ----------------------------------------------------------- > > (Updated Sept. 18, 2014, 10:41 a.m.) > > > Review request for mesos and Vinod Kone. > > > Bugs: MESOS-1815 > https://issues.apache.org/jira/browse/MESOS-1815 > > > Repository: mesos-git > > > Description > ------- > > Add a guide to becoming a committer. > > > Diffs > ----- > > docs/becoming-a-committer.md PRE-CREATION > > Diff: https://reviews.apache.org/r/25785/diff/ > > > Testing > ------- > > > Thanks, > > Dominic Hamon > >
