> On 28 Jul 15, at 10:24, jan i <j...@apache.org> 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. 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.
