> On 30 Jul 15, at 03:28, jan i <[email protected]> wrote: > > On Tuesday, July 28, 2015, Louis Suárez-Potts <[email protected]> wrote: > >> >>> On 28 Jul 15, at 10:24, jan i <[email protected] <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). >
What I’ve done previously is use the term, "guidelines," which has the same force as convention but is perhaps more codified. I would suggest that if consensus is not reached—and consensus is desirable, then a graceful fallback would be to supermajority (>60 percent of voting members), or, if agreed upon by a supermajority, just taking the proposal off the table. Yes, I’m aware that my inclination to bureaucracy has add more words than you (or I) would want. But what I try to do, too, is see how people actually operate, then suggest from that, provided that the people in question (us) are few in number and generally in agreement. If things are working fine, then why introduce elements that can complicate matters, and even distort them? If things are in fact broken—are they? I mean "broken" in that conversation has collapsed—then the rules or guidelines or whatever make more sense. All that said, tracking what we do, whether for a report or for the purpose of onboarding new members is hugely important and much of it is done automagically via email list archives. Asserting areas that probably need more monitoring—areas where there is either disagreement because views differ on how to do something or because no one has a clue and arguing is part of the necessary process—these can generate their own loose rules, where the grammar of rule making is, I suppose, accordance with the achievement of what is generally wanted out of that particular aspect of Corinthia or even Corinthia as such. And again, I hardly disagree with your suggestions or efforts. And I also absolutely understand the psychological benefit of having boundaries to channel intensity. best louis > 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.
