Re: [PROPOSAL] Committer access and responsibilities...

[Pier Fumagalli]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Sat, 25 May 2002, Pier Fumagalli wrote:
> 
>>> If you are a commiter - you have the same rights with all other commiters.
>>> If you don't want to exercise some rights - it's your choice.
>> 
>> Hola, you tend to forget a part I'm stressing out quite hardly... It's not
>> only "rights"... It's also "dues", right?
> 
> Yes, the 'due' to spend weekends writing code or answering emails or
> reading flame wars.
> 
> Give me a break with the big 'due' to vote or have a say over how the
> project you're involved with.

And in fact, Costin, the big opposition you're going to get from me, will
always be on the fact that you are totally and utterly irresponsible towards
this community and the ASF... It's years that you're been told that, not
only from me, but from an extended number of people (do we want to get back
to the Tomcat 3.x/4.x flamewar? Read those comments)...

Anyway, nice talking to you (not).

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[costinm]

On Sat, 25 May 2002, Pier Fumagalli wrote:

> > If you are a commiter - you have the same rights with all other commiters.
> > If you don't want to exercise some rights - it's your choice.
> 
> Hola, you tend to forget a part I'm stressing out quite hardly... It's not
> only "rights"... It's also "dues", right?

Yes, the 'due' to spend weekends writing code or answering emails or 
reading flame wars. 

Give me a break with the big 'due' to vote or have a say over how the 
project you're involved with. 


Costin 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Pier Fumagalli]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> I do agree ( and I advocated for this a lot ) on lowering ( or
> eliminating) the walls between projects, so jakarta commiters can commit
> code in any jakarta project ( subject to the normal project rules ).
> Some people didn't agree with that even for commons, and I accepted the
> fact. 

Over my dead body.

> If you are a commiter - you have the same rights with all other commiters.
> If you don't want to exercise some rights - it's your choice.

Hola, you tend to forget a part I'm stressing out quite hardly... It's not
only "rights"... It's also "dues", right?

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Pier Fumagalli]

Henri Yandell <[EMAIL PROTECTED]> wrote:
> 
> +1.
> 
> Another example if I could. The job role of 'Java admin' is growing more
> and more at companies. Developers shouldn't be adminning things, but would
> you have your unix or oracle admin be the admin of the Java side with zero
> Java knowledge?
> 
> Jakarta houses the 'Java' community at Apache but there's no way for a
> Java admin to be a part of that community. Helping other admins, writing
> documentation, being a consumer at the coders. The only way it can happen
> is if they become a coder, and that's contrary to the concept of a Java
> admin.

That's where my career is going to lately, I didn't think about that in the
first place. I'm going to loose my "committer" status soon now that you make
me think about it! :) :) :)

> I think Pier's suggestion will help to grow the 'ownership' of the
> projects and the apache way of thinking to a larger audience.

Thanks...

> Some possible negatives:
> 
> With more non-codery people around, will the 'noise' level in mail lists
> be too high for coders to want to pay attention?
> [It already is getting that way I find. I delete entire threads if the
> first couple of mails are not of interest to me. It has to be retitled as
> with this email to make me realise there was more going on than the
> original mails. ]

That might as well happen, although I don't feel that there will be many in
one of the two categories without being a "committer". Probably a some more
in the "contributor" side of things (because of corporate involvement and
stuff), but not the other way around... But I believe that we shouldn't give
up this option...

> By growing a large community of non-coders, the coders could have less say
> in the product. Is this good/bad? How would the +1/-1 system work. Would
> votes be open to committers only in some instances, and to non-committing
> members only in others. Who votes membership vs committership vs
> contributorship?

