You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by jan i <ja...@apache.org> on 2015/07/28 16:24:59 UTC
Criteria for becoming committer in Corinthia.
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.
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.
Re: Criteria for becoming committer in Corinthia.
Posted by jan i <ja...@apache.org>.
On 1 August 2015 at 17:26, Peter Kelly <pm...@apache.org> wrote:
> > On 28 Jul 2015, at 9:24 pm, jan i <ja...@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.
> >
> > 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.
>
> I think that fulfilling either of these three criteria to a sufficient
> extent makes sense as criteria. I think these should be guidelines to help
> people make their judgements however, not necessarily an automatic
> conclusion, not least of which is that opinions about what considers
> “sufficient” effort will differ.
>
> I think we should also add participation on JIRA issues to this list. I
> would consider that we should see both communication and code from a
> potential new committer in order to make a judgement. JIRA is an important
> mode of communication aside from the mailing list. And of course evidence
> of (non-trivial) coding work, especially when it’s done on the candidate’s
> own initiative, would in my mind speak strongly in favour of a +1.
>
please remember not all committers are programmers. We will hopefully soon
have testers/documenters/buildbot maintainers etc. so we must take care not
to focus
being committer around having done git commit.
rgds
jan i.
>
> Regarding patches and attribution: Git has the ability to make a commit
> where the identities of the author and committer are distinct. For example
> if Linus Torvalds sends me a patch, and I decide it’s good enough to
> accept, then I can use the —author option on git commit so that it’s
> recorded it was Linus’s work, not mine; I just put it in the repository.
> This will help in tracking who has done what, and a non-committer’s patch
> doesn’t get incorrectly attributed to the committer themselves.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: Criteria for becoming committer in Corinthia.
Posted by jan i <ja...@apache.org>.
On 1 August 2015 at 19:39, Andrea Pescetti <pe...@apache.org> wrote:
> On 01/08/2015 Peter Kelly wrote:
>
>> Regarding patches and attribution: Git has the ability to make a
>> commit where the identities of the author and committer are distinct.
>>
>
> All revision control systems have logs anyway, so proper attribution is
> always possible by means of a convention like
> http://openoffice.apache.org/svn-basics.html#committing_changes_by_others
>
> It is not nearly as elegant as having it natively, but much better than
> completely omitting it.
>
+1, I am all for we adapt that scheme, we are anyhow only a few that commit
patches from others, so it should not be hard.
Attribution is important, so omitting it is not an option from my pow.
rgds
jan i.
>
> Regards,
> Andrea.
>
Re: Criteria for becoming committer in Corinthia.
Posted by Andrea Pescetti <pe...@apache.org>.
On 01/08/2015 Peter Kelly wrote:
> Regarding patches and attribution: Git has the ability to make a
> commit where the identities of the author and committer are distinct.
All revision control systems have logs anyway, so proper attribution is
always possible by means of a convention like
http://openoffice.apache.org/svn-basics.html#committing_changes_by_others
It is not nearly as elegant as having it natively, but much better than
completely omitting it.
Regards,
Andrea.
Re: Criteria for becoming committer in Corinthia.
Posted by Peter Kelly <pm...@apache.org>.
> On 28 Jul 2015, at 9:24 pm, jan i <ja...@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.
>
> 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.
I think that fulfilling either of these three criteria to a sufficient extent makes sense as criteria. I think these should be guidelines to help people make their judgements however, not necessarily an automatic conclusion, not least of which is that opinions about what considers “sufficient” effort will differ.
I think we should also add participation on JIRA issues to this list. I would consider that we should see both communication and code from a potential new committer in order to make a judgement. JIRA is an important mode of communication aside from the mailing list. And of course evidence of (non-trivial) coding work, especially when it’s done on the candidate’s own initiative, would in my mind speak strongly in favour of a +1.
Regarding patches and attribution: Git has the ability to make a commit where the identities of the author and committer are distinct. For example if Linus Torvalds sends me a patch, and I decide it’s good enough to accept, then I can use the —author option on git commit so that it’s recorded it was Linus’s work, not mine; I just put it in the repository. This will help in tracking who has done what, and a non-committer’s patch doesn’t get incorrectly attributed to the committer themselves.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Criteria for becoming committer in Corinthia.
Posted by jan i <ja...@apache.org>.
On 30 July 2015 at 15:57, Dave Fisher <da...@comcast.net> wrote:
> 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.
>
I thought it was connected issues, but of course it makes sense to publicly
(in our wiki) state how merit is earned, and have the other discussion just
on a ML.
>
> 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.
>
+1
rgds
jan i.
> 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 <ja...@apache.org> wrote:
> >
> >> On Tuesday, July 28, 2015, Louis Suárez-Potts <lu...@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.
>
Re: Criteria for becoming committer in Corinthia.
Posted by Dave Fisher <da...@comcast.net>.
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 <ja...@apache.org> wrote:
>
>> On Tuesday, July 28, 2015, Louis Suárez-Potts <lu...@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.
Re: Criteria for becoming committer in Corinthia.
Posted by Louis Suárez-Potts <lu...@gmail.com>.
> On 30 Jul 15, at 03:28, jan i <ja...@apache.org> wrote:
>
> On Tuesday, July 28, 2015, Louis Suárez-Potts <lu...@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).
>
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.
Re: Criteria for becoming committer in Corinthia.
Posted by jan i <ja...@apache.org>.
On Tuesday, July 28, 2015, Louis Suárez-Potts <lu...@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.
Re: Criteria for becoming committer in Corinthia.
Posted by Louis Suárez-Potts <lu...@gmail.com>.
> On 28 Jul 15, at 10:24, jan i <ja...@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.
RE: Criteria for becoming committer in Corinthia.
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Tuesday, July 28, 2015 07:25
To: dev@corinthia.incubator.apache.org
Subject: Criteria for becoming committer in Corinthia.
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.
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.