You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Tim Williams <wi...@gmail.com> on 2005/09/08 21:09:27 UTC
committer vs write access
At risk of keeping this going, I'll give my own thoughts on what
you've said. I've moved this out of the vote thread too.
> ****************************************************************
> As well I want to take the opportunity for to make a statement.
>
> I did a senseless comment on the beginning of this vote that did not
> reflect the situation that we now have. I was talking about simple
> committership when calling the vote. That was not correct as *I* really
> see it.
>
> Yes http://apache.org/foundation/how-it-works.html#roles defines the
> role committer as follow:
> "committer is a developer that was given write access to the code
> repository and has a signed Contributor License Agreement (CLA) on file.
> They have an apache.org mail address. Not needing to depend on other
> people for the patches, they are actually making short-term decisions
> for the project. The PMC can (even tacitly) agree and approve it into
> permanency, or they can reject it. Remember that the PMC makes the
> decisions, not the individual people."
>
> The thing that I do not like on this description is that is missing one
> important (and IMO the most important) point expressed by David in
> another thread:
> On Sat, 2005-09-03 at 10:18 +1000, David Crossley wrote:
> > We would not become "committers" at Lenya or Cocoon,
> > just get "svn access". To become committers proper
> > we would go there, participate on their mailing lists,
> > help users, be committed to the project, etc.
It is *not* missing that important point. In the definition, it says
commiter += developer -- meaning to get the full definition, one needs
to read them together. This is particularly important here because
developer is where the definition expects those community aspects to
happen. The definitions are rightfully based on meritorious
progression in the "roles". We're having this problem reconciling
non-developers, non-contributers having write access to the code
repository only because we're giving them write access without having
earned it the way others do by progressing from user->dev->committer.
I think the situation David is describing here lessen's significance
of ASF Committership. I mean shucks, if I've got svn write access
anyway, committer is just a title, not a role. They both can checkin
code but neither has a binding vote. I've asked twice now what the
*pragmatic* difference is between committer and "one who has svn
access".
> I miss in above official description the point to *be* committed and
> what this actually mean. David pinpointed this very nice. To *be*
> committer in a project means that you "participate on their mailing
> lists, help users, be committed to the project, etc."
see above
> I repeated our discussion about simple committership vs PMC on the lenya
> dev list. Michis answer seems very interesting in the light of the above
> said. http://marc.theaimsgroup.com/?l=lenya-dev&m=112539704200829&w=2
I read this as "why buy the cow, when you can get the milk for free".
If we trust them with write access to the code repo, then we should
trust their binding vote. Anything else is "club-ish" and subject I
think.
> He actually is using the official definition of the ASF to fuel his
> argumentation. That has the certain background that Michi has a company
> where they use lenya for customer projects. Now his employees are
> sending tons of patches everyday and we do not have the time/resources
> to cope with all of them. The solution of simple committership seems
> logical.
>
> Now let us recall what David said, to *be* committer in a project means
> that you "participate on their mailing lists, help users, be committed
> to the project, etc." The important point that I see in this is that
> David points out that the community building makes you a committer not
> so much the code contributions. This is as well my opinion. IMO we find
> a definition ASF wide to redefine the committer role.
>
> Clearly forrest committer are not automatically lenya committer and vice
> versa even if they meet the official ASF definition for this role. The
> situation we have now I see only as leveraging projects that have the
> same roots and were we can use synergy effects. Like stated by Ross it
> helps to just go ahead to apply your own patches on a "foreign" project
> where you have write access.
Is there anyone that would really apply patches to a "foreign" project
without being a "developer" in the true ASF sense of the word? I
doubt it. Our situation is a little different and more akin to GSoC
and could probably have been favorably solved in the same way Cocoon
did their GSoC folks.
> I actually using this right @cocoon to fix typos and small things in
> their code base. The argument that I could create a patch and attach it
> to the issue tracker is not logically for me, because even if it takes
> me "only" 3 minutes, it will at least take another 3 Minutes for the
> cocoon committer that is applying my patch. Now simple math tells us
> that with 10 patches we spend 60 min on something that would normally
> take less then 10 min if I am doing directly.
>
> As soon as I have bigger changes I will create a diff and ask on the dev
> list to discuss this patch before applying it. I even do it sometimes on
> lenya and if I would change the forrest core I will do it here.
>
> I hope that I clarified my sloppy comment.
>
> salu2
> --
> thorsten
>
> "Together we stand, divided we fall!"
> Hey you (Pink Floyd)
Anyway, I know that this sort of banter is being frowned upon of late,
but it's very interesting to me.
--tim
Re: Roles: user, committer, member, etc.
Posted by Leo Simons <ma...@leosimons.com>.
On Sat, Sep 17, 2005 at 10:16:52AM +0200, Bertrand Delacretaz wrote:
> Note that over at Cocoon we make an important distinction between
>
> a) having commit rights to the code repository
> and
> b) being a committer, in the sense of having a demonstrated committment
> to the project, voting rights, etc.
Excalibur is similar -- 'client' apache projects such as cocoon and james
get commit rights to the repository but are not "committers".
Gump is also similar -- all apache committers get commit rights to the
repository. I can't for the life of me remember the last time there was
something resembling a formal vote by "gump committers". I don't think
we really define "gump committer".
> I don't want to blur the picture, but it's important to make the
> distinction: committing code is only one of the ways in which a
> committer can help - at least in the Cocoon view of these things.
I don't think a somewhat blurred or non-standard picture here is all bad,
as long as its an actual picture.
ciao!
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Roles: user, committer, member, etc.
Posted by Thorsten Scherler <th...@apache.org>.
El sáb, 17-09-2005 a las 10:16 +0200, Bertrand Delacretaz escribió:
> Le 17 sept. 05, à 01:19, Thorsten Scherler a écrit :
> > ...I am actually unsure whether or not a committer role makes sense
> > because
> > e.g. the cocoon based projects have given the commit right to each
> > other. That means per definition of the role (that we have now) that
> > new
> > committer entering e.g. forrest will be as well committer to cocoon
> > without even to have to submit a single line of code....
>
> Note that over at Cocoon we make an important distinction between
>
> a) having commit rights to the code repository
> and
> b) being a committer, in the sense of having a demonstrated committment
> to the project, voting rights, etc.
That is the point. The definition on apache.org do not have this
distinction! You are a committer if you have a).
In forrest and lenya we see it like cocoon, but how can you explain that
to new committer that read
http://apache.org/foundation/how-it-works.html#roles
¿?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Roles: user, committer, member, etc.
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 17 sept. 05, à 01:19, Thorsten Scherler a écrit :
> ...I am actually unsure whether or not a committer role makes sense
> because
> e.g. the cocoon based projects have given the commit right to each
> other. That means per definition of the role (that we have now) that
> new
> committer entering e.g. forrest will be as well committer to cocoon
> without even to have to submit a single line of code....
Note that over at Cocoon we make an important distinction between
a) having commit rights to the code repository
and
b) being a committer, in the sense of having a demonstrated committment
to the project, voting rights, etc.
Lenya (I'm not sure about Forrest but it should be the same IMO)
committers currently get commit rights to the Cocoon repository as a
convenience, so that they can fix small things easily when needed, but
this does *not* make them committers in the sense of b).
Cocoon also has several committers who have not added a single line of
code to the project - they're here because they help the project go
forward in other valuable ways.
I don't want to blur the picture, but it's important to make the
distinction: committing code is only one of the ways in which a
committer can help - at least in the Cocoon view of these things.
-Bertrand
Re: Roles: user, committer, member, etc.
Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2005-09-12 at 19:16 +0800, Niclas Hedhman wrote:
> On Monday 12 September 2005 18:16, David Crossley wrote:
> > We seem to be having endless discussions at some
> > projects about what it means to be a committer and
> > a PMC member and an ASF member.
>
> Some "heavy-weighters" have been arguing for long that "committer" is not a
> role but a right/status, and that all committers should be PMC members. Not
> sure if such argument is still current or not though.
Consider the situation where a company is dedicated to a certain
project. Surely many patches will arise from the employees of the
company. That will become pretty soon overkill for existing committers
to apply those patches.
Now given them the right to commit their changes will help leverage the
work load of the project. Normally because it is their working job they
are more concerned about the code then the community.
We always state community is more important then code. Following this
thought would mean that this patch provider have to still learn the ASF
way and should not be PMC member. That is were the committer right comes
into play. That became IMO the incubation for PMC members. The new
committer are learning the responsibilities of a PMC member.
I am actually unsure whether or not a committer role makes sense because
e.g. the cocoon based projects have given the commit right to each
other. That means per definition of the role (that we have now) that new
committer entering e.g. forrest will be as well committer to cocoon
without even to have to submit a single line of code.
I see it more as right that makes IMO the following roles
user -> senior user (with commit rights)->PMC member->ASF member
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Roles: user, committer, member, etc.
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 12 September 2005 18:16, David Crossley wrote:
> We seem to be having endless discussions at some
> projects about what it means to be a committer and
> a PMC member and an ASF member.
Some "heavy-weighters" have been arguing for long that "committer" is not a
role but a right/status, and that all committers should be PMC members. Not
sure if such argument is still current or not though.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Roles: user, committer, member, etc.
Posted by Leo Simons <ma...@leosimons.com>.
On Tue, Sep 13, 2005 at 12:45:04PM -0700, Justin Mason wrote:
> > Indeed. I have a hunch that "re-inventing the collaboration wheel" is a
> > significant part of "the apache way". An organisational structure that
> > is completely patching itself at every level has a lot of appeal.
>
> Hmm. Why does constant change have a lot of appeal?
Not quite what I meant. I meant that it is good to have people thinking about
how they want to run their own project and it is good to give them some
leeway. And incorporating change as part of our processes is better than
setting things in stone.
Messiness and confusion seem to be a consequence. Those don't have much appeal
at all :-)
> We in SpamAssassin certainly found it confusing, for a while -- we assumed
> that there was some central thought about this, then realised that no,
> every project/subproject does it differently.
Indeed. Incubating a project at apache is hard, innit?
The SpamAssassin proved very capable of dealing with all the weirdness and
confusion and inconsistencies. I have the idea (not very founded on solid
research) spamassassin is doing well without requiring much "active
oversight" from other parties. I think that partly that may be because the
project was allowed to "carve out" its own space in the apache landscape,
perhaps taking its turn at defining some bits of what that landscape actually
is.
> It would be nice to have an "overview" doc on a wiki somewhere, describing
> different projects' approaches, to make this clear. It would be
> especially useful for incoming incubator projects, because in our
> experience it was a major stumbling block.
Aye. David has put in lots of work along these lines along with a handful of
other people. The "handful" is why there isn't better documentation.
I had hoped that the Incubator would be self-sustaining (in that people who
were brought in through new projects would stick around and be helping out
with incubation and other foundation-wide tasks). While there are some
obvious exceptions, it seems they really are exceptions to the rule.
cheers!
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Roles: user, committer, member, etc.
Posted by David Crossley <cr...@apache.org>.
Leo Simons wrote:
> David Crossley wrote:
> > One thing that is bothering at the ASF is not having a
> > clear definition of the various roles.
>
> Hmmm. I think there's a lot of people not bothered though.
> Not being clear may even serve a purpose.
>
> > We seem to be having endless discussions at some
> > projects about what it means to be a committer and
> > a PMC member and an ASF member.
>
> Indeed. I have a hunch that "re-inventing the collaboration wheel"
> is a significant part of "the apache way". An organisational
> structure that is completely patching itself at every level has a lot
> of appeal.
I partially agree. However when that re-invention occurs
because of poor documentation, then we have a sad state
of affairs.
It is interesting to look at the following woeful document
and its svn history (i.e. no changes since initial minor doc):
http://incubator.apache.org/learn/theapacheway.html
In particular see the last section. It encourages
new incubating projects to follow the "Jakarta way".
Not blaming Jakarta, but it seems silly to point to
an umbrella project as "the" way to do things.
> Other projects *never* discuss any of this. They just write code.
I wonder if these projects are bringing on new committers
and explaining the intricacies to them.
> > It seems that over the years too much distinction
> > has been made and some the roles have become confused.
> > For example [4] says that "committers" have the
> > right to vote on community-related decisions
> > and [5] has that as the PMC member.
>
> As the ASF has grown, it has also grown more formal. If you look back (for example) to the
> beginnings of java.apache.org and later jakarta.apache.org you'll see that there wasn't a whole lot
> of design to the seperation between these roles. Heh. java.apache.org was a rather sizeable
> trademark violation. Can you imagine something like that happening now?
>
> If you go a little further back in time, eg
>
> http://httpd.apache.org/dev/voting.html
>
> there is no definition of "committer" or "member" or "pmc", just "Apache Group members", which is
> not further defined.
>
> As Jakarta people "moved up the ranks" the process documentation written (I think by Jon Stevens
> initially) moved up with them. When that happened people disagreed with that process and it got
> patched. Some patches found their way back into the processes of various TLPs. Which bits hasn't
> been overly co-ordinated.
The mismatch has probably arisen because of the old
experiment with such "umbrella" projects.
> Compare
>
> http://httpd.apache.org/dev/guidelines.html
> http://jakarta.apache.org/site/management.html
> http://jakarta.apache.org/site/decisions.html
> http://ant.apache.org/bylaws.html
> http://xml.apache.org/guidelines.html
> http://maven.apache.org/contributing/help.html
> http://apr.apache.org/guidelines.html
> http://tcl.apache.org/about.rvt
> http://gump.apache.org/bylaws.html
> http://geronimo.apache.org/get-involved.html
> http://beehive.apache.org/contributors.html
> ...
>
> TCL talks of a "project maintainership committee". HTTPD still refers to "Apache Group" every now
> and then. Maven, SpamAssassin and Geronimo don't describe their processes at all on their website.
> XML says "The Chairman or any member may be removed from the PMC by a 3/4 vote of the PMC" which is
> false (the chairman is a board-appointed officer and cannot be removed by the PMC at all). Gump defines
> "committer" but doesn't actually really keep track of them (when gump went TLP there was really no
> initial list of people that might be considered PMC members) because all of Apache is allowed to
> mess around with the code. Beehive has 0 pages devoted to saying something like "get involved!", the
> only thing that comes close is a news blurb on their front page. SpamAssassin has a list of PMC
> members at the top of their CREDITS file with links to Amazon wishlists. That's smart innit! :-)
>
> There are only a few truly authoritive references:
>
> * http://www.apache.org/foundation/bylaws.html
> * http://www.apache.org/foundation/board/calendar.html
> * http://www.apache.org/licenses/
>
> I think none of these ever talk of "committers" formally.
>
> Also note that the second one specifically tasks new PMCs with defining their own bylaws, eg
>
> RESOLVED, that the initial XXX PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> XXX Project.
That is one reason that i am raising it. This job falls through
the gaps and seems to be why our communities are not functioning
properly.
> yet there are loads of projects that don't have anything marked as "bylaws". So we have a project
> going through two years of incubation and community building, then they are tasked with only a few
> things (oversight, project growth, establish bylaws) and they often fail 1/3 of that task.
>
> We have *loads* of inconsistencies, and a lot of the stuff on the main foundation site is not
> consistent with stuff on the pages of many TLPs. I don't think we're going to be able to solve that
> completely, and I think the incubator shouldn't task itself with that either.
So if not Incubator, then who? And if not, then we had
better remove the second paragraph of the Incubator
home page.
I wonder if it might be better to simply remove a stack
of that top-level documentation, particluarly this "Roles"
section of the "How it Works" document. Then simply say
"go see each project for their own guidelines".
However that puts a big load on each project to revisit
such definitions, particularly if they do not have active
mentors who have some insight into the rest of the ASF.
Ah. Going to board_minutes_2002_10_16.txt where the Incubator
was established ...
"educating new developers in the philosophy and guidelines
for collaborative development as defined by the members
of the Foundation".
That probably puts the ball back in the court of
the Incubator, because i don't see such guidelines
being developed elsewhere, other than Infrastructure
trying to dig themselves out of the hole.
> > I think that the first two sentences of the PMC
> > role in [5] need to move back into the Committer role.
>
> Hmm. That page does seem a little out-of-sync with common practice.
As i showed, it developed that way with influence
of Jakarta and my efforts to fine-tune the docs
may have exacerbated the situation.
> > The PMC role should then stress that it is up to
> > each project to define the composition of its PMC.
>
> Actually I think that is up to the VP for the project, formally,
> which was established through board resolution.
Yes, that is what i meant to say. Hopefully the chair
also has the support of the project.
> > If no-one says otherwise, then i will change that.
>
> I'm not saying otherwise :-)
>
> > I presume that even though committers can vote on
> > project decisions, it is still its PMC that has
> > the binding votes.
>
> Officially, "committer" does not exist, so, officially,
> a "committer" cannot do anything "binding" on behalf of the ASF.
> If someone uploads a release somewhere without a PMC vote,
> then that action is > not on behalf of the ASF. Etc.
>
> > Are there any other clarifications that are needed?
>
> I dunno. I don't know where you're coming from,
> eg I'm not too sure what problem you're solving.
My main issue is that the developer communities which
we are trying to encourage, are totally confused
about what it means to be a committer and PMC member.
The problem is exacerbated when we have an existing
committer from another project. They bring their
ways to the other project, and we go through another
endless discussion.
We are now seeing a new thing happening as a result
of the Google Summer of Code and other situations at
the Cocoon-based projects, which are introducing
concepts which might lead to classes of committers.
> Hope this helped a little, regardless :-)
It did. Said many of the things that i had left unsaid
and shows that confusion reigns. No wonder we have
a hard time incubating new projects, and then having
them run smoothly and understand what it means to be
a committer or a PMC member.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Roles: user, committer, member, etc.
Posted by Leo Simons <ma...@leosimons.com>.
On Mon, Sep 12, 2005 at 08:16:49PM +1000, David Crossley wrote:
> One thing that is bothering at the ASF is not having a
> clear definition of the various roles.
Hmmm. I think there's a lot of people not bothered though. Not being clear may even serve a purpose.
> We seem to be having endless discussions at some
> projects about what it means to be a committer and
> a PMC member and an ASF member.
Indeed. I have a hunch that "re-inventing the collaboration wheel" is a significant part of "the
apache way". An organisational structure that is completely patching itself at every level has a lot
of appeal.
Other projects *never* discuss any of this. They just write code.
> It seems that over the years too much distinction
> has been made and some the roles have become confused.
> For example [4] says that "committers" have the
> right to vote on community-related decisions
> and [5] has that as the PMC member.
As the ASF has grown, it has also grown more formal. If you look back (for example) to the
beginnings of java.apache.org and later jakarta.apache.org you'll see that there wasn't a whole lot
of design to the seperation between these roles. Heh. java.apache.org was a rather sizeable
trademark violation. Can you imagine something like that happening now?
If you go a little further back in time, eg
http://httpd.apache.org/dev/voting.html
there is no definition of "committer" or "member" or "pmc", just "Apache Group members", which is
not further defined.
As Jakarta people "moved up the ranks" the process documentation written (I think by Jon Stevens
initially) moved up with them. When that happened people disagreed with that process and it got
patched. Some patches found their way back into the processes of various TLPs. Which bits hasn't
been overly co-ordinated.
Compare
http://httpd.apache.org/dev/guidelines.html
http://jakarta.apache.org/site/management.html
http://jakarta.apache.org/site/decisions.html
http://ant.apache.org/bylaws.html
http://xml.apache.org/guidelines.html
http://maven.apache.org/contributing/help.html
http://apr.apache.org/guidelines.html
http://tcl.apache.org/about.rvt
http://gump.apache.org/bylaws.html
http://geronimo.apache.org/get-involved.html
http://beehive.apache.org/contributors.html
...
TCL talks of a "project maintainership committee". HTTPD still refers to "Apache Group" every now
and then. Maven, SpamAssassin and Geronimo don't describe their processes at all on their website.
XML says "The Chairman or any member may be removed from the PMC by a 3/4 vote of the PMC" which is
false (the chairman is a board-appointed officer and cannot be removed by the PMC at all). Gump defines
"committer" but doesn't actually really keep track of them (when gump went TLP there was really no
initial list of people that might be considered PMC members) because all of Apache is allowed to
mess around with the code. Beehive has 0 pages devoted to saying something like "get involved!", the
only thing that comes close is a news blurb on their front page. SpamAssassin has a list of PMC
members at the top of their CREDITS file with links to Amazon wishlists. That's smart innit! :-)
There are only a few truly authoritive references:
* http://www.apache.org/foundation/bylaws.html
* http://www.apache.org/foundation/board/calendar.html
* http://www.apache.org/licenses/
I think none of these ever talk of "committers" formally.
Also note that the second one specifically tasks new PMCs with defining their own bylaws, eg
RESOLVED, that the initial XXX PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
XXX Project.
yet there are loads of projects that don't have anything marked as "bylaws". So we have a project
going through two years of incubation and community building, then they are tasked with only a few
things (oversight, project growth, establish bylaws) and they often fail 1/3 of that task.
We have *loads* of inconsistencies, and a lot of the stuff on the main foundation site is not
consistent with stuff on the pages of many TLPs. I don't think we're going to be able to solve that
completely, and I think the incubator shouldn't task itself with that either.
> I think that the first two sentences of the PMC
> role in [5] need to move back into the Committer role.
Hmm. That page does seem a little out-of-sync with common practice.
> The PMC role should then stress that it is up to
> each project to define the composition of its PMC.
Actually I think that is up to the VP for the project, formally, which was established through board
resolution.
> If no-one says otherwise, then i will change that.
I'm not saying otherwise :-)
> I presume that even though committers can vote on
> project decisions, it is still its PMC that has
> the binding votes.
Officially, "committer" does not exist, so, officially, a "committer" cannot do anything "binding"
on behalf of the ASF. If someone uploads a release somewhere without a PMC vote, then that action is
not on behalf of the ASF. Etc.
> Are there any other clarifications that are needed?
I dunno. I don't know where you're coming from, eg I'm not too sure what problem you're solving.
Hope this helped a little, regardless :-)
cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Roles: user, committer, member, etc.
Posted by David Crossley <cr...@apache.org>.
(Hopefully this is the correct list for this topic.
The second paragraph on the Incubator website seems
to indicate so.)
One thing that is bothering at the ASF is not having a
clear definition of the various roles.
We seem to be having endless discussions at some
projects about what it means to be a committer and
a PMC member and an ASF member.
It seems that over the years too much distinction
has been made and some the roles have become confused.
For example [4] says that "committers" have the
right to vote on community-related decisions
and [5] has that as the PMC member.
I think that the first two sentences of the PMC
role in [5] need to move back into the Committer role.
The PMC role should then stress that it is up to
each project to define the composition of its PMC.
If no-one says otherwise, then i will change that.
I presume that even though committers can vote on
project decisions, it is still its PMC that has
the binding votes.
Are there any other clarifications that are needed?
Been using the waybackmachine to investigate older
versions of our website to try to see how these
roles developed ...
--------
[1]
http://web.archive.org/web/19991012213226/http://apache.org/foundation/FAQ.html#what
"Members" were mentioned here and in the bylaws.
"Each project is managed by a self-selected team of technical
experts who are active contributors to the project, according
to whatever guidelines for collaborative development are best
suited to that project."
--------
[2]
http://web.archive.org/web/20011204201948/http://www.apache.org/foundation/roles.html
The top-level website gained this "Roles" document
as the link "Management" on the left-hand menu.
The 'svn log' shows that this was modelled after
a similar document from Jakarta.
It defines various different roles: users, developers,
committers, PMC, Foundation members.
--------
[3]
http://web.archive.org/web/20040401225632/http://apache.org/foundation/roles.html
Later update of the Roles doc before merge with How-it-works.
--------
[4]
http://web.archive.org/web/20040610072506/http://www.apache.org/foundation/how-it-works.html#meritocracy
The initial version of the "How it works" doc.
Only mentioned "user, committer, member" as the "merit stages".
--------
At this stage we had two separate documents which described
the roles. So we tried to merge the two.
--------
[5]
http://www.apache.org/foundation/how-it-works.html#roles
This is today's document.
--------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: committer vs write access
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
> At risk of keeping this going, I'll give my own thoughts on what
> you've said. I've moved this out of the vote thread too.
It is a very important topic and it needs to keep going
until resolved.
In the earlier discussion, people referred to the website
definitions of roles as though they were official
cast-in-stone definitions. They are not. Just like any
other documentation, they are an effort made by a few
people to write things down and hopefully clarify.
Anyway, i have tried to take it to the general@incubator
list to see if we can get the definitions refined.
http://marc.theaimsgroup.com/?l=incubator-general&m=112652023010033
-David