corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Criteria for becoming committer in Corinthia.
Date Thu, 30 Jul 2015 13:57:44 GMT
I may be wrong, but I think this conversation is not about working towards consensus as it
is about having an open way for all to see how merit is earned in the Corinthia project.

It helps others see it happen if it can be found in open archives.

Let's set some minimums: I propose:

PPMC will handle discussions on potential committers including consensus building on the private
list for a minimum of 7 days. We are volunteers and some may not be able to respond thoughtfully
until the weekend.

Unlike technical decisions committer decisions are not easily undone. Proceeding carefully
until consensus is reached is critical.

Sent from my iPhone

> On Jul 30, 2015, at 12:28 AM, jan i <jani@apache.org> wrote:
> 
>> On Tuesday, July 28, 2015, Louis Suárez-Potts <luispo@gmail.com> wrote:
>> 
>> 
>>> On 28 Jul 15, at 10:24, jan i <jani@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.

Mime
View raw message