Regarding votes, I believe that the votes for a particular codebase should
be open only to contributors only of that particular codebase, and that's it
(I'm not going to vote on Ant for example, or Turbine)... Votes regarding
accepting new codebases, starting new subprojects,  electing the PMC, that
should go only to members, not contributors...

My stance would be that if you start off being a contributor, no question
asked (from that point of view)... Patch contribute, do all you want and
need, you have fun? You want to spend more time on it and Jakarta is not
only something you're paid to work on? Kewl, just ask, could be fairly
automatic, it might as well happen automatically if someone "nominates" you
to do that... I don't think that a vote is even necessary to promote a
committer who wants to be a contributor, talk with someone who can sponsor
you, and I'll be fine...

For the ones who want to start as member, the procedure to become a
committer on one particular projects are already there, as if I wanted to
start giving some patches to (for example) Ant, and get involved with that
codebase...

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[costinm]

-1

If someone doesn't want to be involved in the voting - he can do exaclty
that, abstain. If someone doesn't want to support a particular release -
he can abstain from the release vote( or vote +-0 ). 

If you spend time and write code for a project and are willing to
maintain/support - and if the people on the project vote you in, 
you have the same rights as all the other people on that project.


I do agree ( and I advocated for this a lot ) on lowering ( or 
eliminating) the walls between projects, so jakarta commiters can commit 
code in any jakarta project ( subject to the normal project rules ).
Some people didn't agree with that even for commons, and I accepted the
fact. 

If you are a commiter - you have the same rights with all other commiters.
If you don't want to exercise some rights - it's your choice. 



Costin



On Sat, 25 May 2002, Pier Fumagalli wrote:

> Chatted with a lot of people, seen many, different development models, went
> around, asked, talked, and I believe I have a pretty decent picture, and
> maybe even a solution...
> 
> So the major topic of discussion is that I perceive a substantial difference
> between being able to commit code to a CVS repository, and being a
> "committer" committer, with all dues and responsibilities that this role
> concerns...
> 
> For example sometimes someone might want to have commit access just because
> he is working for a company that deals with a particular project in Apache
> (we've seen this happening several times with some projects such as Xerces
> and Tomcat), but he really doesn't care about the whole fuzz of Apache and
> stuff, and once the employment contract ends, the relationship with Apache
> terminates as well (I don't need to enumerate all those examples along those
> lines).
> 
> One other example, if we didn't have Henri building RPMs for basically all
> Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
> don't you think that he would deserve committer status even if he's not tied
> to any particular codebase? We had this "problem" in the current election of
> the members, Sally Khudairi: Sally doesn't code, but she was involved with
> the ASF since before it was even created as a press organizer. Does she
> deserve to be a member of the foundation? Even if she doesn't code? Yes she
> does, IMO (and she was elected and nominated a member today)...
> 
> So, IMO, there's a great difference between being a coder, and being a
> member of the Jakarta community, at least in my opinion. There might be
> coders who are not involved with the community, and there might be
> non-coders who are much involved with it, want to participate, are active
> and deserve to be committers...
> 
> Our current structure doesn't "allow" that to happen, both things. If you
> need to write code in a particular source-base, and you need CVS access, you
> are automagically made a committer, even if you don't care about much else,
> and if you're very much involved with the overall project, but not tied to
> ANY whatsoever codebase, and really, don't want / can't do it.
> 
> So, given this little background, I would like to ask to the PMC, and all
> other committers, if others agree that we should "splitting" the "committer"
> figure in two parts:
> 
> - contributor: a contributor is someone who has access to a particular CVS
> tree, but for any reason doesn't want/need to be involved with the whole
> Jakarta community. He just wants to code his little bit and live a long
> life.
> 
> - member: is someone who is involved with the Jakarta community, somehow,
> somewhere (might be just giving a great deal in supporting users of our
> projects, or providing extra value to projects, like guidance in respect to
> overall specifications, binary builds). He is effectively a member of the
> community and has all the rights and dues of every member, such as
> participate in the election of the PMC.
> 
> And redefining the figure of the "committer" as follows:
> 
> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and overlooking the
> code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
> 
> I believe this makes sense, more sense than what we have now, also because
> we've seen that happening in the ASF for the very first time with a
> non-coding member. Comments please?
> 
> Pier
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Henri Yandell]

+1.

Another example if I could. The job role of 'Java admin' is growing more
and more at companies. Developers shouldn't be adminning things, but would
you have your unix or oracle admin be the admin of the Java side with zero
Java knowledge?

Jakarta houses the 'Java' community at Apache but there's no way for a
Java admin to be a part of that community. Helping other admins, writing
documentation, being a consumer at the coders. The only way it can happen
is if they become a coder, and that's contrary to the concept of a Java
admin.

I think Pier's suggestion will help to grow the 'ownership' of the
projects and the apache way of thinking to a larger audience.

Some possible negatives:

With more non-codery people around, will the 'noise' level in mail lists
be too high for coders to want to pay attention?
[It already is getting that way I find. I delete entire threads if the
first couple of mails are not of interest to me. It has to be retitled as
with this email to make me realise there was more going on than the
original mails. ]

