On Tuesday, July 28, 2015, Louis Suárez-Potts <lui...@gmail.com> wrote:
> > > On 28 Jul 15, at 10:24, jan i <j...@apache.org <javascript:;>> wrote: > > > > Hi. > > > > As was obvious from other discussions (in private), we need to agree on > > what are the "rules" > > for being accepted as a committer. It is also obvious that there are room > > for diversity in how > > we apply the rules. > > Note: first, I like your framework and like, too, the flexibility > implicit. I also dislike rules that bind actions into rituals even when the > originating context has faded. I don’t think your suggestions do. > > However…. > mild rant/ > > Do we need rules? I’d think that in a small project, "rules" are better > understood as "conventions," or even "agreements." The difference is simply > that a step toward the codification of practice in the form of scripted > rules often—but not inevitably—doesn’t really add to the working of the > project. Unless I’m missing something here? I can see that when Corinthia > has more people and—one can only hope—diverging opinions and the > wherewithal to back them up—then bureaucratic and transparent systems will > be useful, as these are designed to minimise arbitrariness. But right now? > Of course, as Dennis enthusiastically +1’d, no doubt I’m missing something > here, and it really is the case that Corinthia needs rules now, as opposed > to, well, common sense modulo open source collaboration subjunctive Apache. > > /end mild rant > > All that said, I find nothing objectionable in the clear description you > offer—thanks. it is a good suggestion, let us talk about "conventions". Maybe we should also add a convention about what happens if a single PPMC do not want to work towards consensus (of course after ample time to discuss). rgds jan i > > Louis > > > > > > For me life is very simple, we are a small project, and should use any > > chance to grow. This > > means, I believe we should look at: > > > > 1) Candidate has been active on dev@ and shown interest for the project > > 2) Candidate has submitted patches (not necessarily through dev@) > > 3) Candidate has otherwise done work to help corinthia. > > > > The proposer must make clear which of the 3 the candidate fulfills (1 is > > enough), in > > case of 3) the proposer must make it clear to the others what work was > done > > and > > what the benefit will be for the project. > > > > If there is general consensus after a discussion, that the candidate is > > beneficial for the project, > > we run a vote (needed formally, at least until we become TLP). The vote > > should be a formality, > > but in case someone votes -1, the following should happen > > > > 1) The reasons for the -1 must be discussed, and may cause others to > change > > their > > opinion. > > > > We need to think about, how to handle a -1 from a person that either > give a > > non serious reason, > > or did not participate in the discussion. > > > > Please accept this for what it is, a suggestion from me, I hope for and > > expect changes. > > > > rgds > > jan i. > > -- Sent from My iPad, sorry for any misspellings.
