Home » General (non-technical) » Eclipse Foundation » Sponsored Committers?
| Sponsored Committers? [message #32150] |
Sat, 01 April 2006 00:43  |
 Bjorn Freeman-Benson
Messages: 334
Registered: July 2009 |
Senior Member |
|
|
As we have begun to remind people of the Charter rules for nominating
committers (see
http://eclipse-projects.blogspot.com/2006/03/consolidating-c ommitters.html),
reactions have been mixed. Some people feel that this is a good move,
while others find these rules inconvenient and resent their enforcement.
One argument against the requirement for a public track record of
contribution before becoming a committer is that it makes adding new
full-time team members more difficult than when starting a new project.
For example, if Mary-Anne joins the staff working on the Hyperplex
project, the rules state that she must serve as a contributor (via
patches) for three or four months before she can be elected and trusted
as a Committer. However, if she was part of the staff when the Hyperplex
project was created, then she would have been a Committer instantly.
Thus if she is one day late in joining the project, her committer status
is wildly different.
While we don't want to diminish the role of Committer in any way -
especially the trust placed in full-privileged Committers around project
decisions, technical leadership, and IP policy - we are floating the
idea of a "Sponsored Committer" status. A Sponsored Committer (SC) would
have write-access to the CVS repository, but would not have voting
rights on the project. Additionally, a Sponsored Committer would have a
Sponsor - a full-rights Committer who is taking responsibility for the
SC, just as if they were applying the SC's patches.
A Sponsored Committer would be elected by the existing Committers on a
project, and would be a temporary role (not to exceed N months) after
which the Committers would need a second vote to promote the person to
full Committer status. This would allow the SC to have write-access to
the repository while creating his or her public record of significant
and substantial contribution to the project.
We envision that the Sponsor would need to actively restate their
sponsorship on a regular basis (monthly?) and to nominate the candidate
for the full-rights Committer election when appropriate.
We are interested in your thoughts and opinions. A change of this nature
should be discussed in public here in the eclipse.foundation newsgroup.
Some discussion topics (besides the obvious "good or bad") include:
* Should some or all new committers on new projects start as Sponsored
Committers?
* Should we retroactively seek sponsors for existing Committers who do
not have a public track record of significant and substantial contribution?
* How should a project's Committer monitor the Sponsor's supervision of
the Sponsored Committer?
P.S. Read this post in HTML:
http://eclipse-projects.blogspot.com/2006/03/sponsored-commi tters.html
|
|
|
| Re: Sponsored Committers? [message #32187 is a reply to message #32150] |
Sat, 01 April 2006 14:01  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------020206020607030306060609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bjorn,
Thanks for soliciting feedback. My comments are below.
Bjorn Freeman-Benson wrote:
> As we have begun to remind people of the Charter rules for nominating
> committers (see
> http://eclipse-projects.blogspot.com/2006/03/consolidating-c ommitters.html),
> reactions have been mixed. Some people feel that this is a good move,
> while others find these rules inconvenient and resent their enforcement.
I'm a strong believer in looking at rules closely to understand the
spirit of the rules rather than merely the letters of the rules. In the
open source world, the spirit of freedom must be a fundamental principle
that helps guide all other rules. The developer is king within the
domain of their project.
>
>
> One argument against the requirement for a public track record of
> contribution before becoming a committer is that it makes adding new
> full-time team members more difficult than when starting a new
> project. For example, if Mary-Anne joins the staff working on the
> Hyperplex project, the rules state that she must serve as a
> contributor (via patches) for three or four months before she can be
> elected and trusted as a Committer. However, if she was part of the
> staff when the Hyperplex project was created, then she would have been
> a Committer instantly. Thus if she is one day late in joining the
> project, her committer status is wildly different.
The key principle to my mind is that the existing members of the project
must be comfortable that a new member is *trustworthy*. The number of
months that takes, or which criteria are used to determine
trustworthiness are merely a guidelines. The developers are king and
they should decide this within their own domain. The rules merely help
them justify any delays they feel are appropriate.
>
> While we don't want to diminish the role of Committer in any way -
> especially the trust placed in full-privileged Committers around
> project decisions, technical leadership, and IP policy - we are
> floating the idea of a "Sponsored Committer" status. A Sponsored
> Committer (SC) would have write-access to the CVS repository, but
> would not have voting rights on the project. Additionally, a Sponsored
> Committer would have a Sponsor - a full-rights Committer who is taking
> responsibility for the SC, just as if they were applying the SC's
> patches.
This seems an unnecessary. As a project lead I must and do already take
personally responsibility for every last thing that's committed by any
committer on my project. And even for committers I trust, I often still
want to review patches before they are committed.
>
> A Sponsored Committer would be elected by the existing Committers on a
> project, and would be a temporary role (not to exceed N months) after
> which the Committers would need a second vote to promote the person to
> full Committer status. This would allow the SC to have write-access to
> the repository while creating his or her public record of significant
> and substantial contribution to the project.
In my experience there is a gradual shift from reviewing all work
carefully to simply trusting that such scrutiny is unnecessary and that
the committer will seek review when they have any doubts. I don't think
this graduation process needs to be entrenched as yet more rules.
>
> We envision that the Sponsor would need to actively restate their
> sponsorship on a regular basis (monthly?) and to nominate the
> candidate for the full-rights Committer election when appropriate.
We really don't need more processes.
>
> We are interested in your thoughts and opinions. A change of this
> nature should be discussed in public here in the eclipse.foundation
> newsgroup. Some discussion topics (besides the obvious "good or bad")
> include:
>
> * Should some or all new committers on new projects start as Sponsored
> Committers?
No, I don't believe we need two classes of committer. If we can't trust
a committer to seek review of their changes then they can't be trusted
at all. The developers of any particular project should have final say
over whom to trust, and the lead should be accountable for any and all
committed changes.
> * Should we retroactively seek sponsors for existing Committers who do
> not have a public track record of significant and substantial
> contribution?
Absolutely not! Never should new rules be retroactively applied without
full agreement of those to whom they apply.
> * How should a project's Committer monitor the Sponsor's supervision
> of the Sponsored Committer?
The project lead should already be responsible for everything that's
committed and hence needs to be monitoring directly or indirectly
everything that's going on. We don't need rules for how to do this.
>
> P.S. Read this post in HTML:
> http://eclipse-projects.blogspot.com/2006/03/sponsored-commi tters.html
>
--------------020206020607030306060609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bjorn,<br>
<br>
Thanks for soliciting feedback. My comments are below.<br>
<br>
<br>
Bjorn Freeman-Benson wrote:
<blockquote cite="mid442DCCAE.7000502@eclipse.org" type="cite">As we
have begun to remind people of the Charter rules for nominating
committers (see
<a class="moz-txt-link-freetext" href=" http://eclipse-projects.blogspot.com/2006/03/consolidating-c ommitters.html"> http://eclipse-projects.blogspot.com/2006/03/consolidating-c ommitters.html</a>),
reactions have been mixed. Some people feel that this is a good move,
while others find these rules inconvenient and resent their enforcement.</blockquote>
I'm a strong believer in looking at rules closely to understand the
spirit of the rules rather than merely the letters of the rules. In the
open source world, the spirit of freedom must be a fundamental
principle that helps guide all other rules. The developer is king
within the domain of their project.<br>
<blockquote cite="mid442DCCAE.7000502@eclipse.org" type="cite"><br>
<br>
One argument against the requirement for a public track record of
contribution before becoming a committer is that it makes adding new
full-time team members more difficult than when starting a new project.
For example, if Mary-Anne joins the staff working on the Hyperplex
project, the rules state that she must serve as a contributor (via
patches) for three or four months before she can be elected and trusted
as a Committer. However, if she was part of the staff when the
Hyperplex project was created, then she would have been a Committer
instantly. Thus if she is one day late in joining the project, her
committer status is wildly different.
<br>
</blockquote>
The key principle to my mind is that the existing members of the
project must be comfortable that a new member is <b>trustworthy</b>.
The number of months that takes, or which criteria are used to
determine trustworthiness are merely a guidelines. The developers are
king and they should decide this within their own domain. The rules
merely help them justify any delays they feel are appropriate.<br>
<blockquote cite="mid442DCCAE.7000502@eclipse.org" type="cite"><br>
While we don't want to diminish the role of Committer in any way -
especially the trust placed in full-privileged Committers around
project decisions, technical leadership, and IP policy - we are
floating the idea of a "Sponsored Committer" status. A Sponsored
Committer (SC) would have write-access to the CVS repository, but would
not have voting rights on the project. Additionally, a Sponsored
Committer would have a Sponsor - a full-rights Committer who is taking
responsibility for the SC, just as if they were applying the SC's
patches.
<br>
</blockquote>
This seems an unnecessary. As a project lead I must and do already
take personally responsibility for every last thing that's committed by
any committer on my project. And even for committers I trust, I often
still want to review patches before they are committed.<br>
<blockquote cite="mid442DCCAE.7000502@eclipse.org" type="cite"><br>
A Sponsored Committer would be elected by the existing Committers on a
project, and would be a temporary role (not to exceed N months) after
which the Committers would need a second vote to promote the person to
full Committer status. This would allow the SC to have write-access to
the repository while creating his or her public record of significant
and substantial contribution to the project.
<br>
</blockquote>
In my experience there is a gradual shift from reviewing all work
carefully to simply trusting that such scrutiny is unnecessary and that
the committer will seek review when they have any doubts. I don't
think this graduation process needs to be entrenched as yet more rules.<br>
<blockquote cite="mid442DCCAE.7000502@eclipse.org" type="cite"><br>
We envision that the Sponsor would need to actively restate their
sponsorship on a regular basis (monthly?) and to nominate the candidate
for the full-rights Committer election when appropriate.
<br>
</blockquote>
We really don't need more processes.<br>
<blockquote cite="mid442DCCAE.7000502@eclipse.org" type="cite"><br>
We are interested in your thoughts and opinions. A change of this
nature should be discussed in public here in the eclipse.foundation
newsgroup. Some discussion topics (besides the obvious "good or bad")
include:
<br>
<br>
* Should some or all new committers on new projects start as Sponsored
Committers?
<br>
</blockquote>
No, I don't believe we need two classes of committer. If we can't
trust a committer to seek review of their changes then they can't be
trusted at all. The developers of any particular project should have
final say over whom to trust, and the lead should be accountable for
any and all committed changes.<br>
<blockquote cite="mid442DCCAE.7000502@eclipse.org" type="cite">* Should
we retroactively seek sponsors for existing Committers who do not have
a public track record of significant and substantial contribution?
<br>
</blockquote>
Absolutely not! Never should new rules be retroactively applied
without full agreement of those to whom they apply.<br>
<blockquote cite="mid442DCCAE.7000502@eclipse.org" type="cite">* How
should a project's Committer monitor the Sponsor's supervision of the
Sponsored Committer?
<br>
</blockquote>
The project lead should already be responsible for everything that's
committed and hence needs to be monitoring directly or indirectly
everything that's going on. We don't need rules for how to do this.<br>
<blockquote cite="mid442DCCAE.7000502@eclipse.org" type="cite"><br>
P.S. Read this post in HTML:
<br>
<a class="moz-txt-link-freetext" href=" http://eclipse-projects.blogspot.com/2006/03/sponsored-commi tters.html"> http://eclipse-projects.blogspot.com/2006/03/sponsored-commi tters.html</a>
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------020206020607030306060609--
|
|
|
| Re: Sponsored Committers? [message #32292 is a reply to message #32187] |
Mon, 03 April 2006 18:45 |
| Eclipse User |
|
|
|
Originally posted by: gwatson.lanl.gov
I agree with Ed. Different projects are going to have very different
requirements. Small or developing projects need to encourage
participation, not discourage it through strict interpretation of rules.
Also, the current rules do not cover all scenarios. For example, if I
hire someone to work on the project then I don't want to wait months for
them to achieve commit status, nor do I necessarily have the resources
to review every commit they make. The act of hiring them for the project
implies a level of 'trust', and having them sign an agreement that they
will abide by the guidelines implies a level of responsibility. There
should be flexibility, not rigidity, in the process.
Greg
Ed Merks wrote:
> Bjorn,
>
> Thanks for soliciting feedback. My comments are below.
>
>
> Bjorn Freeman-Benson wrote:
>> As we have begun to remind people of the Charter rules for nominating
>> committers (see
>> http://eclipse-projects.blogspot.com/2006/03/consolidating-c ommitters.html),
>> reactions have been mixed. Some people feel that this is a good move,
>> while others find these rules inconvenient and resent their enforcement.
> I'm a strong believer in looking at rules closely to understand the
> spirit of the rules rather than merely the letters of the rules. In the
> open source world, the spirit of freedom must be a fundamental principle
> that helps guide all other rules. The developer is king within the
> domain of their project.
>>
>>
>> One argument against the requirement for a public track record of
>> contribution before becoming a committer is that it makes adding new
>> full-time team members more difficult than when starting a new
>> project. For example, if Mary-Anne joins the staff working on the
>> Hyperplex project, the rules state that she must serve as a
>> contributor (via patches) for three or four months before she can be
>> elected and trusted as a Committer. However, if she was part of the
>> staff when the Hyperplex project was created, then she would have been
>> a Committer instantly. Thus if she is one day late in joining the
>> project, her committer status is wildly different.
> The key principle to my mind is that the existing members of the project
> must be comfortable that a new member is *trustworthy*. The number of
> months that takes, or which criteria are used to determine
> trustworthiness are merely a guidelines. The developers are king and
> they should decide this within their own domain. The rules merely help
> them justify any delays they feel are appropriate.
>>
>> While we don't want to diminish the role of Committer in any way -
>> especially the trust placed in full-privileged Committers around
>> project decisions, technical leadership, and IP policy - we are
>> floating the idea of a "Sponsored Committer" status. A Sponsored
>> Committer (SC) would have write-access to the CVS repository, but
>> would not have voting rights on the project. Additionally, a Sponsored
>> Committer would have a Sponsor - a full-rights Committer who is taking
>> responsibility for the SC, just as if they were applying the SC's
>> patches.
> This seems an unnecessary. As a project lead I must and do already take
> personally responsibility for every last thing that's committed by any
> committer on my project. And even for committers I trust, I often still
> want to review patches before they are committed.
>>
>> A Sponsored Committer would be elected by the existing Committers on a
>> project, and would be a temporary role (not to exceed N months) after
>> which the Committers would need a second vote to promote the person to
>> full Committer status. This would allow the SC to have write-access to
>> the repository while creating his or her public record of significant
>> and substantial contribution to the project.
> In my experience there is a gradual shift from reviewing all work
> carefully to simply trusting that such scrutiny is unnecessary and that
> the committer will seek review when they have any doubts. I don't think
> this graduation process needs to be entrenched as yet more rules.
>>
>> We envision that the Sponsor would need to actively restate their
>> sponsorship on a regular basis (monthly?) and to nominate the
>> candidate for the full-rights Committer election when appropriate.
> We really don't need more processes.
>>
>> We are interested in your thoughts and opinions. A change of this
>> nature should be discussed in public here in the eclipse.foundation
>> newsgroup. Some discussion topics (besides the obvious "good or bad")
>> include:
>>
>> * Should some or all new committers on new projects start as Sponsored
>> Committers?
> No, I don't believe we need two classes of committer. If we can't trust
> a committer to seek review of their changes then they can't be trusted
> at all. The developers of any particular project should have final say
> over whom to trust, and the lead should be accountable for any and all
> committed changes.
>> * Should we retroactively seek sponsors for existing Committers who do
>> not have a public track record of significant and substantial
>> contribution?
> Absolutely not! Never should new rules be retroactively applied without
> full agreement of those to whom they apply.
>> * How should a project's Committer monitor the Sponsor's supervision
>> of the Sponsored Committer?
> The project lead should already be responsible for everything that's
> committed and hence needs to be monitoring directly or indirectly
> everything that's going on. We don't need rules for how to do this.
>>
>> P.S. Read this post in HTML:
>> http://eclipse-projects.blogspot.com/2006/03/sponsored-commi tters.html
>>
>
|
|
| |
| Re: Sponsored Committers? [message #32362 is a reply to message #32292] |
Tue, 04 April 2006 19:33 |
Bjorn Freeman-Benson
Messages: 334
Registered: July 2009 |
Senior Member |
|
|
Ed, Greg,
Thanks. And to keep the conversation going some of my opinions...
Greg Watson wrote:
> For example, if I hire someone to work on the project
> then I don't want to wait months for them to achieve
> commit status, ... The act of hiring them for the project
> implies a level of 'trust',
While that sounds good on the surface, it implies that
"company X == Eclipse project Y" (or that a manager in
company X gets to make decisions about Eclipse project Y).
In open source land, it is the committers on project Y who
grant rights for Y even if those committers do not work
for the same company.
Consider the situation where hiring manager Susan of
Instantiations hires Tom to work at Instantiations on BIRT.
(Just an example: I don't know any Susan who works for
Instantiations.) Susan trusts Tom, clearly. But nobody on
the BIRT project has heard of Tom (or Susan). So why should
Tom be granted any rights on BIRT?
So perhaps you mean "if the project lead of Eclipse project Y
who works at company X hires somebody at company X to work on Y,
then that new person is trusted"? But what about the non-X
committers on project Y? Don't they get a say about whether the
person is to be trusted?
So perhaps you mean "if the project lead of Eclipse project Y
who works at company X and all the Y committers work at X for
the same project lead, then the new person should be given
rights"? ...
I think Ed had the right idea with (and my addition):
> The key principle to my mind is that [ALL] existing members
> of the project must be comfortable that a new member
> is *trustworthy*.
I like this idea. I like it so much that I think we should
change the charters to say this and then to recommend (but
not require) mechanisms that the project can use to ascertain
the trust. An apprenticeship would be one. A previous
history with the person (perhaps at a former project or job)
would be another. And so on.
How about others out there in the community? Does Ed's idea
resonate with you?
|
|
| |
| Re: Sponsored Committers? [message #32430 is a reply to message #32150] |
Wed, 05 April 2006 00:38 |
Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
I agree with Ed, Ed and Greg as well. None of us are fans of more process.
But what I think Bjorn could have done to help was to explain his motivation
for floating this idea. This idea didn't come up because we at the
Foundation like to dream up excuses for more process. It came up because
Bjorn is being asked by some PMCs to relax their own rules in the charters
so that as new people are hired by companies that they can be simply added
to the list of committers for projects.
Since Bjorn is a much nicer guy than I am, he is exploring ideas that could
achieve some sort of reasonable compromise. My answer would have actually
been a lot simpler: no way. (Actually, as those who know me well realize I
would have likely said it differently, but there might be kids reading
this.)
In my mind, Eclipse committer status means something much different than who
your employer is. It is something that must be *earned* through *prior*
contributions to a project, not a promise of future ones. It should never be
given to someone simply because it is convenient. If we go down the path of
convenience, we're headed for a world of hurt IMHO. As a general statement,
I would actually prefer to see the bar raised higher before someone is
granted committer status, not the other way around.
But hey, the Eclipse Foundation is here to service its members, especially
its committer members. So what do you guys think? Am I wrong?
|
|
|
| Re: Sponsored Committers? [message #32465 is a reply to message #32430] |
Thu, 06 April 2006 10:08 |
| Eclipse User |
|
|
|
Originally posted by: daniel.megert.eclipse.org
I agree with Mike, same rules should apply for all projects i.e. a
committer has to merit its status. Though it seems painful to review
patches and commit them for your new co-workers it is an important part
of ensuring a certain quality level and transferring project know how.
>For example, if Mary-Anne joins the staff working on the Hyperplex
project, the rules state that she must serve as a contributor (via
patches) for three or four >months before she can be elected and trusted
as a Committer. However, if she was part of the staff when the Hyperplex
project was created, then she >would have been a Committer instantly.
Thus if she is one day late in joining the project, her committer status
is wildly different.
I tend to disagree here: it is up to the Hyperplex project lead to name
the initial committers. For the sake of quality I hope he won't appoint
someone who got just added to the project a day ago to the initial list
unless of course that new guy is a real code wizard ;-)
Dani
|
|
|
| Re: Sponsored Committers? [message #32534 is a reply to message #32430] |
Thu, 06 April 2006 15:49 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Mike,
More comments in-line. I appreciate that Eclipse has such a good open
process for this type of discussion!
Mike Milinkovich wrote:
> I agree with Ed, Ed and Greg as well. None of us are fans of more process.
>
> But what I think Bjorn could have done to help was to explain his motivation
> for floating this idea. This idea didn't come up because we at the
> Foundation like to dream up excuses for more process. It came up because
> Bjorn is being asked by some PMCs to relax their own rules in the charters
> so that as new people are hired by companies that they can be simply added
> to the list of committers for projects.
>
I think it would be bad to bypass the normal checks and balances that
are in place within a project. It would undermine and devalue the
status associated with being a committer. I rather like Bjorn's idea of
requiring everyone on the project to agree (or perhaps for there to be
no dissenters) if the process is to be short cut based on pre-existing
levels of trust and merit. It's quite possible for everyone on the
project to be very familiar the person being added so in that case it
would not be a problem at all.
> Since Bjorn is a much nicer guy than I am, he is exploring ideas that could
> achieve some sort of reasonable compromise.
You're both nice guys. ;-)
> My answer would have actually
> been a lot simpler: no way. (Actually, as those who know me well realize I
> would have likely said it differently, but there might be kids reading
> this.)
>
Although perhaps Bjorn has a better way with words. ;-)
> In my mind, Eclipse committer status means something much different than who
> your employer is. It is something that must be *earned* through *prior*
> contributions to a project, not a promise of future ones.
I believe it definitely should be earned, but a particular person may
have earned great respect and trust in other ways and if everyone on the
project is comfortable with that, it should be fine.
> It should never be
> given to someone simply because it is convenient. If we go down the path of
> convenience, we're headed for a world of hurt IMHO. As a general statement,
> I would actually prefer to see the bar raised higher before someone is
> granted committer status, not the other way around.
>
Yes. Being too busy to review patches should not be an excuse to have a
free for all...
> But hey, the Eclipse Foundation is here to service its members, especially
> its committer members. So what do you guys think? Am I wrong?
>
I think you are mostly right. Just need to keep in mind that the people
on a particular project are probably the best people to judge trust and
merit. They'd better be! We are already trusting the existing
committer's merit every day...
>
>
|
|
|
| Re: Sponsored Committers? [message #32568 is a reply to message #32430] |
Thu, 06 April 2006 21:56 |
| Eclipse User |
|
|
|
Originally posted by: john.eclipsefaq.org
I definitely don't agree with adding committers "for free" because they
are paid to work on a project. Everyone should go through the same
process to earn commit rights. If anything, I agree with Mike that the
bar could actually be made higher, or at least require more evidence to
be presented than "+1" when someone is being nominated.
Having said that, I think it should be at the discretion of the PMC. On
some projects that are in very early stages, or in incubation areas of
mature projects, it makes sense for PMCs to bootstrap the process by
adding committers before they have established a track record. A
safeguard that can be used here is to make those rights more
fine-grained. For example Equinox has various incubation projects in
the repository that are not part of the production code. The PMC will
sometimes grant commit rights to new faces *only* in the incubation
project to help get it started. When the code migrates into production,
committers in the new location need to vote on whether commit rights
should be granted for the incubation committers in the production code.
This has a similar flavour to what Bjorn was suggesting: granting
limited rights with less restrictions to help get projects going, and as
a "career path" to earning the level of trust required for full-blown
commit rights.
I'll also make a feature plug: if anyone complains that applying patches
is too onerous, they likely aren't using the Eclipse 3.2 patch wizard.
It uses a new Eclipse-aware workspace patch format that makes creating
and applying patches dead easy.
--
Mike Milinkovich wrote:
> I agree with Ed, Ed and Greg as well. None of us are fans of more process.
>
> But what I think Bjorn could have done to help was to explain his motivation
> for floating this idea. This idea didn't come up because we at the
> Foundation like to dream up excuses for more process. It came up because
> Bjorn is being asked by some PMCs to relax their own rules in the charters
> so that as new people are hired by companies that they can be simply added
> to the list of committers for projects.
>
> Since Bjorn is a much nicer guy than I am, he is exploring ideas that could
> achieve some sort of reasonable compromise. My answer would have actually
> been a lot simpler: no way. (Actually, as those who know me well realize I
> would have likely said it differently, but there might be kids reading
> this.)
>
> In my mind, Eclipse committer status means something much different than who
> your employer is. It is something that must be *earned* through *prior*
> contributions to a project, not a promise of future ones. It should never be
> given to someone simply because it is convenient. If we go down the path of
> convenience, we're headed for a world of hurt IMHO. As a general statement,
> I would actually prefer to see the bar raised higher before someone is
> granted committer status, not the other way around.
>
> But hey, the Eclipse Foundation is here to service its members, especially
> its committer members. So what do you guys think? Am I wrong?
>
>
|
|
|
| Re: Sponsored Committers? [message #32602 is a reply to message #32568] |
Thu, 06 April 2006 22:08 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
John,
Comments from me below...
John Arthorne wrote:
> I definitely don't agree with adding committers "for free" because
> they are paid to work on a project. Everyone should go through the
> same process to earn commit rights. If anything, I agree with Mike
> that the bar could actually be made higher, or at least require more
> evidence to be presented than "+1" when someone is being nominated.
I totally agree. I think important questions to ask are who should be
the judge and how should they judge? I feel it's in keeping with the
spirit of open source that the folks on the project who should
ultimately judge and that their freedom and discretion to judge the way
they see as most appropriate for their project at it's stage of
development should not be usurped. But I think that's your next point. ;-)
>
> Having said that, I think it should be at the discretion of the PMC.
> On some projects that are in very early stages, or in incubation areas
> of mature projects, it makes sense for PMCs to bootstrap the process
> by adding committers before they have established a track record. A
> safeguard that can be used here is to make those rights more
> fine-grained. For example Equinox has various incubation projects in
> the repository that are not part of the production code. The PMC will
> sometimes grant commit rights to new faces *only* in the incubation
> project to help get it started. When the code migrates into
> production, committers in the new location need to vote on whether
> commit rights should be granted for the incubation committers in the
> production code. This has a similar flavour to what Bjorn was
> suggesting: granting limited rights with less restrictions to help get
> projects going, and as a "career path" to earning the level of trust
> required for full-blown commit rights.
It certainly seems reasonable that folks might have access to only a
subset of the models.
>
>
> I'll also make a feature plug: if anyone complains that applying
> patches is too onerous, they likely aren't using the Eclipse 3.2 patch
> wizard. It uses a new Eclipse-aware workspace patch format that makes
> creating and applying patches dead easy.
I'll second that! It's such a wonderful time saving improvement. I
just love it!
> --
>
> Mike Milinkovich wrote:
>> I agree with Ed, Ed and Greg as well. None of us are fans of more
>> process.
>>
>> But what I think Bjorn could have done to help was to explain his
>> motivation for floating this idea. This idea didn't come up because
>> we at the Foundation like to dream up excuses for more process. It
>> came up because Bjorn is being asked by some PMCs to relax their own
>> rules in the charters so that as new people are hired by companies
>> that they can be simply added to the list of committers for projects.
>>
>> Since Bjorn is a much nicer guy than I am, he is exploring ideas that
>> could achieve some sort of reasonable compromise. My answer would
>> have actually been a lot simpler: no way. (Actually, as those who
>> know me well realize I would have likely said it differently, but
>> there might be kids reading this.)
>>
>> In my mind, Eclipse committer status means something much different
>> than who your employer is. It is something that must be *earned*
>> through *prior* contributions to a project, not a promise of future
>> ones. It should never be given to someone simply because it is
>> convenient. If we go down the path of convenience, we're headed for a
>> world of hurt IMHO. As a general statement, I would actually prefer
>> to see the bar raised higher before someone is granted committer
>> status, not the other way around.
>>
>> But hey, the Eclipse Foundation is here to service its members,
>> especially its committer members. So what do you guys think? Am I wrong?
>>
|
|
|
| Re: Sponsored Committers? [message #32637 is a reply to message #32430] |
Sun, 09 April 2006 15:01 |
| Eclipse User |
|
|
|
Originally posted by: dschaefer.qnx.com
Just to add my two cents :)
I think every project is different in its community and really needs to
be managed carefully and to the needs of that community.
As an example, when I first became the CDT project lead, there were very
few active committers on the CDT and it was in jeopardy of losing its
momentum. To help regain that momentum, I nominated a couple of
committers earlier than I may have when the CDT was in full swing a year
earlier. I've monitored their commits and their work has been more than
acceptable. And I think it did the trick since I now have a handful of
vendors that want to put bodies on the CDT.
To make sure each project is successful, you really need to leave the
management of those projects to the people who know best about what's
going on day to day in those projects. And that would be the committers
who have the responsibility for electing new committers.
And I agree with Ed, in the end, the project lead is mainly responsible
for what happens in the project and should be given the freedom to make
sure they can do whatever necessary to make sure the project is successful.
Cheers,
Doug
Mike Milinkovich wrote:
> I agree with Ed, Ed and Greg as well. None of us are fans of more process.
>
> But what I think Bjorn could have done to help was to explain his motivation
> for floating this idea. This idea didn't come up because we at the
> Foundation like to dream up excuses for more process. It came up because
> Bjorn is being asked by some PMCs to relax their own rules in the charters
> so that as new people are hired by companies that they can be simply added
> to the list of committers for projects.
>
> Since Bjorn is a much nicer guy than I am, he is exploring ideas that could
> achieve some sort of reasonable compromise. My answer would have actually
> been a lot simpler: no way. (Actually, as those who know me well realize I
> would have likely said it differently, but there might be kids reading
> this.)
>
> In my mind, Eclipse committer status means something much different than who
> your employer is. It is something that must be *earned* through *prior*
> contributions to a project, not a promise of future ones. It should never be
> given to someone simply because it is convenient. If we go down the path of
> convenience, we're headed for a world of hurt IMHO. As a general statement,
> I would actually prefer to see the bar raised higher before someone is
> granted committer status, not the other way around.
>
> But hey, the Eclipse Foundation is here to service its members, especially
> its committer members. So what do you guys think? Am I wrong?
>
>
|
|
|
| Re: Sponsored Committers? [message #32672 is a reply to message #32430] |
Sun, 09 April 2006 17:23 |
| Eclipse User |
|
|
|
Originally posted by: gwatson.lanl.gov
After reading over what I wrote, I realize that it can be taken
completely the wrong way. I wasn't suggesting in any way that just
because I hire someone to work on the project that they should
automatically become a committer, or that somehow the process should be
short circuited. What I meant was that the act of hiring someone does
imply a degree of trustworthiness which is the hallmark of obtaining
committer status, and that the process should take that into account.
That is what I meant by flexibility.
Sorry for not being clearer.
Greg
Mike Milinkovich wrote:
> I agree with Ed, Ed and Greg as well. None of us are fans of more process.
>
> But what I think Bjorn could have done to help was to explain his motivation
> for floating this idea. This idea didn't come up because we at the
> Foundation like to dream up excuses for more process. It came up because
> Bjorn is being asked by some PMCs to relax their own rules in the charters
> so that as new people are hired by companies that they can be simply added
> to the list of committers for projects.
>
> Since Bjorn is a much nicer guy than I am, he is exploring ideas that could
> achieve some sort of reasonable compromise. My answer would have actually
> been a lot simpler: no way. (Actually, as those who know me well realize I
> would have likely said it differently, but there might be kids reading
> this.)
>
> In my mind, Eclipse committer status means something much different than who
> your employer is. It is something that must be *earned* through *prior*
> contributions to a project, not a promise of future ones. It should never be
> given to someone simply because it is convenient. If we go down the path of
> convenience, we're headed for a world of hurt IMHO. As a general statement,
> I would actually prefer to see the bar raised higher before someone is
> granted committer status, not the other way around.
>
> But hey, the Eclipse Foundation is here to service its members, especially
> its committer members. So what do you guys think? Am I wrong?
>
>
|
|
|
| Re: Sponsored Committers? [message #32904 is a reply to message #32362] |
Fri, 14 April 2006 19:09 |
Tim Wagner
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
I like the idea of apprenticeships with limited rights and limited duration
when the project as a whole agrees that those individuals merit the
increased level of trust. However, to be meaningful, there cannot be an
unlimited number of "apprentices" relative to committers...perhaps a limit
of no more than one apprentice to every 3 committers?
"Bjorn Freeman-Benson" <bjorn.freeman-benson@eclipse.org> wrote in message
news:e0uhlo$rog$1@utils.eclipse.org...
> Ed, Greg,
> Thanks. And to keep the conversation going some of my opinions...
>
> Greg Watson wrote:
> > For example, if I hire someone to work on the project
> > then I don't want to wait months for them to achieve
> > commit status, ... The act of hiring them for the project
> > implies a level of 'trust',
>
> While that sounds good on the surface, it implies that
> "company X == Eclipse project Y" (or that a manager in
> company X gets to make decisions about Eclipse project Y).
> In open source land, it is the committers on project Y who
> grant rights for Y even if those committers do not work
> for the same company.
>
> Consider the situation where hiring manager Susan of
> Instantiations hires Tom to work at Instantiations on BIRT.
> (Just an example: I don't know any Susan who works for
> Instantiations.) Susan trusts Tom, clearly. But nobody on
> the BIRT project has heard of Tom (or Susan). So why should
> Tom be granted any rights on BIRT?
>
> So perhaps you mean "if the project lead of Eclipse project Y
> who works at company X hires somebody at company X to work on Y,
> then that new person is trusted"? But what about the non-X
> committers on project Y? Don't they get a say about whether the
> person is to be trusted?
>
> So perhaps you mean "if the project lead of Eclipse project Y
> who works at company X and all the Y committers work at X for
> the same project lead, then the new person should be given
> rights"? ...
>
> I think Ed had the right idea with (and my addition):
>
> > The key principle to my mind is that [ALL] existing members
> > of the project must be comfortable that a new member
> > is *trustworthy*.
>
> I like this idea. I like it so much that I think we should
> change the charters to say this and then to recommend (but
> not require) mechanisms that the project can use to ascertain
> the trust. An apprenticeship would be one. A previous
> history with the person (perhaps at a former project or job)
> would be another. And so on.
>
> How about others out there in the community? Does Ed's idea
> resonate with you?
|
|
| |
| Re: Sponsored Committers? [message #32975 is a reply to message #32939] |
Mon, 17 April 2006 18:21 |
| Eclipse User |
|
|
|
Originally posted by: john.eclipsefaq.org
Ward Cunningham wrote:
> I agree with John that this has the same feel as a Sponsored Committer.
> And, it does so without creating any burdensom formal mechanism. What I
> wonder, though, is do these "incubating" committers vote? Could one get
> away with casting the only -1? Has it ever happened?
>
I haven't seen this happen personally, but in theory it could.
Typically people only vote on issues in their work area, so while they
may cast a -1 on an issue in their incubator, they wouldn't typically
attempt to commandeer or veto work in other areas in the project. I
suspect if someone with rights in an incubator did try to veto
something, their arguments would be considered carefully, but ultimately
those with commit rights on the affected area would have the final say.
Note that in votes over commit rights, I believe the simple rule is (or
should be) that only those who have the commit rights in question have
the right to vote on adding a new committer. I.e., I should not be able
to cast a vote concerning commit rights I don't have myself.
--
|
|
|
| Re: Sponsored Committers? [message #33076 is a reply to message #32430] |
Wed, 19 April 2006 02:32 |
David Williams
Messages: 722
Registered: July 2009 |
Senior Member |
|
|
On Tue, 04 Apr 2006 20:38:58 -0400, Mike Milinkovich
<mike.milinkovich@eclipse.org> wrote:
> It came up because
> Bjorn is being asked by some PMCs to relax their own rules in the
> charters
> so that as new people are hired by companies that they can be simply
> added
> to the list of committers for projects.
I'm not sure if this has been covered by others, but, in my experience,
these sort of requests partially come up because the "create patch and
apply patch"
process seems "hard" for some folks, especially for rapidly changing
startup code.
In my experience, its not that bad once you learn ... and, if they haven't
learned that yet,
then I'd wonder if those folks are really ready to be turned loose -- but,
I also realize that's
easy for me to say, as I've been doing it for years ... I think harder for
new projects
and those new to Eclipse.
But, I can't help but wonder, is the "CVS Commit rights", and the "voting
rights"
mixed up and complicating this issue? I could envision a process of
getting cvs commit rights,
but not voting rights, and would still be responsibility of "voting
members" to "release"
code for a build, or for a true release. Just an idea.
|
|
|
| Re: Sponsored Committers? [message #33180 is a reply to message #33076] |
Wed, 19 April 2006 17:43 |
Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
David,
IMO, separating these two would be hard. Committer status is more than just
"commit rights" and "voting rights". Just one example: the entire Eclipse IP
policy assumes that the people who have committer status understand our
processes well and take care in what code is checked into CVS.
The point here is that committer status implies a degree of knowledge,
experience and trust upon which the whole community relies upon. It's
*supposed* to be hard to be an Eclipse committer. And any variation on a
"Committer Lite" theme calls that into question.
Just my $0.02 worth.
"David Williams" <david_williams@us.ibm.com> wrote in message
news:op.s78hctmmac05ss@dmw2t23.raleigh.ibm.com...
> But, I can't help but wonder, is the "CVS Commit rights", and the "voting
> rights"
> mixed up and complicating this issue? I could envision a process of
> getting cvs commit rights,
> but not voting rights, and would still be responsibility of "voting
> members" to "release"
> code for a build, or for a true release. Just an idea.
|
|
|
| Re: Sponsored Committers? [message #33216 is a reply to message #33180] |
Wed, 19 April 2006 19:19 |
| Eclipse User |
|
|
|
Originally posted by: markp.softlanding.com
Mike Milinkovich wrote:
> IMO, separating these two would be hard. Committer status is more
> than just "commit rights" and "voting rights". Just one example: the
> entire Eclipse IP policy assumes that the people who have committer
> status understand our processes well and take care in what code is
> checked into CVS.
>
> The point here is that committer status implies a degree of
> knowledge, experience and trust upon which the whole community relies
> upon. It's supposed to be hard to be an Eclipse committer. And any
> variation on a "Committer Lite" theme calls that into question.
>
> Just my $0.02 worth.
Just another thing to consider ... On the ALF project we have a bunch
of different people that are working together on various tasks, other
than perhaps whomever it was that started the project, I do not think
any of us have any kind of committer rights. This is fine, because
right now none of us are writing code or committing anything. And it
is hard to say who ultimately will be doing this stuff down the road.
However, not being a committer puts up a lot of barriers to having
people in the project work together.
1) We cannot use the Eclipse Wiki to collaborate on some of the
documents we want to post.
2) Similar to #1, there is no way to allow people to update/manage the
web site for the project.
3) I do not know how Bugzilla is managed but if we wanted to start
setting stuff up for that it would again force the existing committers
to do that.
It just seems like ideally there would be a way for the committers of
the ALF project to allow some of us to take on some of these
responsibilities without making us committers.
Of these, #1 is probably the main issue and the other two are
stretches. It would certainly help us to work together better as well
as produce some lasting documentation if we could use the Wiki. It
seems kind of natural that when a project is starting the initial
committers and people that started the project are going to be doing a
lot of the work. But, we are really putting a lot of burden on these
individuals by creating these barriers that prevent them from
offloading any of that work to other people that want to be involved.
Mark
|
|
| |
| Re: Sponsored Committers? [message #33423 is a reply to message #33248] |
Fri, 21 April 2006 19:43 |
Bjorn Freeman-Benson
Messages: 334
Registered: July 2009 |
Senior Member |
|
|
Thanks for all the feedback about Committer elections and Sponsored
Committers. I think the conversation has been very useful. Let me
summarize and then propose an action. First, the summary:
The general consensus is that an official second level of committer-ness
would not be good. However, at the same time the consensus is that we
need to change the election rules to retain the intent that being a
full-fledged committer is a privilege, while at the same time allowing
project leads flexibility in recruiting contributors and electing
committers.
I think we should do three things:
1. Change the election rule to be about trust (as Ed Merks suggested)
and then recommend various ways to demonstrate that trust (contribution
to the project; well know contributions elsewhere; etc.). We should also
highlight that hiring a new employee to company X does not automatically
qualify them for committer status.
2. Emphasize that you donÂt have to be committer to be a contributor. I
think there is not enough emphasis on the project websites, mailing
lists, and newsgroups around patch-based contributors  rather
everything is Âcommitters versus everyone elseÂ. Even EclipseCon is
that way: discounts for committers but not for contributors.
3. Emphasize fine-grained commit rights as a way to implement a trainee
committer status (as John Arthorne suggested). For example, a project
might start by providing commit rights to the website but require
patches for the code. Then, as the new committer shows merit, the
committers can vote to extend those rights to one module of the code;
and so on.
To this end, I am going to propose these changes (see the marked up
webpage
http://www.eclipse.org/technology/proposed-technology-charte r-changes.html)
to the Technology Charter (and, if successful, I will try to convince
other projects to adopt (with the Board's approval) similar changes).
The net of this should be to allow the flexibility that we all want
while still having rules to guide our community.
Comments? Critiques? Improvements? Still too heavy handed? Or perhaps
too lenient? Please let me know through this newsgroup.
|
|
|
| Re: Sponsored Committers? [message #33450 is a reply to message #33423] |
Fri, 21 April 2006 20:06 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Bjorn,
+1 for all these good ideas
Bjorn Freeman-Benson wrote:
> Thanks for all the feedback about Committer elections and Sponsored
> Committers. I think the conversation has been very useful. Let me
> summarize and then propose an action. First, the summary:
>
> The general consensus is that an official second level of
> committer-ness would not be good. However, at the same time the
> consensus is that we need to change the election rules to retain the
> intent that being a full-fledged committer is a privilege, while at
> the same time allowing project leads flexibility in recruiting
> contributors and electing committers.
>
> I think we should do three things:
>
> 1. Change the election rule to be about trust (as Ed Merks suggested)
> and then recommend various ways to demonstrate that trust
> (contribution to the project; well know contributions elsewhere;
> etc.). We should also highlight that hiring a new employee to company
> X does not automatically qualify them for committer status.
>
> 2. Emphasize that you donÂt have to be committer to be a contributor.
> I think there is not enough emphasis on the project websites, mailing
> lists, and newsgroups around patch-based contributors  rather
> everything is Âcommitters versus everyone elseÂ. Even EclipseCon is
> that way: discounts for committers but not for contributors.
>
> 3. Emphasize fine-grained commit rights as a way to implement a
> trainee committer status (as John Arthorne suggested). For example, a
> project might start by providing commit rights to the website but
> require patches for the code. Then, as the new committer shows merit,
> the committers can vote to extend those rights to one module of the
> code; and so on.
>
> To this end, I am going to propose these changes (see the marked up
> webpage
> http://www.eclipse.org/technology/proposed-technology-charte r-changes.html)
> to the Technology Charter (and, if successful, I will try to convince
> other projects to adopt (with the Board's approval) similar changes).
> The net of this should be to allow the flexibility that we all want
> while still having rules to guide our community.
>
> Comments? Critiques? Improvements? Still too heavy handed? Or perhaps
> too lenient? Please let me know through this newsgroup.
|
|
| | |
| Re: Sponsored Committers? [message #33552 is a reply to message #33423] |
Sat, 22 April 2006 15:59 |
| Eclipse User |
|
|
|
Originally posted by: gwatson.lanl.gov
I think this is a positive move to addressing some of the shortcomings
of the current charter. The distinction between contributor and
committer reflect the natural state of affairs. I was also commenting
to someone the other day that the current restrictions requiring
committer access to modify web pages and/or the wiki makes contribution
more difficult. I think a finer grained commit status would be a good
way to encourage contribution to a project.
A few comments on the new charter:
1. The statement '...nor it is a right based on employment by an Eclipse
Member company' could be extended to '... nor it is a right based on
employment by an Eclipse Member company or a company employing existing
committers'.
2. I would like to see the role of the Project Committers made more
explicit, as is done for the PMC. At the moment this is kind of spread
all over the place. E.g.:
Project Operation
Within the scope of the charter, it is the Project Committers who are
responsible for the day-to-day activities associated with the operation
and development of a Project. These activities include:
- establishing the Project goals and objectives
- providing leadership for the Project
- approving new committers, and changes in committer status
- monitoring project progress
- reporting to the PMC
- initiating release reviews
- maintaining Project infrastructure
- providing release, development, and test plans
- undertaking development to fulfill the Project goals
3. I would like it made clear that the PMC is responsible for ensuring
that the Projects adhere to the top level charter, and is the final
arbiter for decisions and/or disputes. However, the PMC does not get
involved in Projects day-to-day operational issues.
Regards,
Greg
Bjorn Freeman-Benson wrote:
> Thanks for all the feedback about Committer elections and Sponsored
> Committers. I think the conversation has been very useful. Let me
> summarize and then propose an action. First, the summary:
>
> The general consensus is that an official second level of committer-ness
> would not be good. However, at the same time the consensus is that we
> need to change the election rules to retain the intent that being a
> full-fledged committer is a privilege, while at the same time allowing
> project leads flexibility in recruiting contributors and electing
> committers.
>
> I think we should do three things:
>
> 1. Change the election rule to be about trust (as Ed Merks suggested)
> and then recommend various ways to demonstrate that trust (contribution
> to the project; well know contributions elsewhere; etc.). We should also
> highlight that hiring a new employee to company X does not automatically
> qualify them for committer status.
>
> 2. Emphasize that you donÂt have to be committer to be a contributor. I
> think there is not enough emphasis on the project websites, mailing
> lists, and newsgroups around patch-based contributors  rather
> everything is Âcommitters versus everyone elseÂ. Even EclipseCon is
> that way: discounts for committers but not for contributors.
>
> 3. Emphasize fine-grained commit rights as a way to implement a trainee
> committer status (as John Arthorne suggested). For example, a project
> might start by providing commit rights to the website but require
> patches for the code. Then, as the new committer shows merit, the
> committers can vote to extend those rights to one module of the code;
> and so on.
>
> To this end, I am going to propose these changes (see the marked up
> webpage
> http://www.eclipse.org/technology/proposed-technology-charte r-changes.html)
> to the Technology Charter (and, if successful, I will try to convince
> other projects to adopt (with the Board's approval) similar changes).
> The net of this should be to allow the flexibility that we all want
> while still having rules to guide our community.
>
> Comments? Critiques? Improvements? Still too heavy handed? Or perhaps
> too lenient? Please let me know through this newsgroup.
|
|
|
| Re: Sponsored Committers? [message #33586 is a reply to message #33423] |
Sun, 23 April 2006 01:17 |
David Williams
Messages: 722
Registered: July 2009 |
Senior Member |
|
|
On Fri, 21 Apr 2006 15:43:12 -0400, Bjorn Freeman-Benson
<bjorn.freeman-benson@eclipse.org> wrote:
>
> 2. Emphasize that you don't have to be committer to be a contributor. I
> think there is not enough emphasis on the project websites, mailing
> lists, and newsgroups around patch-based contributors -- rather
> everything is "committers versus everyone else". Even EclipseCon is that
> way: discounts for committers but not for contributors.
>
Bjorn, I think all your ideas are good and might help clarify some if the
issues and rules. But, here's a small little glitch related to the above
paragraph and the actual draft changes you link to.
The Eclipse Development Process
http://www.eclipse.org/org/documents/Eclipse%20Development%2 0Process%202003_11_09%20FINAL.pdf
Uses "developer" in the way you want to use "contributor", and it implies
"contributors" are the union of "developers" and "committers".
I think basically you would like to swap the definitions of "developer"
and "contributor", so that
"developers" are the union of "contributors" and "committers".
I think that's a fine change, and better lines up with the general
industry usage of the term "developer" and matches what most people mean
when they say "contributor".
But, I do think its important to actually change the Development Process
document first, or at the same time, you'd change your charter, just so we
have consistency through-out Eclipse documents.
And, actually, if you get the Developement Process document wording
changed first, that might go a long ways toward your goal of "try to
convince other projects to adopt". I think all your statements are
consistent with out goals and intents in WTP ... we have not currently
implemented "fine grained committer components", but have always known we
could and might have to some day ... and if it would help get more help,
who would argue with that! :)
|
|
|
| Re: Sponsored Committers? [message #33654 is a reply to message #33423] |
Wed, 26 April 2006 03:35 |
Tim Wagner
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
I don't know how you could enforce it at the Foundation level, but #3
(fine granularity) makes a lot of sense to me.
One way to implement that might be to have different rules (or perhaps
just social norms) for incubating projects versus graduated projects. In
WTP, e.g., I would be willing to vote yes on a committer to JSF with a
record of just a few months of contributions, because they wouldn't have
to (and would not be allowed to) modify the core WTP logic.
There are questions to be answered here: Particularly, what happens when
a project incubating as part of a top-level project graduates. Do the
committers automatically get full access rights at that point, or do
they retain their "playground" settings and have to apply again to
become a committer on the larger project?
There's also the meta question of whether the Foundation should have a
uniform policy here or whether this is explicitly being left to each
top-level project to decide/police on its own. If the latter, then we
should at a minimum press the projects to state explicitly somewhere
what their policy is.
Bjorn Freeman-Benson wrote:
> Thanks for all the feedback about Committer elections and Sponsored
> Committers. I think the conversation has been very useful. Let me
> summarize and then propose an action. First, the summary:
>
> The general consensus is that an official second level of committer-ness
> would not be good. However, at the same time the consensus is that we
> need to change the election rules to retain the intent that being a
> full-fledged committer is a privilege, while at the same time allowing
> project leads flexibility in recruiting contributors and electing
> committers.
>
> I think we should do three things:
>
> 1. Change the election rule to be about trust (as Ed Merks suggested)
> and then recommend various ways to demonstrate that trust (contribution
> to the project; well know contributions elsewhere; etc.). We should also
> highlight that hiring a new employee to company X does not automatically
> qualify them for committer status.
>
> 2. Emphasize that you donÂt have to be committer to be a contributor. I
> think there is not enough emphasis on the project websites, mailing
> lists, and newsgroups around patch-based contributors  rather
> everything is Âcommitters versus everyone elseÂ. Even EclipseCon is
> that way: discounts for committers but not for contributors.
>
> 3. Emphasize fine-grained commit rights as a way to implement a trainee
> committer status (as John Arthorne suggested). For example, a project
> might start by providing commit rights to the website but require
> patches for the code. Then, as the new committer shows merit, the
> committers can vote to extend those rights to one module of the code;
> and so on.
>
> To this end, I am going to propose these changes (see the marked up
> webpage
> http://www.eclipse.org/technology/proposed-technology-charte r-changes.html)
> to the Technology Charter (and, if successful, I will try to convince
> other projects to adopt (with the Board's approval) similar changes).
> The net of this should be to allow the flexibility that we all want
> while still having rules to guide our community.
>
> Comments? Critiques? Improvements? Still too heavy handed? Or perhaps
> too lenient? Please let me know through this newsgroup.
|
|
|
Goto Forum:
Current Time: Fri Apr 19 04:01:02 GMT 2024
Powered by FUDForum. Page generated in 0.03681 seconds |
] 
Search
Help
Register
Login
Home