By growing a large community of non-coders, the coders could have less say
in the product. Is this good/bad? How would the +1/-1 system work. Would
votes be open to committers only in some instances, and to non-committing
members only in others. Who votes membership vs committership vs
contributorship?


None of them that hard to answer I imagine.

Hen

On Sat, 25 May 2002, Pier Fumagalli wrote:

> Chatted with a lot of people, seen many, different development models, went
> around, asked, talked, and I believe I have a pretty decent picture, and
> maybe even a solution...
>
> So, given this little background, I would like to ask to the PMC, and all
> other committers, if others agree that we should "splitting" the "committer"
> figure in two parts:
>
> - contributor: a contributor is someone who has access to a particular CVS
> tree, but for any reason doesn't want/need to be involved with the whole
> Jakarta community. He just wants to code his little bit and live a long
> life.
>
> - member: is someone who is involved with the Jakarta community, somehow,
> somewhere (might be just giving a great deal in supporting users of our
> projects, or providing extra value to projects, like guidance in respect to
> overall specifications, binary builds). He is effectively a member of the
> community and has all the rights and dues of every member, such as
> participate in the election of the PMC.
>
> And redefining the figure of the "committer" as follows:
>
> - committer: is a contributor, but also a member, therefore he has all the
> privileges and dues of a contributor (having CVS access, and overlooking the
> code he's contributing to) and of a member (can vote for PMCs, should
> participate and contribute to discussions on the overall structure of
> Jakarta).
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PROPOSAL] Committer access and responsibilities...

[Pier Fumagalli]

Chatted with a lot of people, seen many, different development models, went
around, asked, talked, and I believe I have a pretty decent picture, and
maybe even a solution...

So the major topic of discussion is that I perceive a substantial difference
between being able to commit code to a CVS repository, and being a
"committer" committer, with all dues and responsibilities that this role
concerns...

For example sometimes someone might want to have commit access just because
he is working for a company that deals with a particular project in Apache
(we've seen this happening several times with some projects such as Xerces
and Tomcat), but he really doesn't care about the whole fuzz of Apache and
stuff, and once the employment contract ends, the relationship with Apache
terminates as well (I don't need to enumerate all those examples along those
lines).

One other example, if we didn't have Henri building RPMs for basically all
Jakarta projects (and others), or if Henri wasn't a committer on Tomcat,
don't you think that he would deserve committer status even if he's not tied
to any particular codebase? We had this "problem" in the current election of
the members, Sally Khudairi: Sally doesn't code, but she was involved with
the ASF since before it was even created as a press organizer. Does she
deserve to be a member of the foundation? Even if she doesn't code? Yes she
does, IMO (and she was elected and nominated a member today)...

So, IMO, there's a great difference between being a coder, and being a
member of the Jakarta community, at least in my opinion. There might be
coders who are not involved with the community, and there might be
non-coders who are much involved with it, want to participate, are active
and deserve to be committers...

Our current structure doesn't "allow" that to happen, both things. If you
need to write code in a particular source-base, and you need CVS access, you
are automagically made a committer, even if you don't care about much else,
and if you're very much involved with the overall project, but not tied to
ANY whatsoever codebase, and really, don't want / can't do it.

So, given this little background, I would like to ask to the PMC, and all
other committers, if others agree that we should "splitting" the "committer"
figure in two parts:

- contributor: a contributor is someone who has access to a particular CVS
tree, but for any reason doesn't want/need to be involved with the whole
Jakarta community. He just wants to code his little bit and live a long
life.

- member: is someone who is involved with the Jakarta community, somehow,
somewhere (might be just giving a great deal in supporting users of our
projects, or providing extra value to projects, like guidance in respect to
overall specifications, binary builds). He is effectively a member of the
community and has all the rights and dues of every member, such as
participate in the election of the PMC.

And redefining the figure of the "committer" as follows:

- committer: is a contributor, but also a member, therefore he has all the
privileges and dues of a contributor (having CVS access, and overlooking the
code he's contributing to) and of a member (can vote for PMCs, should
participate and contribute to discussions on the overall structure of
Jakarta).

I believe this makes sense, more sense than what we have now, also because
we've seen that happening in the ASF for the very first time with a
non-coding member. Comments please?

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: