corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Suárez-Potts <>
Subject Re: Criteria for becoming committer in Corinthia.
Date Tue, 28 Jul 2015 18:26:39 GMT

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

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.


> 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.

View raw message