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

[Martin van den Bemt]

On Thu, 2002-05-30 at 01:49, Ted Husted wrote:
> 
> If you accept a nomination to be a committer, and gain CVS access, then
> you can apply your own patches. Since most of use the products we patch,
> this is an important benefit to most contributors. If you happen to see
> a patch from another contributor that you think is useful, you can apply
> that too. But none of us are obligated to do anything we don't want to
> do.

That will attract volunteers a great deal ;((.
The least "the project" (and therefor also you as a committer), has an
obligation to give a reasonable response to the effort taken. Clouding
the mailinglist with reminders (what some projects actually specifically
ask for), is actually not something I should invest my time in. 
Just a simple "we don't have time for it now, it is on the todo list..
", would do in many cases. 

So if you don't want to take that effort  : don't take up the
responsibility of being a committer. 

So the obligation to do something with it, is of the project and if you
are part of that you have an obligation. 

Mvgr,
Martin




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

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

[Steven Noels]

> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> Subject: Re: [PROPOSAL] Committer access and responsibilities...

> Strong case in pointthe jakarta.apache.org and 
> www.apache.org websites
> are built with Anakianot that XSLT crap.

[shrug]



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

[Andrew C. Oliver]

Sam Ruby wrote:

>Ted Husted wrote:
>  
>
>>I believe the fundamental principal behind our system is
>>
>>   Them that does the work makes the decisions.
>>
>>
>
>+1
>  
>
+1

>  
>
>>I believe a secondary principal behind our system is
>>
>>   Thanks for volunteering.
>>
>>
>
>+1
>  
>
+1

> - Sam Ruby
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




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

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

[Andrew C. Oliver]

Jon Scott Stevens wrote:

>on 5/29/02 1:47 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
>
>  
>
>>I got shot down by the POI community.
>>
>>
>
>Sounds like a common thread, eh?
>  
>
Not sure what you mean.  How's the bar doing?

-Andy

>;-)
>
>-jon 
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




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

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

[Jon Scott Stevens]

on 5/29/02 4:53 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Ted Husted wrote:
>> 
>> I believe the fundamental principal behind our system is
>> 
>>Them that does the work makes the decisions.
> 
> +1
> 
>> I believe a secondary principal behind our system is
>> 
>>Thanks for volunteering.
> 
> +1
> 
> - Sam Ruby

I can't agree more. Babble all day long about random crap, but when it comes
down to it, it is the people who actually do the work that make the
decisions.

I have proven this time and time again.

Strong case in pointthe jakarta.apache.org and www.apache.org websites
are built with Anakianot that XSLT crap.

;-)

-jon


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

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

[Sam Ruby]

Ted Husted wrote:
>
> I believe the fundamental principal behind our system is
>
>Them that does the work makes the decisions.

+1

> I believe a secondary principal behind our system is
>
>Thanks for volunteering.

+1

 - Sam Ruby


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

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

[Ted Husted]

I believe the fundamental principal behind our system is 

Them that does the work makes the decisions. 

Integrating code or documentation into CVS is work, and people who do
that work are entitled to be decision-makers. 

I believe a secondary principal behind our system is 

Thanks for volunteering.

If you think something needs to be done, then you volunteer to do it. 

So, as a committer, you can decide that something needs to be added or
changed, and then you can go ahead and do it. 

Most anything that needs to be done on a product, including the
documentationa and website, involves CVS. Doing and decision-making all
center on CVS. 

If you accept a nomination to be a committer, and gain CVS access, then
you can apply your own patches. Since most of use the products we patch,
this is an important benefit to most contributors. If you happen to see
a patch from another contributor that you think is useful, you can apply
that too. But none of us are obligated to do anything we don't want to
do.

If there are other ways to contribute to a product that don't involve
CVS, and the Committers to a product want to make someone a Committer in
recognition of their non-CVS contributions, that sounds fine to me. Just
because you have CVS access doesn't mean you have to use it. 

It's fun to talk about the obligations and responsibilites of
Committers, but the only real obligation is to commit your own stuff.
(Thanks for volunteering.)

Once someone is a Committer, I would also say that voting and handling
support issues on the lists is participating, and as long as they show
up once in a while to help out, AFAIC, they can keep their Committer
badge. 

So, I'm saying 

+ If you are working hard enough to need CVS access, you are working
hard enough to be a Committer. 
+ If you are making significant contributions to the product in ways
that don't require CVS access, sure, you can be a Committer too.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

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

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

[Jon Scott Stevens]

on 5/29/02 1:47 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:

> I got shot down by the POI community.

Sounds like a common thread, eh?

;-)

-jon 


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

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

[Andrew C. Oliver]

Jon Scott Stevens wrote:

>on 5/29/02 7:23 AM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
>
>  
>
>>to me the point that Pier was trying to get accross that I agreed with
>>is that there is sometimes work that happens
>>outside of CVS worthy of committership (and/or that should require
>>committership) irrelevant of CVS access.
>>
>>
>
>Yea, like that code that will auto-format your code on checkin that you
>threatened to write a month or so ago...
>
>;-)
>
>-jon (still waiting) stevens
>  
>
Not that it had anything to do with anything but

I got shot down by the POI community.  They don't want their code 
reformatted.Check the archives.
I began the proposal with "Any discussion regarding bracket placement 
automatically kills this proposal and
it shall be hereby recended"...

-Andy

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




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

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

[Jon Scott Stevens]

on 5/29/02 7:23 AM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:

> to me the point that Pier was trying to get accross that I agreed with
> is that there is sometimes work that happens
> outside of CVS worthy of committership (and/or that should require
> committership) irrelevant of CVS access.

Yea, like that code that will auto-format your code on checkin that you
threatened to write a month or so ago...

;-)

-jon (still waiting) stevens


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

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

[Andrew C. Oliver]

>
>
>  
>
>>>"Why is increased granularity in role/right/responsibility bad in
>>>general?"
>>>
>>>  
>>>
>>1. Because it is a cop out.  
>>
>>
>
>http://www.dictionary.com/search?q=cop%20out (I'm learning today =)
>
>which one do you mean?
>  
>
/**/
To avoid fulfilling a commitment or responsibility; renege: copped out 
on my friends; copped out by ducking the issue.

>  
>
>>2. If this is about community and not code then we want participating 
>>members in the community
>>
>>
>
>don't follow...you mean limited community participating should not be an
>option if you want right X?
>  
>
Yes.

>  
>
>>3. "granularity" is a clever way of putting it, but thats not what this 
>>is about
>>
>>
>
>I think there's a close relationship. You could also talk about
>decoupling, as Pier coined it, leading to:
>
>"Why is decoupling sets of rights/responsibilities from each other a bad
>thing?"
>
>Note that doing so would lead to an increase in "roles", ie a more
>granular system. Just my view of the world...
>  
>
No I think bestowing "committership" on people who have CVS-Like access 
(shell access is an equal amount of trust) is
different from bestowing committership without voting rights/etc.

>  
>
>>4. "Code dumps" are white elephants
>>
>>
>
>one does not automatically lead to another. Increased "granularity"
>("right/responsibility set decoupling") doesn't mean an increase in code
>dumps.
>  
>
That was your rationale for this.  

>  
>
>>5. Opening the floodgates to CVS is bad (for so many reasons),
>>
>>
>
>same as for 4.
>  
>
its still bad.

>  
>
>>6. If you trust them in the repository, you accept their code, then they 
>>should be part of the community,
>>
>>
>
>yes. But there are various ways of participating in the community. You
>can accept their code and trust them in the repository, and they can be
>a member of the community, and still not be a committer. Well, not now,
>but the thought is to change that.
>  
>
That is a bad idea.

>This is about the specific case of creating a role that provides cvs
>access and no other rights, though.
>  
>
give me a use case other than code dumps.  I see no compelling need for 
this.

>  
>
>>>  
>>>
>>I've explained this sufficiently in this and other emails.
>>
>>
>
>except I still don't get it =)
>  
>
I don't get why you'd want to effect this change. :-)

>  
>
>> I do not 
>>think defining a role for folks whose work is not CVS-based but just as 
>>relevant if its clearly defined.
>>
>>
>
>you ment to end with "is stupid/bad" or something, right? On that the
>two of us agree, then? (now for the rest of the world...)
>  
>
sorry I meant to say that non CVS-based "committers" should be 
recognized.  (shell access is just as big of
a trust thing as CVS access if not bigger)

>  
>
>> Overall I'm happy with the 
>>organization as it is and do not think it needs radical social engineering.
>>
>>
>
>of course. But maintainance is cool.
>  
>
only where needed.

-Andy

>cheers,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




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

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

[Leo Simons]

> Pragmatically I think if a community voted to temporarily grant access 
> to its CVS repository, I'll bet it
> could be done.

More than likely...point of discussing it is to try and reach an
agreement about whether it should be done...

> >"Why is increased granularity in role/right/responsibility bad in
> >general?"
> >
> 1. Because it is a cop out.  

http://www.dictionary.com/search?q=cop%20out (I'm learning today =)

which one do you mean?

> 2. If this is about community and not code then we want participating 
> members in the community

don't follow...you mean limited community participating should not be an
option if you want right X?

> 3. "granularity" is a clever way of putting it, but thats not what this 
> is about

I think there's a close relationship. You could also talk about
decoupling, as Pier coined it, leading to:

"Why is decoupling sets of rights/responsibilities from each other a bad
thing?"

Note that doing so would lead to an increase in "roles", ie a more
granular system. Just my view of the world...

> 4. "Code dumps" are white elephants

one does not automatically lead to another. Increased "granularity"
("right/responsibility set decoupling") doesn't mean an increase in code
dumps.

> 5. Opening the floodgates to CVS is bad (for so many reasons),

same as for 4.

> 6. If you trust them in the repository, you accept their code, then they 
> should be part of the community,

yes. But there are various ways of participating in the community. You
can accept their code and trust them in the repository, and they can be
a member of the community, and still not be a committer. Well, not now,
but the thought is to change that.

This is about the specific case of creating a role that provides cvs
access and no other rights, though.

> >"Why is defining a new role that is in between the currently defined
> >roles of contributor and committer in terms of rights and
> >responsibilities a bad thing?"
> >  
> >
> I've explained this sufficiently in this and other emails.

except I still don't get it =)

>  I do not 
> think defining a role for folks whose work is not CVS-based but just as 
> relevant if its clearly defined.

you ment to end with "is stupid/bad" or something, right? On that the
two of us agree, then? (now for the rest of the world...)

>  Overall I'm happy with the 
> organization as it is and do not think it needs radical social engineering.

of course. But maintainance is cool.

cheers,

- Leo



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

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

[Andrew C. Oliver]

Leo Simons wrote:

>On Wed, 2002-05-29 at 15:50, Paulo Gaspar wrote:
>  
>
>>Despite all the arguments I still can NOT see why it should be 
>>more complicated than this (Sam + Jon definitions).
>>
>>
>
>there's been numerous examples mentioned in this thread.
>
>Also, the system already _is_ more complicated than the definitions
>below. A committer can also vote for the PMC. Someone who wants to do
>administration/documentation but should not be trusted with CVS should
>not be made a committer, etc etc etc.
>\
>
Now that I can get my fingers around.  (not documentation as that does 
go in CVS).  Someone who administrates
all of the Mail servers, Bugzilla, etc etc.  Should be a committer, but 
should not require CVS access.

I propose the following solution.  Next time that is needed propose them 
a committer, vote them in and then do not
request CVS access for them.  Root won't do it unless asked.  I'll bet 
if you say "give everything but CVS access to",
"root" will serve the request!   (Simple, elegant, practical...it just 
won't do!)

>  
>
>>Probably the system is already as good as it can get.
>>
>>
>
>I think the underlying thoughts and the spirit of the system (like
>what's written below, the concepts of meritocracy, do-ocracy, trust,
>etc) are about as good as it gets. Implementation can always use some
>work ;)
>
>- Leo
>
>  
>
>>>"Anyone" can suggest a change.
>>>
>>>A "developer" can submit a patch.
>>>
>>>A "committer" can make it happen.
>>>
>>>;-)
>>>
>>>-jon
>>>  
>>>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




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

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

[Andrew C. Oliver]

Nicola Ken Barozzi wrote:

>From: "Leo Simons" <[EMAIL PROTECTED]>
>
>  
>
>>On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote:
>>
>>
>>> I don't think
>>>there is anything to forbid a community from temporarily granting CVS
>>>access.
>>>  
>>>
>>;)
>>
>>Well, I think our guidelines forbid us. You cannot give someone CVS
>>access without giving them all the committer rights and responsibilities
>>as well. That's the point of the discussion, innit?
>>
>>
>
>Yes, it is.
>
>I regard CVS as the heart of our system.
>
to me the point that Pier was trying to get accross that I agreed with 
is that there is sometimes work that happens
outside of CVS worthy of committership (and/or that should require 
committership) irrelevant of CVS access.

>Would you make a well known surgeon operate your heart without knowing him
>first, and being sure he can assist you afterwards?
>If you do, usually it's for emergencies... like wanting some 20MB patch to
>be in CVS and not having time to do it.
>  
>
>Personally, I would prefer not have the patch at all, if it means giving
>access to the CVS to someone you don't trust.
>And if you trust him, there is no time limit.
>Nothing prevents him from asking his account to be deleted anyway.
>  
>
Agreed.

>If you invite someone in the boat with you, it's because you think that
>he'll be part of the group, and share roles and responsibilities; I don't
>think we need technical "repairmen" here.
>I may be wrong, but for me it's a matter of trust, personal trust.
>  
>
Agreed.

>I have been contributing stuff to Cocoon since version 1.7, but never
>proposed as a comitter.
>Why?
>Because I wasn't ready for OS collaboration, and they didn't trust me.
>
>This made me stronger, and I learned a lot.
>Now you made me come in Avalon just on my word and good proposition, and
>this is something I will never forget. It has a very strong meaning for me.
>
>I would like that others have these possibilities, that have made me learn a
>lot.
>I'm afraid that having "technitians" would break up this system.
>  
>
Well spoken!

>--
>Nicola Ken Barozzi   [EMAIL PROTECTED]
>- verba volant, scripta manent -
>   (discussions get forgotten, just code remains)
>-
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




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

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

[Andrew C. Oliver]

>
>
>thought that was a special kind of elephant...
>
>http://www.dictionary.com/search?q=white%20elephant
>
>...does now.
>  
>
In some Asian cultures, a particularaly cruel way to blight someone you 
didn't like was to gift them a
white elephant.  They'd need to feed and take care of it because they 
were considered something sacred
and rare -- but an elephant eats a lotand well outputs a lot as well.

>  
>
>> I don't think
>>there is anything to forbid a community from temporarily granting CVS
>>access.
>>
>>
>
>;)
>
>Well, I think our guidelines forbid us. You cannot give someone CVS
>access without giving them all the committer rights and responsibilities
>as well. That's the point of the discussion, innit?
>  
>
Pragmatically I think if a community voted to temporarily grant access 
to its CVS repository, I'll bet it
could be done.

>Not going anywhere; I'd rather see an answer to:
>
>"Why is increased granularity in role/right/responsibility bad in
>general?"
>
1. Because it is a cop out.  
2. If this is about community and not code then we want participating 
members in the community
3. "granularity" is a clever way of putting it, but thats not what this 
is about
4. "Code dumps" are white elephants
5. Opening the floodgates to CVS is bad (for so many reasons),
6. If you trust them in the repository, you accept their code, then they 
should be part of the community, otherwise, you shouldn't accept either.

>
>and
>
>"Why is defining a new role that is in between the currently defined
>roles of contributor and committer in terms of rights and
>responsibilities a bad thing?"
>  
>
I've explained this sufficiently in this and other emails.  I do not 
think defining a role for folks whose work is not CVS-based but just as 
relevant if its clearly defined.  Overall I'm happy with the 
organization as it is and do not think it needs radical social engineering.

-Andy


>cheers,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




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

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

[Leo Simons]

On Wed, 2002-05-29 at 15:50, Paulo Gaspar wrote:
> Despite all the arguments I still can NOT see why it should be 
> more complicated than this (Sam + Jon definitions).

there's been numerous examples mentioned in this thread.

Also, the system already _is_ more complicated than the definitions
below. A committer can also vote for the PMC. Someone who wants to do
administration/documentation but should not be trusted with CVS should
not be made a committer, etc etc etc.

> Probably the system is already as good as it can get.

I think the underlying thoughts and the spirit of the system (like
what's written below, the concepts of meritocracy, do-ocracy, trust,
etc) are about as good as it gets. Implementation can always use some
work ;)

- Leo

> > "Anyone" can suggest a change.
> > 
> > A "developer" can submit a patch.
> > 
> > A "committer" can make it happen.
> > 
> > ;-)
> > 
> > -jon



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

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

[Leo Simons]

> > On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote:
> > >  I don't think
> > > there is anything to forbid a community from temporarily granting CVS
> > > access.
> >
> > ;)
> >
> > Well, I think our guidelines forbid us. You cannot give someone CVS
> > access without giving them all the committer rights and responsibilities
> > as well. That's the point of the discussion, innit?
> 
> Yes, it is.
> 
> I regard CVS as the heart of our system.
> Would you make a well known surgeon operate your heart without knowing him
> first, and being sure he can assist you afterwards?

This is somewhat different - no lives are at stake, the "operation" can
be reversed, etc etc.

> Personally, I would prefer not have the patch at all, if it means giving
> access to the CVS to someone you don't trust.
> And if you trust him, there is no time limit.
> Nothing prevents him from asking his account to be deleted anyway.
> 
> If you invite someone in the boat with you, it's because you think that
> he'll be part of the group, and share roles and responsibilities; I don't
> think we need technical "repairmen" here.
> I may be wrong, but for me it's a matter of trust, personal trust.

don't let a bad example get in the way of the general idea. You should
trust this person, and he should trust you. Making him a committer is
not the only way to express this trust.

> I have been contributing stuff to Cocoon since version 1.7, but never
> proposed as a comitter.
> Why?
> Because I wasn't ready for OS collaboration, and they didn't trust me.
> 
> This made me stronger, and I learned a lot.
> Now you made me come in Avalon just on my word and good proposition, and
> this is something I will never forget. It has a very strong meaning for me.

I can totally relate to that story...I probably wouldn't be here if I
hadn't, at one time, been welcomed in the same way.

> 
> I would like that others have these possibilities, that have made me learn a
> lot.
> I'm afraid that having "technitians" would break up this system.

You mean being proposed and accepting to be a "technitian" reduces
educational value for beginning OSS developers and reduces the drive for
them of becoming committers later?

that might just be true.

cheers,

- Leo



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

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

[Paulo Gaspar]

Despite all the arguments I still can NOT see why it should be 
more complicated than this (Sam + Jon definitions).


Probably the system is already as good as it can get.


Have fun,
Paulo Gaspar

> -Original Message-
> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 28, 2002 5:59 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Committer access and responsibilities...

...

> > 
> > A "developer" can suggest a change.
> > 
> > A "committer" can make it happen.
> > 
> > - Sam Ruby
> 
> "Anyone" can suggest a change.
> 
> A "developer" can submit a patch.
> 
> A "committer" can make it happen.
> 
> ;-)
> 
> -jon


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

[Nicola Ken Barozzi]

From: "Leo Simons" <[EMAIL PROTECTED]>

> On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote:
> >  I don't think
> > there is anything to forbid a community from temporarily granting CVS
> > access.
>
> ;)
>
> Well, I think our guidelines forbid us. You cannot give someone CVS
> access without giving them all the committer rights and responsibilities
> as well. That's the point of the discussion, innit?

Yes, it is.

I regard CVS as the heart of our system.
Would you make a well known surgeon operate your heart without knowing him
first, and being sure he can assist you afterwards?
If you do, usually it's for emergencies... like wanting some 20MB patch to
be in CVS and not having time to do it.

Personally, I would prefer not have the patch at all, if it means giving
access to the CVS to someone you don't trust.
And if you trust him, there is no time limit.
Nothing prevents him from asking his account to be deleted anyway.

If you invite someone in the boat with you, it's because you think that
he'll be part of the group, and share roles and responsibilities; I don't
think we need technical "repairmen" here.
I may be wrong, but for me it's a matter of trust, personal trust.

I have been contributing stuff to Cocoon since version 1.7, but never
proposed as a comitter.
Why?
Because I wasn't ready for OS collaboration, and they didn't trust me.

This made me stronger, and I learned a lot.
Now you made me come in Avalon just on my word and good proposition, and
this is something I will never forget. It has a very strong meaning for me.

I would like that others have these possibilities, that have made me learn a
lot.
I'm afraid that having "technitians" would break up this system.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

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

[Leo Simons]

On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote:
> 
> > Yeah, exactly. And what if there is someone who actually wants less
> > responsibility and less rights than a committer, but still more than a
> > contributor?
> > 
> 
> -1

why?

> Does the term "white elephant" mean anything to you?

thought that was a special kind of elephant...

http://www.dictionary.com/search?q=white%20elephant

...does now.

>  I don't think
> there is anything to forbid a community from temporarily granting CVS
> access.

;)

Well, I think our guidelines forbid us. You cannot give someone CVS
access without giving them all the committer rights and responsibilities
as well. That's the point of the discussion, innit?

> I would say such a "gift" should not be interpreted with the direct
> meaning of the word in German.  Such things usually are wrought with
> problems and with this person who dumps a bunch of code into your
> repository and leaves, well generally it reduces the quality of your
> codebase and no one who IS part of the community knows the code.

This is of course, generalising, and we're leading away from the
discussion here. I say we should evaluate role/right/responsibility
granularity, you write an example line of thought of a potential
candidate for a new role to illustrate you disagree, so I provide a
"counterexample".

Not going anywhere; I'd rather see an answer to:

"Why is increased granularity in role/right/responsibility bad in
general?"

and

"Why is defining a new role that is in between the currently defined
roles of contributor and committer in terms of rights and
responsibilities a bad thing?"

cheers,

- Leo



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

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

[Andrew C. Oliver]

> Yeah, exactly. And what if there is someone who actually wants less
> responsibility and less rights than a committer, but still more than a
> contributor?
> 

-1

> It is all about granularity: less rights, less responsibility.
> 
> > "Gee I'd like to dump my code
> > here and not bother with the community"
> 
> "Gee I've created this amazing forked version of your codebase (this
> amazing book about your project, ..., ...) and now got permission from
> my employer to contribute it back. This is quite a lot of stuff, you can
> find it at http://somewhere/ to look at. If you accept, do you want 20MB
> worth of patches or can you give me CVS access?"
> 
> What if the community would very much like you to provide that stuff,
> you're already committer in other apache projects, but have no time to
> support your submission for longer than, say, a month? Should you be
> committer for a month?
> 

Does the term "white elephant" mean anything to you?  I don't think
there is anything to forbid a community from temporarily granting CVS
access.

I would say such a "gift" should not be interpreted with the direct
meaning of the word in German.  Such things usually are wrought with
problems and with this person who dumps a bunch of code into your
repository and leaves, well generally it reduces the quality of your
codebase and no one who IS part of the community knows the code.


-Andy

> etc etc etc.
> 
> cheers,
> 
> - Leo
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Leo Simons]

> > Case can be made that since putting something in CVS is putting
> > something up for lazy majority vote (and I subscribe to that), this is
> > not a good 'use case'. But what is wrong with a role for people that
> > have the option to propose something for a lazy majority vote, and then
> > no right/obligation to actually vote on that 'something' or anything
> > else?
> > 
> 
> I think with rights comes responsibility.

Yeah, exactly. And what if there is someone who actually wants less
responsibility and less rights than a committer, but still more than a
contributor?

It is all about granularity: less rights, less responsibility.

> "Gee I'd like to dump my code
> here and not bother with the community"

"Gee I've created this amazing forked version of your codebase (this
amazing book about your project, ..., ...) and now got permission from
my employer to contribute it back. This is quite a lot of stuff, you can
find it at http://somewhere/ to look at. If you accept, do you want 20MB
worth of patches or can you give me CVS access?"

What if the community would very much like you to provide that stuff,
you're already committer in other apache projects, but have no time to
support your submission for longer than, say, a month? Should you be
committer for a month?

etc etc etc.

cheers,

- Leo



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

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

[Andrew C. Oliver]

On Tue, 2002-05-28 at 17:36, Leo Simons wrote:
> On Tue, 2002-05-28 at 14:20, Andrew C. Oliver wrote:
> > I totally disagree with everything you just said.
> 
> Uhm, I think you disagree with the idea "we should have
> 'developers/contributors' with CVS access who are not committers". I'm
> not sure whether I support that idea yet.
> 
> You also disagree with the other stuff I said?
> 
> > I do NOT think developers should be granted CVS access without voting 
> > rights.  Thats a cop out.  That says "Gee we trust you in CVS but don't 
> > want to give you the rights to control your work or give you any 
> > ownership in what you do".  If they are frequent enough committers to 
> > require CVS access...then they deserve the rights there under.
> 
> Missing the point I made that there might be people out there that want
> some of the rights that come with committer status, not caring about
> having all of them, while not wanting all of the duties that come with
> committer status.
> 

I want a million dollars with no responsibilities such as paying taxes
or any of that stuff.  With rights come responsibilities, such is life.

> Heck, I'll probably submit more than a few patches to centipede in the
> future; people will probably get tired of applying them and they might
> ask me to become a committer, to which I will say "no thanks" as I feel
> I have have no time to make that commitment. It'll still be easier for
> both the committers and me if I still get CVS access.
> 

Centipede is not a Jakarta project, and if the voting rules for
centipede are documented, I missed the link.  I think for the moment its
either common law or "understood" because nearly everyone there is a
committer on some Apache project somewhere.  

> I'm not saying we should allow it, just that there's two sides to the
> story.
> 

I'd in fact -1 the idea of giving you CVS access without agreeing to be
a committer.

Krysalis (from what I can tell) actually has a slightly different type
of committership.  One is a committer to all projects (meaning I get to
vote on Wings and Centipede both).

I think I may be (there) an excellent example of the type of "committer"
that Pier talks about.  I've actually committed 0 code to Wings or
Centipede.  All of my work has been in setup, publicising, cross
OS-testing, and well lots of little things that aren't code but that
well the project might not be where it is today had I not done them.  

> Case can be made that since putting something in CVS is putting
> something up for lazy majority vote (and I subscribe to that), this is
> not a good 'use case'. But what is wrong with a role for people that
> have the option to propose something for a lazy majority vote, and then
> no right/obligation to actually vote on that 'something' or anything
> else?
> 

I think with rights comes responsibility.  "Gee I'd like to dump my code
here and not bother with the community" I want a million dollars
without bothering with earning it or the taxes or jailtime or
whatever...

-Andy

> g'night,
> 
> - Leo
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Jon Scott Stevens]

on 5/28/02 12:12 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Leo Simons wrote:
>> 
>>> Since committing is voting, what I think what some people want is a
>>> non-vetoing Committer.
>> 
>> I think 'some people' don't see/don't agree to the "committing is
>> voting", and then what they want is a Developer-with-CVS-access, which
>> is more or less what they said.
>> 
>> "Committing is voting" is not reflected in our guidelines (at least I
>> couldn't find such a notion).
> 
> In projects like , any
> impleementation of an idea (as opposed to a simple patch) must be
> review-then-comment.  In most Jakarta subprojects, the norm is lazy
> consensus as defined in .
> 
> So, think of a commit as the first (any typically only) +1 most changes get.
> 
>>> Someone to do the work without sharing in the
>>> responsibility.
>> 
>> sounds like what we call "developer" in our guidelines ;)
> 
> A "developer" can suggest a change.
> 
> A "committer" can make it happen.
> 
> - Sam Ruby

"Anyone" can suggest a change.

A "developer" can submit a patch.

A "committer" can make it happen.

;-)

-jon


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

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

[Danny Angus]

I agree with andy to an extent here:


> I do NOT think developers should be granted CVS access without voting
> rights.


But do still believe that there ought to be a more restrictive set of
permissions, and responsibilities, for "entry level"  sub-project
membership, if entry level members buy-in to the project community they will
learn where to ask to be proposed for full membership.

I think its important, getting back to the cause of this discussion to
reconcile the two ideals of firstly letting sub-projects manage their own
entry criteria, and secondly still maintaining a real community amongst
those with a wider horizon.

The problem Pier raised can be summarised as the entrance criteria of Tomcat
being percieved as too low w.r.t. the benefits and responsibilities a
commiter has within the wider Jakarta community, while acknowleding that
raising the bar would be Jakarta unfairly restricting the freedom Tomcat
mambers have in running their own community.

d.


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

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

[Andrew C. Oliver]

I totally disagree with everything you just said.  I think "committer" 
status should be granted to folks who do *other* things outside of CVS. 
 But the key word is "Do".  So pretend for a second that Pier is *not 
otherwise* a comitter to Tomcat and wherever, he does a lot of other 
stuff like manage bugzilla.  And bugzilla...what a pain.  So I would say 
Pier should be granted some voting rights etc.  I think thats the goal 
here and I agree with to goal, but none of the proposals I've seen spell 
out tight enough constraints.  

I do NOT think developers should be granted CVS access without voting 
rights.  Thats a cop out.  That says "Gee we trust you in CVS but don't 
want to give you the rights to control your work or give you any 
ownership in what you do".  If they are frequent enough committers to 
require CVS access...then they deserve the rights there under.

-Andy

Leo Simons wrote:

>>Since this is a volunteer organization, and we all have other pressing
>>responsibilities, it is important that we do not encourage any systemic
>>bottlenecks.
>>
>>
>
>I wrote:
>"> > user: no rights, no responsibilities
>  
>
>>>developer: right to get quoted as author for authored pieces, no
>>>responsibility
>>>committer: right to vote as per voting guidelines, responsibility to
>>>sign and submit Contributor License Agreement
>>>pmc member: right and obligation to set overall project direction"
>>>  
>>>
>
>this is not quite reflective of our current situation. The term
>"developer" can sometimes be misleading ("contributor" would be better,
>perhaps), while "committer" perhaps should include some added guidelines
>wrt responsibilities.
>
>You might call the fact that these definitions are somewhat out of whack
>a "systemic bottleneck".
>
>  
>
>>Since committing is voting, what I think what some people want is a
>>non-vetoing Committer.
>>
>>
>
>I think 'some people' don't see/don't agree to the "committing is
>voting", and then what they want is a Developer-with-CVS-access, which
>is more or less what they said.
>
>"Committing is voting" is not reflected in our guidelines (at least I
>couldn't find such a notion).
>
>  
>
>>Someone to do the work without sharing in the
>>responsibility.
>>
>>
>
>sounds like what we call "developer" in our guidelines ;)
>
>  
>
>>Which is to say, we can reject what they do, but they
>>can't reject what we do. Personally, I would find that type of
>>master/slave relationship difficult to maintain in a volunteer 
>>organization like this. If you are working hard enough to need commit 
>>rights, you are working hard enough to have veto rights. 
>>
>>
>
>What if someone wants/needs commit rights but doesn't want the veto
>rights (and responsibilities)? The right to vote also means an
>obligation to vote/abstain. The implication of your statement is "if you
>are given cvs access, you should also take on the responsibility of
>voting".
>
>cheers,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




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

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

[Ted Husted]

I changed "Developer" to "Contributer" throughout the guidelines, if 
for no other reason than to match the terminology of the "Contributor 
License" distributed by the ASF.

Personally, I feel that the current guidelines do express the concept
that committing is voting by lazy consensus. That's why there is a 
lazy consensus: so we can propose, vote, and make-it-so in one fell 
swoop. Volunteer time is a precious resource and we need to make 
the most of it. 

A substantial patch to the guidelines was proposed some time ago that
might help clarify this and other fine points. 

http://jakarta.apache.org/site/proposal.html


-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Leo Simons wrote:
> this is not quite reflective of our current situation. The term
> "developer" can sometimes be misleading ("contributor" would be better,
> perhaps), while "committer" perhaps should include some added guidelines
> wrt responsibilities.
> 
> You might call the fact that these definitions are somewhat out of whack
> a "systemic bottleneck".
> 
> > Since committing is voting, what I think what some people want is a
> > non-vetoing Committer.
> 
> I think 'some people' don't see/don't agree to the "committing is
> voting", and then what they want is a Developer-with-CVS-access, which
> is more or less what they said.
> 
> "Committing is voting" is not reflected in our guidelines (at least I
> couldn't find such a notion).
> 
> > Someone to do the work without sharing in the
> > responsibility.
> 
> sounds like what we call "developer" in our guidelines ;)
> 
> > Which is to say, we can reject what they do, but they
> > can't reject what we do. Personally, I would find that type of
> > master/slave relationship difficult to maintain in a volunteer
> > organization like this. If you are working hard enough to need commit
> > rights, you are working hard enough to have veto rights.
> 
> What if someone wants/needs commit rights but doesn't want the veto
> rights (and responsibilities)? The right to vote also means an
> obligation to vote/abstain. The implication of your statement is "if you
> are given cvs access, you should also take on the responsibility of
> voting".
> 
> cheers,
> 
> - Leo
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

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

[Santiago Gala]

Sam Ruby wrote:

>Ted Husted wrote:
>  
>
>>Since committing is voting...
>>
>>
>
>+1
>  
>
You can look at it the other way round:

voting is (in a sense) committing (yourself) to the project. :-)

My itch is that I have been overwhelmed with work, to the point that I 
can barely follow the codebase or the dev list. I think that I will 
slowly find myself in a role in the project again, like:

- When the frenzy dies, I can review and debug (I'm quite good at 
debugging), and document things, and ask (and answer) nasty questions 
about product architecture or implementation.
- I can point to interesting ways to improve the project (functionality 
and/or architecture).
- I can have discussions on future changes, I keep global vision since 
I'm more detached, ...

I have been worried during this whole thread, because I feel that I'm 
losing grip of my involvements with Apache. I used to be able to track 
closely lists and codebases for cocoon, turbine, tomcat and jetspeed. 
Now I barely track Jetspeed. I felt like my involvement as committer was 
dying.

But thinking carefully after reading this thread, I think I agree with 
Andrew's comment: the system works, don't touch it.

If I am respectful and I don't touch the codebase without asking people 
(except obvious patches for typo/bug fixing or documentation), I can 
still be useful to the project. While my comments are good shaped and 
reasonable they will be taken into account and agreed. If I start doing 
unreasonable proposals or messing with code, -1s will appear, and a 
conflict will be raised.

I just wanted to point that, in addition to taking the 
developer/commiter role as something more than code shaping 
(documentation, proposals, design, etc.) tasks like teaching newbies in 
the lists or raising awareness about the projects, are valuable in 
themselves. But I would not mess with the current roles in Apache, 
except for raising awareness of the fact that there are things beyond 
code lines.

IMO, the key issues for having a working system are:

- openness
- openness
- openness

The only think that makes the system work is that all discussions (and 
the decision processes themselves) are held in the open, so that people 
can follow design intentions without needing to have explicit 
instructions, and so that proposals are kept in archives for future 
people to implement them. Also, only an open system enables us to build 
and maintain the trust and respect network for the project. Turning back 
to my itches, while I'm trusted and respected in the jetspeed team, my 
decisions will be heard and taken into account. Unless my contributions 
are really valuable, the trust will extinguish slowly as I fade. If my 
contributions are valuable, I will manage to keep a low profile and 
still be a respected developer/commiter/younameit (i.e. an active member 
of the community). I have seen this happening with other people, which 
have a varying involvement in terms of time, but always bring valuable 
material in, and they are respected even after disappearing during 
months from the list.

Pardon me for this kind of rant/public confession. ;)

Regards,
   Santiago (reading mail after weeks outside teaching java/Apache code)

>- Sam Ruby
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>  
>




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

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

[Sam Ruby]

Leo Simons wrote:
>
>> Since committing is voting, what I think what some people want is a
>> non-vetoing Committer.
>
> I think 'some people' don't see/don't agree to the "committing is
> voting", and then what they want is a Developer-with-CVS-access, which
> is more or less what they said.
>
> "Committing is voting" is not reflected in our guidelines (at least I
> couldn't find such a notion).

In projects like , any
impleementation of an idea (as opposed to a simple patch) must be
review-then-comment.  In most Jakarta subprojects, the norm is lazy
consensus as defined in .

So, think of a commit as the first (any typically only) +1 most changes get.

>> Someone to do the work without sharing in the
>> responsibility.
>
> sounds like what we call "developer" in our guidelines ;)

A "developer" can suggest a change.

A "committer" can make it happen.

- Sam Ruby


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

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

[Leo Simons]

> Since this is a volunteer organization, and we all have other pressing
> responsibilities, it is important that we do not encourage any systemic
> bottlenecks.

I wrote:
"> > user: no rights, no responsibilities
> > developer: right to get quoted as author for authored pieces, no
> > responsibility
> > committer: right to vote as per voting guidelines, responsibility to
> > sign and submit Contributor License Agreement
> > pmc member: right and obligation to set overall project direction"

this is not quite reflective of our current situation. The term
"developer" can sometimes be misleading ("contributor" would be better,
perhaps), while "committer" perhaps should include some added guidelines
wrt responsibilities.

You might call the fact that these definitions are somewhat out of whack
a "systemic bottleneck".

> Since committing is voting, what I think what some people want is a
> non-vetoing Committer.

I think 'some people' don't see/don't agree to the "committing is
voting", and then what they want is a Developer-with-CVS-access, which
is more or less what they said.

"Committing is voting" is not reflected in our guidelines (at least I
couldn't find such a notion).

> Someone to do the work without sharing in the
> responsibility.

sounds like what we call "developer" in our guidelines ;)

> Which is to say, we can reject what they do, but they
> can't reject what we do. Personally, I would find that type of
> master/slave relationship difficult to maintain in a volunteer 
> organization like this. If you are working hard enough to need commit 
> rights, you are working hard enough to have veto rights. 

What if someone wants/needs commit rights but doesn't want the veto
rights (and responsibilities)? The right to vote also means an
obligation to vote/abstain. The implication of your statement is "if you
are given cvs access, you should also take on the responsibility of
voting".

cheers,

- Leo



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

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

[Peter Donald]

On Tue, 28 May 2002 03:12, [EMAIL PROTECTED] wrote:
> On Sun, 26 May 2002, Peter Donald wrote:
> > + some mailing list management software + some product release software)
> > it would be very beneficial to push the administration down onto project
> > "leads"
>
> So we'll also have 'project leads' ?

we already do in practice. Some projects more so than others. As been stated 
before - Apache is a meritocracy, the more you contribute, the more 
responsibility and power you receive.

-- 
Cheers,

Peter Donald



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

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

[Sam Ruby]

Ted Husted wrote:
>
> Since committing is voting...

+1

- Sam Ruby


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

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

[Ted Husted]

I think the real point is that while, given the chance, some people may
prefer to do one thing or another, as Committers we all can potentially
do anything that needs to be done whenever we have time to do it. 

Since this is a volunteer organization, and we all have other pressing
responsibilities, it is important that we do not encourage any systemic
bottlenecks. If the Committer who likes to do the releases can't,
someone else can just step up to bat without any hoopla. A committer is
a committer .. from each according to their abilities, to each according
to their needs. 

Regardless of what we choose to do from time to time, the codebase is
our joint responsiblity. And when we drift away, someone else will step
into our shoes. When we are gone, another committer may elect to do what
we used to do, or a new contributor may fill the void and then be 
nominated as the product's newest Committer. 

The real problem I would have with non-voting Committers is that
comitting is an important way of how we vote. Because we are all
responsible for the entire codebase, jointly and severally, we don't 
have to vote on every little thing. We can vote through our commits -- 
unless and until another Committer points out an error in our judgment. 

Since committing is voting, what I think what some people want is a
non-vetoing Committer. Someone to do the work without sharing in the
responsibility. Which is to say, we can reject what they do, but they
can't reject what we do. Personally, I would find that type of
master/slave relationship difficult to maintain in a volunteer 
organization like this. If you are working hard enough to need commit 
rights, you are working hard enough to have veto rights. 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Leo Simons wrote:
> we have, in practice, in quite a few of the subprojects. The "in
> practice" part in that sentence explains the quotes around "leads".
> 
> We have a nice theoretical meritocracy model defining several "roles and
> responsibilities". That's just fine. The current model defines "user",
> "developer", "committer" and "pmc member".
> 
> In real life, there's more roles, overlapping roles, more specific
> roles, less specific roles.
> 
> Examples: with Avalon, Peter and Berin handle most of our releases; they
> assume the role of "release manager". Jeff Turner's been working on the
> build process; he had the cap of "build process manager", now passed
> over to Nicola Ken, all informally.
> 
> Fortunately, this is all okay and no-one complains. Like Ted said, we're
> pragmatic about it.
> 
> Thing is, formal roles and responsibilities currently are
> (as per http://jakarta.apache.org/site/roles.html):
> 
> user: no rights, no responsibilities
> developer: right to get quoted as author for authored pieces, no
> responsibility
> committer: right to vote as per voting guidelines, responsibility to
> sign and submit Contributor License Agreement
> pmc member: right and obligation to set overall project direction
> 
> when these no longer reflect the ad hoc pragmatic roles defined within
> subprojects, or when they make using these pragmatic "roles" difficult,
> we should think about changing these definitions, roles and
> responsibilities.
> 
> Fact of the matter is, the model is not perfect, and not everyone in our
> community fits into these categories very well. Saying that everyone who
> submits a patch is a developer is a bit of a strange definition, as you
> don't really "develop" documentation, etc etc etc.
> 
> Pier brings this up, perhaps in a somewhat clumsy way, but with a valid
> point and valid arguments: voila, heated discussion and comments on a
> personal note.
> 
> "if it ain't broken, don't fix it" leads to things like windows. We'd
> still be forced to work with AWT and JSP.
> 
> - Leo

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

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

[Leo Simons]

> > + some mailing list management software + some product release software) it 
> > would be very beneficial to push the administration down onto project "leads" 
> 
> So we'll also have 'project leads' ? 
>
> And some people who write and maintain code, but have different rights ?

we have, in practice, in quite a few of the subprojects. The "in
practice" part in that sentence explains the quotes around "leads".

We have a nice theoretical meritocracy model defining several "roles and
responsibilities". That's just fine. The current model defines "user",
"developer", "committer" and "pmc member".

In real life, there's more roles, overlapping roles, more specific
roles, less specific roles.

Examples: with Avalon, Peter and Berin handle most of our releases; they
assume the role of "release manager". Jeff Turner's been working on the
build process; he had the cap of "build process manager", now passed
over to Nicola Ken, all informally.

Fortunately, this is all okay and no-one complains. Like Ted said, we're
pragmatic about it.

Thing is, formal roles and responsibilities currently are
(as per http://jakarta.apache.org/site/roles.html):

user: no rights, no responsibilities
developer: right to get quoted as author for authored pieces, no
responsibility
committer: right to vote as per voting guidelines, responsibility to
sign and submit Contributor License Agreement
pmc member: right and obligation to set overall project direction

when these no longer reflect the ad hoc pragmatic roles defined within
subprojects, or when they make using these pragmatic "roles" difficult,
we should think about changing these definitions, roles and
responsibilities.

Fact of the matter is, the model is not perfect, and not everyone in our
community fits into these categories very well. Saying that everyone who
submits a patch is a developer is a bit of a strange definition, as you
don't really "develop" documentation, etc etc etc.

Pier brings this up, perhaps in a somewhat clumsy way, but with a valid
point and valid arguments: voila, heated discussion and comments on a
personal note.

"if it ain't broken, don't fix it" leads to things like windows. We'd
still be forced to work with AWT and JSP.

- Leo



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

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

[costinm]

On Sun, 26 May 2002, Peter Donald wrote:

> + some mailing list management software + some product release software) it 
> would be very beneficial to push the administration down onto project "leads" 

So we'll also have 'project leads' ? 

And some people who write and maintain code, but have different rights ?

Costin


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

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

[Ted Husted]

Personally, I would say the Jakarta system is most like a judicial
system. It's not the lawmaking or executive branch that is so often
exposed to democracy, but the judicial branch, which is often held above
democracy -- and in the US is used to keep the mob in check. 

Committers don't make laws, disburse funds, or arrest felons. They
simply judge whether code or documentation is product-worthy. 

What we do now is not democratic -- it's pragmatic. 

And so I would agree with Pier. Part of agreeing to be a Committer is
agreeing to weigh in, even if to abstain (+0). There is no provision for
removing a Committer for non-voting, but I would say that voting counts
as participating as to someone's active/inactive status. It may in fact
be a good idea for the release managers to ping any non-voting
Committers before moving forward, as has been done for PMC votes. =:0)

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Pier Fumagalli wrote:
>
> Being a committer (at least that's my idea), he doesn't only have the
> "right" to vote, but also the "due" to vote...
> 
> This is one of the fundamental concepts of any good democratic country. Are
> we undermining that?
> 
> Pier

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

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

[Fernandez Martinez, Alejandro]

Hi Andrew,

> -Mensaje original-
> De: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Enviado el: sábado 25 de mayo de 2002 18:39
> Para: Jakarta General List
> Asunto: Re: [PROPOSAL] Committer access and responsibilities...
> 
> From my understanding, in most European parliamentary democracies,
> generally you vote for more issue-oriented parties.  Even if 
> you "loose"
> you take a certain number of seats.  So it makes sense to vote
> regardless of whether its going to be a landslide.

In most European countries, voting is as irrelevant as it's in the States:
http://www.billionairesforbushorgore.com/
In Spain we've seen socialists undercutting social benefits and privatizing
public companies; and right-wing parties supporting abortion and promoting
public function. (Not a bad thing, necessarily, just a sign of the times).
I'm sure you can think of similar examples in your own countries.

The true strength of the Apache community is, IMHO, not in its democratic
values, but in the spirit of cooperation. Only when this fails, does the
result suck (Apache Axis comes to mind).

Un saludo,

Alex.

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

[Peter Donald]

Hi,

I would love to be able to give people partiial access to projects and I would 
also love to expire accounts if they are dormant or the person goes MIA.

For instance the first one would be especially useful in projects like ant, 
excalibur and commons. Many times in ant the committers have wanted to give a 
person access to a certain subtree in CVS because they contributed it and 
would be able to maintain it. ie Originally the Perforce tasks in Ant were 
largely contributed by a single individual and it would have been great if 
that person coul ddirectly maintain them.

However given that every new committer needs a new account on the boxen we 
never moved forward on it. When more appropriate infrastructure is put in 
place (Subversion - rah rah rah! Subversion - rah rah rah!) I think it would 
definetly be a good idea to do that. However that may put too big a burden on 
the system admins. 

When the new infrastructure is in place (think subversion, eyebrowse, scarab, 
+ some mailing list management software + some product release software) it 
would be very beneficial to push the administration down onto project "leads" 
and away from sys admins (who are prolly overloaded anyways). No one besides 
a select few would even need accounts.

Of course this needs a lot of volunteers to get started but until then I am 
not sure it would be possible to please everyone. However when thats in place 
all projects effectively manage themselves as they see fit.

On Sat, 25 May 2002 09:06, 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

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

[Fernandez Martinez, Alejandro]

Hi Pier,

> -Mensaje original-
> De: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
> Enviado el: sábado 25 de mayo de 2002 18:31
> Para: Jakarta General List
> Asunto: Re: [PROPOSAL] Committer access and responsibilities...

> Being a committer (at least that's my idea), he doesn't only have the
> "right" to vote, but also the "due" to vote...
> 
> This is one of the fundamental concepts of any good 
> democratic country. Are
> we undermining that?

All good democracies allow voters to abstain, for example if they don't care
a bit for the issue being voted on. Only dictatorships have mandatory votes.

Un saludo,

Alex.

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

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Saturday, May 25, 2002 9:17 PM
Subject: RE: [PROPOSAL] Committer access and responsibilities...


> On Sun, 26 May 2002, Ignacio J. Ortega wrote:
>
> > but all i can say from the history i know, that you are simply suffering
> > some kind of father syndrome, like those fathers that, when his children
>
> Stop reading Freud :-) !

Before Nacho kicked in, I was going for Jungian myself. :)

>
> We need to add as commiters not only a lawyer, but also a shrink now.
>

+1 for the shrink.  That way I might be able to get through my inbox in
finite time. ;-)

> Costin
>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

[Andrew C. Oliver]

On Sun, 2002-05-26 at 14:15, Nicola Ken Barozzi wrote:
> Well said.
> I subscribe to this.
> 
> We should remember that people that contribute so much should be proposed as
> committers, regardless to the code submitted, as is done AFAIK in POI,
> Struts, Cocoon, Forrest, Avalon, and the Krysalis projects (that refer to
> Apache guidelines).
> 

I dunno, I think there is a point... I would probably be reluctant to
ask for CVS access for someone whom I did not trust could use it
properly, but I think we'd still vote them a committerthen again I'd
-1 anyone being a committer who I didn't think had the good sense not to
play in CVS if they didn't know what they were doing...so its probably
moot.  

-Andy

> --
> Nicola Ken Barozzi   [EMAIL PROTECTED]
> - verba volant, scripta manent -
>(discussions get forgotten, just code remains)
> -
> 
> 
> - Original Message -
> From: "Ted Husted" <[EMAIL PROTECTED]>
> To: "Jakarta General List" <[EMAIL PROTECTED]>
> Sent: Sunday, May 26, 2002 6:59 PM
> Subject: Re: [PROPOSAL] Committer access and responsibilities...
> 
> 
> > Those who do the work of creating a Jakarta product are entitled to make
> > the decisions regarding that product. A successful product is more than
> > code, it also requires documentation and support and easy-to-use
> > distributions.
> >
> > Whether a patch is to the code or the documentation isn't relevant. A
> > patch is a patch, a contribution is a contribution, and anyone who
> > makes sustained contributions to a product is elligible to become a
> > committer.
> >
> > A change to the codebase can affect everyone, including them that don't
> > code but "simply" document. They should have as much to say about the
> > codebase as everyone else.
> >
> > The real point behind meritocracy, I believe, is that we are all equal
> > and there is no formal hierarchy. It's also a big part of what
> > makes Jakarta both fun and different from our regular jobs.
> >
> > We have a simple and effective system here that's been proven to work.
> > I don't believe that the formal system is broken or needs to be
> > refactored.
> >
> > -1 on there being shades of gray between contributors and committers.
> >
> > A contributor is anyone who has submitted code, documentation or
> > any other deliverable that has been made part of the product.
> > Committers do the work of creating the product by posting
> > contributions to the CVS or other secure area.
> >
> > +1 on "non-coders" or "specialists" being voted as committers when
> > the circumstances warrant. There is nothing to prevent this now
> > nor should there ever be. If its OK with the other committers to a
> > product, there's no reason for the rest of us to care. If it's not
> > OK with the other committers, then it is not the system that's
> > broken, but the committers -- and no amount of tinkering is going
> > to fix that.
> >
> > -- Ted Husted, Husted dot Com, Fairport NY US
> > -- Developing Java Web Applications with Struts
> > -- Tel: +1 585 737-3463
> > -- Web: http://husted.com/about/services
> >
> >
> >
> > 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 projec

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

[Nicola Ken Barozzi]

Well said.
I subscribe to this.

We should remember that people that contribute so much should be proposed as
committers, regardless to the code submitted, as is done AFAIK in POI,
Struts, Cocoon, Forrest, Avalon, and the Krysalis projects (that refer to
Apache guidelines).

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Sunday, May 26, 2002 6:59 PM
Subject: Re: [PROPOSAL] Committer access and responsibilities...


> Those who do the work of creating a Jakarta product are entitled to make
> the decisions regarding that product. A successful product is more than
> code, it also requires documentation and support and easy-to-use
> distributions.
>
> Whether a patch is to the code or the documentation isn't relevant. A
> patch is a patch, a contribution is a contribution, and anyone who
> makes sustained contributions to a product is elligible to become a
> committer.
>
> A change to the codebase can affect everyone, including them that don't
> code but "simply" document. They should have as much to say about the
> codebase as everyone else.
>
> The real point behind meritocracy, I believe, is that we are all equal
> and there is no formal hierarchy. It's also a big part of what
> makes Jakarta both fun and different from our regular jobs.
>
> We have a simple and effective system here that's been proven to work.
> I don't believe that the formal system is broken or needs to be
> refactored.
>
> -1 on there being shades of gray between contributors and committers.
>
> A contributor is anyone who has submitted code, documentation or
> any other deliverable that has been made part of the product.
> Committers do the work of creating the product by posting
> contributions to the CVS or other secure area.
>
> +1 on "non-coders" or "specialists" being voted as committers when
> the circumstances warrant. There is nothing to prevent this now
> nor should there ever be. If its OK with the other committers to a
> product, there's no reason for the rest of us to care. If it's not
> OK with the other committers, then it is not the system that's
> broken, but the committers -- and no amount of tinkering is going
> to fix that.
>
> -- Ted Husted, Husted dot Com, Fairport NY US
> -- Developing Java Web Applications with Struts
> -- Tel: +1 585 737-3463
> -- Web: http://husted.com/about/services
>
>
>
> 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

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

[Ted Husted]

Those who do the work of creating a Jakarta product are entitled to make 
the decisions regarding that product. A successful product is more than 
code, it also requires documentation and support and easy-to-use 
distributions. 

Whether a patch is to the code or the documentation isn't relevant. A 
patch is a patch, a contribution is a contribution, and anyone who 
makes sustained contributions to a product is elligible to become a 
committer. 

A change to the codebase can affect everyone, including them that don't
code but "simply" document. They should have as much to say about the
codebase as everyone else. 

The real point behind meritocracy, I believe, is that we are all equal
and there is no formal hierarchy. It's also a big part of what 
makes Jakarta both fun and different from our regular jobs. 

We have a simple and effective system here that's been proven to work. 
I don't believe that the formal system is broken or needs to be 
refactored.

-1 on there being shades of gray between contributors and committers. 

A contributor is anyone who has submitted code, documentation or 
any other deliverable that has been made part of the product. 
Committers do the work of creating the product by posting 
contributions to the CVS or other secure area. 

+1 on "non-coders" or "specialists" being voted as committers when 
the circumstances warrant. There is nothing to prevent this now 
nor should there ever be. If its OK with the other committers to a 
product, there's no reason for the rest of us to care. If it's not 
OK with the other committers, then it is not the system that's 
broken, but the committers -- and no amount of tinkering is going 
to fix that.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services



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:
> 
> - c

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

[Andrew C. Oliver]

> But Pier, it doesn't address your original problem though, does it?
> Which was about the "bar height", or how to encourage contributors, and
> increase the number of contributors without diluting, and clogging up, the
> community and decision making processes.
> 

Total and complete agreement.  Well said Sir.

-Andy

> d.
> 
> > - 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?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Danny Angus]

+0

I like this, I think it is needed, as it should help to extend the
experience and knowledge of the community by acknowledging the services of
non-coders.

I believe, though, that as sub-projects grow we will eventually need to
address the issue of scope, but in the meantime this would be an
improvement.

But Pier, it doesn't address your original problem though, does it?
Which was about the "bar height", or how to encourage contributors, and
increase the number of contributors without diluting, and clogging up, the
community and decision making processes.

d.

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













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

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

[costinm]

On Sun, 26 May 2002, Ignacio J. Ortega wrote:

> but all i can say from the history i know, that you are simply suffering
> some kind of father syndrome, like those fathers that, when his children

Stop reading Freud :-) ! 

We need to add as commiters not only a lawyer, but also a shrink now.

Costin


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

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

[Ignacio J. Ortega]

> De: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
> Enviado el: sábado 25 de mayo de 2002 19:52

> 
> If commit numbers are not so important (and I agree), what is 
> the way that
> this community has to decide whether a person is a committer 
> or not, given
> that as it is today, you're not recognized as a member of 
> this community if
> you don't have a CVS account, and your name is not listed in 
> $CVSROOT/avail
> 
> Pier

I Disagree completely..

Mail archives prove you wrong, althought many of the more vocal people
here are committers, nothing blocks anyone to give his opinion and his
vote,more this same thread proves you wrong too,  i can remember someone
someone was proposed last time as PMC member without being a committer..


I'm not the oldest here, 2'5 years, and my contributions are not bigger,
but all i can say from the history i know, that you are simply suffering
some kind of father syndrome, like those fathers that, when his children
grow up, doent want to loose the control they have over his lifes.

Your children is starting to be teenager, and hence dont feels his
father is so important or has the reason everytime, nor that is the
better and in addition is a little castrating as every father..  Well
time will get you to the right place.., now your children is walking on
the avenue ( making a girlfriend!!! :) and sometimes in the future, you
will get a friendship with him and he will learn to respect you..


Saludos ,
Ignacio J. Ortega


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

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

[costinm]

On Sat, 25 May 2002, Pier Fumagalli wrote:

> Nope, we shouldn't but we should give it to those who ARE interested in the
> future of Jakarta, or XML, and _do_stuff_ for those project, but are not
> "bound" to a particular codebase. We should change our "meter" from being
> you contribute CODE to the project, to you contribure WORK to the project.

AFAIK each project can decide and vote to give rights to anyone they
feel deserve it and puts work in the project.

There is no requirement that the work is Java or C - I think there are 
people who focus more on documentation and became commiters for that. It's 
up to each project to decide by the normal rules. 

If you want to propose a lawyer to become commiter on tomcat - I'll be 
more than +1 ( we need one to solve the mystery of the JMX and 
other licences, and that would be an important contribution and worth
of making him commiter ).

I don't think that having CVS access ( without knowing what CVS is )
will be a problem for him. And if he cares or not to vote - again
I don't care.

Costin


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

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

[costinm]

On Sat, 25 May 2002, Nicola Ken Barozzi wrote:

> > I respect Craig mostly for the quality of his code ( even if I prefer
> > different solutions and we disagree on many other things ), I respect
> > Sam the most for keeping a low-key as 'PMC president' ( I never saw
> > him use the 'I'm the PMC chair' as an argument ).
> >
> > A smart idea ( like the try/catch unrolling ) is as important as
> > 100s of commits fixing bugs or 100s of mails answering questions.
> 
> If commit numbers are not so important (and I agree), then why measure them
> at all?
> 
> BTW, this is not what you said some days ago:
> http://marc.theaimsgroup.com/?l=jakarta-general&m=102112907923436&w=2

I believe my message is:
http://marc.theaimsgroup.com/?l=jakarta-general&m=102130834717179&w=2

And I said exactly the same thing, that small commits are easier to 
review and putting a 'ranking' on a commiter ( by any criteria )
is bad ( not only number of commits - also age, how long he is commiter,
how many flame-wars he participates in or how many bugs he fixes, or 
anything else ). What it matter is that he moves the project forward
and contributes his time and inteligence to the community.  


Costin


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

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

[Nicola Ken Barozzi]

From: "Pier Fumagalli" <[EMAIL PROTECTED]>

> "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
>
> > It does have the right to vote, but it's not binding (at least this is
what
> > Stefano told me two weeks ago).
> >
> > I don't want developers that are not committers to vote: a vote is
important
> > for the future of the project, and the future of Apache.
> >
> > Should we give votes to developers that are not interested in the future
of
> > Apache?
>
> Nope, we shouldn't but we should give it to those who ARE interested in
the
> future of Jakarta, or XML, and _do_stuff_ for those project, but are not
> "bound" to a particular codebase.

In cocoon, we have a documentation team now.
Documentation is in CVS.

IMO all should be in CVS, which is the project store, or the mailing lists.

> We should change our "meter" from being
> you contribute CODE to the project, to you contribure WORK to the project.

You contribute work? Ok, then you become a committer, that gets the *right*
to use the CVS, not the *need*.
If we trust him, why not give him CVS commit access?

I don't understand what rights you want to give to these "developers but not
committers".

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

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

[Pier Fumagalli]

"Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:

> It does have the right to vote, but it's not binding (at least this is what
> Stefano told me two weeks ago).
> 
> I don't want developers that are not committers to vote: a vote is important
> for the future of the project, and the future of Apache.
> 
> Should we give votes to developers that are not interested in the future of
> Apache?

Nope, we shouldn't but we should give it to those who ARE interested in the
future of Jakarta, or XML, and _do_stuff_ for those project, but are not
"bound" to a particular codebase. We should change our "meter" from being
you contribute CODE to the project, to you contribure WORK to the project.

That's at least what I (and others) think should happen. I'll try to put
together a more "formal" proposal in the next few hours/days (now it's cats
time, food and entertainment is required by my two furry creeps)...

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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

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

[Nicola Ken Barozzi]

From: "Pier Fumagalli" <[EMAIL PROTECTED]>

> "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
>
> > What is the way that *any* community decides in voting?
> >
> > You *are* a member of the community even if you do not have an account.
> >
> > http://xml.apache.org/roles.html   :
> > "
> > Developers
> >
> > Developers are the people who write code or documentation patches or
> > contribute positively to the project in other ways. A developer's
> > contribution is always recognized. In source code, all developers who
> > contribute to a source file may add their name to the list of authors
for
> > that file.
> > "
> >
> > A developer *is* part of the community.
> >
> > This is how it works on the Cocoon, Forrest and POI projects AFAIK.
> >
> > It seems that you are trying to put on paper that developers that are
not
> > committers have to be listed.
> >
> > It can be done, but why?
>
> Nicola, you might as well ask Stefano who wrote that page... I want to
point
> out one little paragraph below the one you mentioned:
>
> "A Committer has write access to the source code repository and gains
voting
> rights allowing them to affect the future of the subproject."
>
> A developer, at the end of the day, doesn't have the right to vote. When
it
> comes to numbers, he is worth less than zero... I'm sorry, but this is how
> OUR reality is right now, because we didn't think about it in the first
> place when this project (or XML) were founded (and you can trust me
because
> I was there, both times)...

It does have the right to vote, but it's not binding (at least this is what
Stefano told me two weeks ago).

I don't want developers that are not committers to vote: a vote is important
for the future of the project, and the future of Apache.

Should we give votes to developers that are not interested in the future of
Apache?

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

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

[Pier Fumagalli]

"Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:

> What is the way that *any* community decides in voting?
> 
> You *are* a member of the community even if you do not have an account.
> 
> http://xml.apache.org/roles.html   :
> "
> Developers
> 
> Developers are the people who write code or documentation patches or
> contribute positively to the project in other ways. A developer's
> contribution is always recognized. In source code, all developers who
> contribute to a source file may add their name to the list of authors for
> that file.
> "
> 
> A developer *is* part of the community.
> 
> This is how it works on the Cocoon, Forrest and POI projects AFAIK.
> 
> It seems that you are trying to put on paper that developers that are not
> committers have to be listed.
> 
> It can be done, but why?

Nicola, you might as well ask Stefano who wrote that page... I want to point
out one little paragraph below the one you mentioned:

"A Committer has write access to the source code repository and gains voting
rights allowing them to affect the future of the subproject."

A developer, at the end of the day, doesn't have the right to vote. When it
comes to numbers, he is worth less than zero... I'm sorry, but this is how
OUR reality is right now, because we didn't think about it in the first
place when this project (or XML) were founded (and you can trust me because
I was there, both times)...

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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

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

[Nicola Ken Barozzi]

From: "Pier Fumagalli" <[EMAIL PROTECTED]>

> "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
>
> > If commit numbers are not so important (and I agree), then why measure
them
> > at all?
>
> If commit numbers are not so important (and I agree), what is the way that
> this community has to decide whether a person is a committer or not, given
> that as it is today, you're not recognized as a member of this community
if
> you don't have a CVS account, and your name is not listed in
$CVSROOT/avail

What is the way that *any* community decides in voting?

You *are* a member of the community even if you do not have an account.

http://xml.apache.org/roles.html   :
"
Developers

 Developers are the people who write code or documentation patches or
contribute positively to the project in other ways. A developer's
contribution is always recognized. In source code, all developers who
contribute to a source file may add their name to the list of authors for
that file.
"

A developer *is* part of the community.

This is how it works on the Cocoon, Forrest and POI projects AFAIK.

It seems that you are trying to put on paper that developers that are not
committers have to be listed.

It can be done, but why?

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

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

[Pier Fumagalli]

"Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:

> If commit numbers are not so important (and I agree), then why measure them
> at all?

If commit numbers are not so important (and I agree), what is the way that
this community has to decide whether a person is a committer or not, given
that as it is today, you're not recognized as a member of this community if
you don't have a CVS account, and your name is not listed in $CVSROOT/avail

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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

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

[Martin van den Bemt]

On Sat, 2002-05-25 at 19:03, Andrew C. Oliver wrote:
> The action worthy of merit being: Surviving adolescence?

Too many words I need a dictionary for ;)) (it's hard to discuss stuff
you have to get out of a dictionary, so I will not try that)
I will conclude this day of way too little coding by using the footer I
just seen on Nicola's mail : 

- verba volant, scripta manent -
   (discussions get forgotten, just code remains)

Let's I made the choice to remain ;).


Mvgr,
Martin van den Bemt 


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

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

[Nicola Ken Barozzi]

From: <[EMAIL PROTECTED]>

> On Sat, 25 May 2002, Pier Fumagalli wrote:
>
> > Just need to grep the right files... You are a good committer, I see
that
> > you have 2342 commits into the turbine CVS. Good.
> >
> > I still beat you, overall I'm at 10717, Andy is at 2666 (Andy you're so
> > lazy), but hear hear, Costin has 25871, beating Craig who is just at
22712,
> > and our president (Sam) at 60869... Yes yes, he deserves to be the PMC
> > president just for that...
>
> I don't think anyone can find a mail from Craig or Sam (or me) 'bragging'
> about the number of commits or how important of contribution we make and
> how people who contribute 'less' should pay attention.
>
> I respect Craig mostly for the quality of his code ( even if I prefer
> different solutions and we disagree on many other things ), I respect
> Sam the most for keeping a low-key as 'PMC president' ( I never saw
> him use the 'I'm the PMC chair' as an argument ).
>
> A smart idea ( like the try/catch unrolling ) is as important as
> 100s of commits fixing bugs or 100s of mails answering questions.

If commit numbers are not so important (and I agree), then why measure them
at all?

BTW, this is not what you said some days ago:
http://marc.theaimsgroup.com/?l=jakarta-general&m=102112907923436&w=2

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

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

[Andrew C. Oliver]

On Sat, 2002-05-25 at 12:53, Martin van den Bemt wrote:
> > its a meritocracy. 
> 
> Thanx to the Oxfort dictionary I know what it is.. But all democracies
> are actually meritocracies according to the dictionary, they select you
> to be able to vote when 18+. But this is getting way to Off-Topic I
> guess... ;))
> 

The action worthy of merit being: Surviving adolescence?

> Mvgr,
> Martin
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Nicola Ken Barozzi]

From: "Pier Fumagalli" <[EMAIL PROTECTED]>

> "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
> > From: "Pier Fumagalli" <[EMAIL PROTECTED]>
> >
> >> Being a committer (at least that's my idea), he doesn't only have the
> >> "right" to vote, but also the "due" to vote...
> >>
> >> This is one of the fundamental concepts of any good democratic country.
> >> Are we undermining that?
> >
> > No, it isn't.
> > In a true democracy, one has the right to abstain.
>
> Correct... In every official Apache ballot (foundation crap, legal stuff),
> you always have three options:
>
> [ ] Yes
> [ ] No
> [ ] Abstain
>
> But I feel it's a due for all foundation members to at least tick one of
> those boxes (got upset with a couple of very close friends of mine because
> they didn't show up at the members meeting last week)...
>
> You can abstain, but you shouldn't "ignore"...
>
> 
> Democraticamente parlando, cos'e` piu` giusto, votare scheda bianca o
> non andare a votare?
> 

 
 Democraticamente parlando, cos'e` piu` giusto, votare scheda bianca o
 non andare a votare?
 

Dipende dal messaggio che vuoi dare...

> (Translated it would sound like: what's more "right" democratically
> speaking, going to poll booth and put in an unticked voter's card, or not
> even caring about going to vote? - But I don't know if it makes sense in
> English... Andy?)

I always thought that voters has at least a "moral" due to vote.

But I have noted that when a democtratic system is sane, the percentages of
the two major parties are similar.
This keeps a healthy tension between them, that keeps the actions of the
ruling party in control.

I have also noted that high turnouts usually mean that the voters are upset
by something, or that the vote is particularly important.
These cases usually involve a lot of tensions.

Out of these simple observations, I have cone not to disdain low turnouts,
and appreciate the fact that there are really 4 votes:

 [ ] Yes
 [ ] No
 [ ] Abstain
 [ ] whatever

Don't we have a similar system (the +-0 is even more)?

+1
-1
+-0
no vote

These votes are different in meaning:

 [ 3] Yes
 [ 1] No
 [ 10] Abstain
 [ 1] Whatever

(I want you to take a decision on this matter, but I don't know what is
best; please try to lobby the -1 or find a compromise)

 [ 3] Yes
 [ 1] No
 [1] Abstain
 [10] Whatever

(I don't care whatever happens, you could even not decide on this issue and
drop it: if there is a -1, don't mind lobbying too much, I will never back
you)

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

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

[costinm]

On Sat, 25 May 2002, Pier Fumagalli wrote:

> Just need to grep the right files... You are a good committer, I see that
> you have 2342 commits into the turbine CVS. Good.
> 
> I still beat you, overall I'm at 10717, Andy is at 2666 (Andy you're so
> lazy), but hear hear, Costin has 25871, beating Craig who is just at 22712,
> and our president (Sam) at 60869... Yes yes, he deserves to be the PMC
> president just for that...

I don't think anyone can find a mail from Craig or Sam (or me) 'bragging' 
about the number of commits or how important of contribution we make and 
how people who contribute 'less' should pay attention. 

I respect Craig mostly for the quality of his code ( even if I prefer 
different solutions and we disagree on many other things ), I respect
Sam the most for keeping a low-key as 'PMC president' ( I never saw
him use the 'I'm the PMC chair' as an argument ).

A smart idea ( like the try/catch unrolling ) is as important as 
100s of commits fixing bugs or 100s of mails answering questions.

Costin


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

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

[Martin van den Bemt]

> its a meritocracy. 

Thanx to the Oxfort dictionary I know what it is.. But all democracies
are actually meritocracies according to the dictionary, they select you
to be able to vote when 18+. But this is getting way to Off-Topic I
guess... ;))

Mvgr,
Martin



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

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

[Pier Fumagalli]

"Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
> From: "Pier Fumagalli" <[EMAIL PROTECTED]>
> 
>> Being a committer (at least that's my idea), he doesn't only have the
>> "right" to vote, but also the "due" to vote...
>> 
>> This is one of the fundamental concepts of any good democratic country.
>> Are we undermining that?
> 
> No, it isn't.
> In a true democracy, one has the right to abstain.

Correct... In every official Apache ballot (foundation crap, legal stuff),
you always have three options:

[ ] Yes
[ ] No
[ ] Abstain

But I feel it's a due for all foundation members to at least tick one of
those boxes (got upset with a couple of very close friends of mine because
they didn't show up at the members meeting last week)...

You can abstain, but you shouldn't "ignore"...


Democraticamente parlando, cos'e` piu` giusto, votare scheda bianca o
non andare a votare?


(Translated it would sound like: what's more "right" democratically
speaking, going to poll booth and put in an unticked voter's card, or not
even caring about going to vote? - But I don't know if it makes sense in
English... Andy?)

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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

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

[Andrew C. Oliver]

LOL ;-)

On Sat, 2002-05-25 at 12:43, Martin van den Bemt wrote:
> Maven provides that functionality ;))
> see http://jakarta.apache.org/turbine/maven/activity-log.html
> 
> Mvgr,
> Martin
> 
> On Sat, 2002-05-25 at 18:28, Pier Fumagalli wrote:
> > "James Taylor" <[EMAIL PROTECTED]> wrote:
> > 
> > > -- jt (who is afraid Pier will do a mailing list search on him and
> > > realize how little value he brings to the community =)
> > 
> > Sorry James, I just _had_ to do this! :) Nothing personal!!! :) :) :)
> > 
> > 
> > 
> > Just need to grep the right files... You are a good committer, I see that
> > you have 2342 commits into the turbine CVS. Good.
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Andrew C. Oliver]

> No, it isn't.
> In a true democracy, one has the right to abstain.
> 
> IMO that a good democracy doesn't need strong feelings: many dictators go to
> power with a strong vote with a strong turnout, while one of the major
> democracies of the world, the US, doen't surely have one of the highest
> turnouts.
> 

For the record, technically the US is a democratic republic and not a
"Democracy".  The low turnout in part reflects that.  We vote *against*
things not for them.  Hence our representatives try to say next to
nothing that they could get voted against on.  (this isn't unpatriotic
or a complaint, its just facts).  As a test of this, be an incumbent and
run on something that people are against, make a racist comment or
something...you'll find your opponent does really well.  

For example.  I did vote in the last presidential election, but it made
little sense to do so.  The electoral votes in North Carolina were
decided LONG before I cast my ballet.  So in a sense, when it came to
actually picking the man, my vote actually did not count.  (You vote for
your states electors, the electors vote for the president...so if your
electors vote for the other guy...well your vote meant nothing on the
scale of things...if you don't win...your issues have to wait till next
time)

>From my understanding, in most European parliamentary democracies,
generally you vote for more issue-oriented parties.  Even if you "loose"
you take a certain number of seats.  So it makes sense to vote
regardless of whether its going to be a landslide.

But as far as I know Jakarta is not a democracy...its a meritocracy. 

-Andy

> Just my 2euros.
> 
> --
> Nicola Ken Barozzi   [EMAIL PROTECTED]
> - verba volant, scripta manent -
>(discussions get forgotten, just code remains)
> -
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[James Taylor]

> while one of the major
> democracies of the world, the US, doen't surely have one of the highest
> turnouts.

And a lot of people see that as a really bad thing. Turning in an empty
ballot is one thing, but not going to the polls because you can't tear
yourself away from 'Must See TV' is ignoring your responsibility as a
citizen.

-- jt


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

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

[Martin van den Bemt]

Maven provides that functionality ;))
see http://jakarta.apache.org/turbine/maven/activity-log.html

Mvgr,
Martin

On Sat, 2002-05-25 at 18:28, Pier Fumagalli wrote:
> "James Taylor" <[EMAIL PROTECTED]> wrote:
> 
> > -- jt (who is afraid Pier will do a mailing list search on him and
> > realize how little value he brings to the community =)
> 
> Sorry James, I just _had_ to do this! :) Nothing personal!!! :) :) :)
> 
> 
> 
> Just need to grep the right files... You are a good committer, I see that
> you have 2342 commits into the turbine CVS. Good.



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

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

[Nicola Ken Barozzi]

From: "Pier Fumagalli" <[EMAIL PROTECTED]>

> Being a committer (at least that's my idea), he doesn't only have the
> "right" to vote, but also the "due" to vote...
>
> This is one of the fundamental concepts of any good democratic country.
Are
> we undermining that?

No, it isn't.
In a true democracy, one has the right to abstain.

IMO that a good democracy doesn't need strong feelings: many dictators go to
power with a strong vote with a strong turnout, while one of the major
democracies of the world, the US, doen't surely have one of the highest
turnouts.

Just my 2euros.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

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

[Martin van den Bemt]

> 
> Being a committer (at least that's my idea), he doesn't only have the
> "right" to vote, but also the "due" to vote...
> 
> This is one of the fundamental concepts of any good democratic country. Are
> we undermining that?

Hmm.. democracy is also having the right not to vote. Just don't
complain if you don't like what happened after the vote..

Mvgr,
Martin



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

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

[Andrew C. Oliver]

> Being a committer (at least that's my idea), he doesn't only have the
> "right" to vote, but also the "due" to vote...
> 
> This is one of the fundamental concepts of any good democratic country. Are
> we undermining that?
> 

you also have the right to abstain.  Sometimes you speak loudest by not
speaking at all.

> Pier
> 
> --
> [Perl] combines all the worst aspects of C and Lisp:  a billion of different
> sublanguages in  one monolithic executable.  It combines the power of C with
> the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Andrew C. Oliver]

> Hints for newbies, make your CVS commits small, so your overall activity
> meter will grow. Two lines at a time, and if you have a nice file of 1000
> lines, you get 500 points just for that...
> 

I'll try and remember that next time.  

Can//;
  //;
   We //;
  //;  
  //;
get //;
  //;
  //;
  //;
a  //;
  //;
  //;
line  //;
  //;
count  //;
  //;
  //;
please?  //;

> 
> --
> [Perl] combines all the worst aspects of C and Lisp:  a billion of different
> sublanguages in  one monolithic executable.  It combines the power of C with
> the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Pier Fumagalli]

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

> On Sat, 25 May 2002, Pier Fumagalli wrote:
> 
>> Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
>> 
>>> -1, its not broken, it worked.  I see little reason to fix it.
>> 
>> It is broken. We don't allow Sally Khudairi to be a member of this
>> community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
>> employment and terminate his working (9 to 5) relationship with Apache,
>> without leaving him with the "dues" of a committer and make him "look bad"
>> because he disappeared.
> 
> What harm is James Todd doing ? Since there are 6 months from his last
> activity you can request the removal of his account - but I don't see
> why he ( or James Davidson or Anil ) should be removed for disappearing.
> If they'll never come back - that's fine and it doesn't hurts nobody.
> But their name remains listed in many source files and should remain
> in the list of commiters.
> 
> Todd is still listed in @author tags in quite a few files ( used by both
> 3.x and 4.x - in tomcat-util package ). And there is nothing wrong with
> 9-5 contributions, there are many people who have jobs related with apache
> projects. 

Being a committer (at least that's my idea), he doesn't only have the
"right" to vote, but also the "due" to vote...

This is one of the fundamental concepts of any good democratic country. Are
we undermining that?

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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

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

[Pier Fumagalli]

"James Taylor" <[EMAIL PROTECTED]> wrote:

> -- jt (who is afraid Pier will do a mailing list search on him and
> realize how little value he brings to the community =)

Sorry James, I just _had_ to do this! :) Nothing personal!!! :) :) :)



Just need to grep the right files... You are a good committer, I see that
you have 2342 commits into the turbine CVS. Good.

I still beat you, overall I'm at 10717, Andy is at 2666 (Andy you're so
lazy), but hear hear, Costin has 25871, beating Craig who is just at 22712,
and our president (Sam) at 60869... Yes yes, he deserves to be the PMC
president just for that...

This is such a nice way to recognized "how much" you contributed to the
foundation, isn't it?

Hints for newbies, make your CVS commits small, so your overall activity
meter will grow. Two lines at a time, and if you have a nice file of 1000
lines, you get 500 points just for that...



--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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

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

[costinm]

On Sat, 25 May 2002, Pier Fumagalli wrote:

> Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
> 
> > -1, its not broken, it worked.  I see little reason to fix it.
> 
> It is broken. We don't allow Sally Khudairi to be a member of this
> community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> employment and terminate his working (9 to 5) relationship with Apache,
> without leaving him with the "dues" of a committer and make him "look bad"
> because he disappeared.

What harm is James Todd doing ? Since there are 6 months from his last 
activity you can request the removal of his account - but I don't see 
why he ( or James Davidson or Anil ) should be removed for disappearing.
If they'll never come back - that's fine and it doesn't hurts nobody.
But their name remains listed in many source files and should remain 
in the list of commiters.

Todd is still listed in @author tags in quite a few files ( used by both
3.x and 4.x - in tomcat-util package ). And there is nothing wrong with 
9-5 contributions, there are many people who have jobs related with apache
projects. 


Costin





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

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

[Andrew C. Oliver]

On Sat, 2002-05-25 at 11:38, James Taylor wrote:
> 
> > My projects haven't come to a grinding halt.  Only on general @ jakarta
> 
> But this isn't about your projects, it is about the community, and the
> community is more important than the code. Do you even know why you are
> here?
> 

No.. how about you enlighten me?

> > -Andy
> 
> -- jt (who is afraid Pier will do a mailing list search on him and
> realize how little value he brings to the community =)
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Martin van den Bemt]

 
> The converse: You all can vote all day long on what I'm to do, but what
> are you going to do when my dissenting vote is cast by me not actually
> doing it?  Voting has NOTHING to do with what work gets done.  Thats the
> POWER of those who do.

We are talking about this proposal am I right not about a project
proposal? So if there is a veto, you can do whatever you want, but you
are doing it for nobody. Unless you want to push the proposal in, when
the opportunity is there.

> 
> > > 
> > > I offered myself as installer of Scarab and it was accepted. 
> > 
> > Guess you are a committer on jakarta? I am not. Is that the difference?
> > This is exactly the reason why I said +1.. 
> 
> If you contribute work, you'll become a committer, its as simple as
> that.  I propose people committers because I can't keep up with their
> patches and get my own work done.  (After I make sure they will fit into
> the community and they know how to use CVS).  I would like to say I
> really value the opinions of everyone, but I don't.  I value the
> opinions of those who are going to contribute something tangible to the
> project (even if its just critique of the documentation, bug reports,
> test files, etc).  

Don't think we are discussing the same thing here.. I refered to my
offer of being a sysadmin/maillist moderator. Becoming a committer of
any project isn't involved in that. Probably because you have to be
committer to do such a thing, getting involved the community is pretty
difficult. 

> 
> If +1 = "Andy Do" then thats a big -1 from me.  If +1 = "Yes and I'll do
> or help do" then great!  To let non-coders be committers cheapens the
> meaning.  
Agreed ont hat, but I guess you missed to point Pier made.. Pier wasn't
suggesting that non-coders can be committers, just that they can be
members. 

> Its just a bunch of folks registering their opinion on what I
> should do.  Yeah, the difference between that and toilette paper is that
> toilette paper is useful.

You are all (seen this reference a couple of times now) thinking of
members that take up "jakarta" management issues and that they become
leaders.. I was just referring to people who can make life easier for
the coders. If I was jakarta's sysadmin, and someones says we want to
switch to scarab, I must be able to say -1 (when supplying good
reasons..). If you have a vote on POI, as a sysmanager I don't vote on
that. The only members that can intervene in your project (if that
member role was there that is), could be the lawyers ;) En (or
de)-cryption support in POI is something that could be appropiate on
that ;)). Hope you get the "overall" picture of what I am trying to say
here.. (please don't kill me on details..)
 
> 
> Yeah the kicker is that there are no bugs in it (or at least there
> weren't a week or two ago).  Maybe Turbine is perfect? :-D

Dude.. I was searching my ass of on that crashing thing.. I guess it is
perfect then indeed ;).

Mvgr,
Martin



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

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

[Andrew C. Oliver]

On Sat, 2002-05-25 at 11:38, Pier Fumagalli wrote:
> "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
> 
> > 
> > I fail to see the connection between what I said and what you stated.
> > 
> > I offered myself as installer of Scarab and it was accepted.  I'll be
> > implementing that shortly.  (Step 1. Drive Server to chapel hill, Step
> > 2. Install Scarab on it for practice, Step 3. install here)
> 
> Good. If you weren't a committer for POI, and you did that for the past 2
> years, wouldn't you like to have a some sort of recognition by this
> community? Wouldn't you like to be able to elect the PMC? To decide what
> projects you'll have to deal with in your installation of the bug tracking
> system? I believe you would.
> 

And that is why I think there should be an infrastructure project.  The
infrastructure project would give credibility to such persons and remove
it from general @.  But if we're going to give lawyers and nannies
voting rights in POI...well thats not real high on my list of good
things.

-Andy

> Pier
> 
> --
> [Perl] combines all the worst aspects of C and Lisp:  a billion of different
> sublanguages in  one monolithic executable.  It combines the power of C with
> the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Andrew C. Oliver]

On Sat, 2002-05-25 at 11:38, Martin van den Bemt wrote:
> On Sat, 2002-05-25 at 17:16, Andrew C. Oliver wrote:
> > 
> > I fail to see the connection between what I said and what you stated.  
> 
> Then I fail to see your connection with my story too.. 
> I'll Give it try anyway : If no one cares or just one person cares and
> needs to vote of all to get things implemented or changed and doesn't
> get that vote, it will not get implemented, or even tried.
> I think that is normal behaviour here, so that is why I guess a lot of
> idea's never get implemented anyway, because you guys -1 it.. 
> 

The converse: You all can vote all day long on what I'm to do, but what
are you going to do when my dissenting vote is cast by me not actually
doing it?  Voting has NOTHING to do with what work gets done.  Thats the
POWER of those who do.

> > 
> > I offered myself as installer of Scarab and it was accepted. 
> 
> Guess you are a committer on jakarta? I am not. Is that the difference?
> This is exactly the reason why I said +1.. 

If you contribute work, you'll become a committer, its as simple as
that.  I propose people committers because I can't keep up with their
patches and get my own work done.  (After I make sure they will fit into
the community and they know how to use CVS).  I would like to say I
really value the opinions of everyone, but I don't.  I value the
opinions of those who are going to contribute something tangible to the
project (even if its just critique of the documentation, bug reports,
test files, etc).  

If +1 = "Andy Do" then thats a big -1 from me.  If +1 = "Yes and I'll do
or help do" then great!  To let non-coders be committers cheapens the
meaning.  Its just a bunch of folks registering their opinion on what I
should do.  Yeah, the difference between that and toilette paper is that
toilette paper is useful.

> If you don't mind me asking out of interest : which project ? (else I
> have to dig into the avail file to see where you have commit access ;))
> 

Committer to POI and Lucene.  Developer/Contributer to Cocoon.

>  I'll be
> > implementing that shortly.  (Step 1. Drive Server to chapel hill, Step
> > 2. Install Scarab on it for practice, Step 3. install here)
> 
> It's broken now indeed ;) On the turbine list they are still saying that
> I have to use that to get bugs...
> 

Yeah the kicker is that there are no bugs in it (or at least there
weren't a week or two ago).  Maybe Turbine is perfect? :-D

-Andy

> Mvgr,
> Martin
> 
> > -Andy
> > 
> > On Sat, 2002-05-25 at 11:05, Martin van den Bemt wrote:
> > > Andy,
> > > 
> > > With this attitude nothing gets ever implemented I guess.
> > > 
> > > In this case Pier can hardly say : I am going to implement this and all
> > > of you comply! So he can implement whatever he wants, as long as it it
> > > still veto'd its no use investing spare time in. 
> > > I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but
> > > to no avail, although some were complaining about lack of time. This new
> > > proposal will leave this kind of involvement at least open.
> > > 
> > > Mvgr,
> > > Martin
> > > 
> > > On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote:
> > > > On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote:
> > > > > Even though I am not a committer / member (I try to contribute code
> > > > > however), I just needed to express my opinion ;).
> > > > > 
> > > > > I am a +1 on Piers proposal. 
> > > > > 
> > > > > Especially the membership possibility for people who are not coding can
> > > > > be very constructive for this community! 
> > > > > 
> > > > > Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> > > > > sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> > > > > community is more then just programming, although it is "our" core
> > > > > business here. Others can give us a look at things we didn't have before
> > > > > and make life a little bit easier for us code monkeys (or as I call
> > > > > myself in dutch "tiep miep")
> > > > > 
> > > > 
> > > > I see lots of ideas floating around.  Just few get implemented.  
> > > > 
> > > > -Andy
> > > > 
> > > > > Just my 2 euro cents ;)
> > > > > 
> > > > > Mvgr,
> > > > > Martin
> > > > > 
> > > > > PS this is not a pro Pier (or whoever) and con Costin (or whoever)
> > > > > thing. So let's keep it that way and ignore the comments about that to
> > > > > each other. If you cannot mail something independend of the past,
> > > > > besidees the current subject, don't mail it or mail it in private, or
> > > > > better be the wisest to ignore it.
> > > > > 
> > > > > I am not here to teach values or something like that (you are not
> > > > > waiting for that probably), but I am going to try anyway :
> > > > > The past is something that happened and is not now, you cannot blame
> > > > > people for what has taken place then, because it is not taking place now
> > > > > (with now I mean this Nanosecond even less). Life becomes so m

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

[Martin van den Bemt]

> 
> -- jt (who is afraid Pier will do a mailing list search on him and
> realize how little value he brings to the community =)

+1 on humor ;) 
You can add some extra by committing my patches for turbine-2.. ))


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

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

[James Taylor]

> My projects haven't come to a grinding halt.  Only on general @ jakarta

But this isn't about your projects, it is about the community, and the
community is more important than the code. Do you even know why you are
here?

> -Andy

-- jt (who is afraid Pier will do a mailing list search on him and
realize how little value he brings to the community =)


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

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

[Pier Fumagalli]

"Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:

> 
> I fail to see the connection between what I said and what you stated.
> 
> I offered myself as installer of Scarab and it was accepted.  I'll be
> implementing that shortly.  (Step 1. Drive Server to chapel hill, Step
> 2. Install Scarab on it for practice, Step 3. install here)

Good. If you weren't a committer for POI, and you did that for the past 2
years, wouldn't you like to have a some sort of recognition by this
community? Wouldn't you like to be able to elect the PMC? To decide what
projects you'll have to deal with in your installation of the bug tracking
system? I believe you would.

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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

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

[Martin van den Bemt]

On Sat, 2002-05-25 at 17:16, Andrew C. Oliver wrote:
> 
> I fail to see the connection between what I said and what you stated.  

Then I fail to see your connection with my story too.. 
I'll Give it try anyway : If no one cares or just one person cares and
needs to vote of all to get things implemented or changed and doesn't
get that vote, it will not get implemented, or even tried.
I think that is normal behaviour here, so that is why I guess a lot of
idea's never get implemented anyway, because you guys -1 it.. 

> 
> I offered myself as installer of Scarab and it was accepted. 

Guess you are a committer on jakarta? I am not. Is that the difference?
This is exactly the reason why I said +1.. 
If you don't mind me asking out of interest : which project ? (else I
have to dig into the avail file to see where you have commit access ;))

 I'll be
> implementing that shortly.  (Step 1. Drive Server to chapel hill, Step
> 2. Install Scarab on it for practice, Step 3. install here)

It's broken now indeed ;) On the turbine list they are still saying that
I have to use that to get bugs...

Mvgr,
Martin

> -Andy
> 
> On Sat, 2002-05-25 at 11:05, Martin van den Bemt wrote:
> > Andy,
> > 
> > With this attitude nothing gets ever implemented I guess.
> > 
> > In this case Pier can hardly say : I am going to implement this and all
> > of you comply! So he can implement whatever he wants, as long as it it
> > still veto'd its no use investing spare time in. 
> > I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but
> > to no avail, although some were complaining about lack of time. This new
> > proposal will leave this kind of involvement at least open.
> > 
> > Mvgr,
> > Martin
> > 
> > On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote:
> > > On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote:
> > > > Even though I am not a committer / member (I try to contribute code
> > > > however), I just needed to express my opinion ;).
> > > > 
> > > > I am a +1 on Piers proposal. 
> > > > 
> > > > Especially the membership possibility for people who are not coding can
> > > > be very constructive for this community! 
> > > > 
> > > > Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> > > > sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> > > > community is more then just programming, although it is "our" core
> > > > business here. Others can give us a look at things we didn't have before
> > > > and make life a little bit easier for us code monkeys (or as I call
> > > > myself in dutch "tiep miep")
> > > > 
> > > 
> > > I see lots of ideas floating around.  Just few get implemented.  
> > > 
> > > -Andy
> > > 
> > > > Just my 2 euro cents ;)
> > > > 
> > > > Mvgr,
> > > > Martin
> > > > 
> > > > PS this is not a pro Pier (or whoever) and con Costin (or whoever)
> > > > thing. So let's keep it that way and ignore the comments about that to
> > > > each other. If you cannot mail something independend of the past,
> > > > besidees the current subject, don't mail it or mail it in private, or
> > > > better be the wisest to ignore it.
> > > > 
> > > > I am not here to teach values or something like that (you are not
> > > > waiting for that probably), but I am going to try anyway :
> > > > The past is something that happened and is not now, you cannot blame
> > > > people for what has taken place then, because it is not taking place now
> > > > (with now I mean this Nanosecond even less). Life becomes so much easier
> > > > if you obtain this view! No barriers to look back on, just plain free,
> > > > non prejudiced communications. Wow we live in a great world!
> > > > Forgive me my Martin logic, you will get used to it.. ;))
> > > > 
> > > > 
> > > > 
> > > > On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> > > > > Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
> > > > > 
> > > > > > -1, its not broken, it worked.  I see little reason to fix it.
> > > > > 
> > > > > It is broken. We don't allow Sally Khudairi to be a member of this
> > > > > community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> > > > > employment and terminate his working (9 to 5) relationship with Apache,
> > > > > without leaving him with the "dues" of a committer and make him "look bad"
> > > > > because he disappeared.
> > > > > 
> > > > > Pier
> > > > > 
> > > > > 
> > > > > --
> > > > > To unsubscribe, e-mail:   
> > > > > For additional commands, e-mail: 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > --
> > > > To unsubscribe, e-mail:   
> > > > For additional commands, e-mail: 
> > > > 
> > > -- 
> > > http://www.superlinksoftware.com - software solutions for business
> > > http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
> > > Java
> > > http://krysalis.sourceforge.net/centipede - the best build/project
> 

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

[Andrew C. Oliver]

I fail to see the connection between what I said and what you stated.  

I offered myself as installer of Scarab and it was accepted.  I'll be
implementing that shortly.  (Step 1. Drive Server to chapel hill, Step
2. Install Scarab on it for practice, Step 3. install here)

-Andy

On Sat, 2002-05-25 at 11:05, Martin van den Bemt wrote:
> Andy,
> 
> With this attitude nothing gets ever implemented I guess.
> 
> In this case Pier can hardly say : I am going to implement this and all
> of you comply! So he can implement whatever he wants, as long as it it
> still veto'd its no use investing spare time in. 
> I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but
> to no avail, although some were complaining about lack of time. This new
> proposal will leave this kind of involvement at least open.
> 
> Mvgr,
> Martin
> 
> On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote:
> > On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote:
> > > Even though I am not a committer / member (I try to contribute code
> > > however), I just needed to express my opinion ;).
> > > 
> > > I am a +1 on Piers proposal. 
> > > 
> > > Especially the membership possibility for people who are not coding can
> > > be very constructive for this community! 
> > > 
> > > Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> > > sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> > > community is more then just programming, although it is "our" core
> > > business here. Others can give us a look at things we didn't have before
> > > and make life a little bit easier for us code monkeys (or as I call
> > > myself in dutch "tiep miep")
> > > 
> > 
> > I see lots of ideas floating around.  Just few get implemented.  
> > 
> > -Andy
> > 
> > > Just my 2 euro cents ;)
> > > 
> > > Mvgr,
> > > Martin
> > > 
> > > PS this is not a pro Pier (or whoever) and con Costin (or whoever)
> > > thing. So let's keep it that way and ignore the comments about that to
> > > each other. If you cannot mail something independend of the past,
> > > besidees the current subject, don't mail it or mail it in private, or
> > > better be the wisest to ignore it.
> > > 
> > > I am not here to teach values or something like that (you are not
> > > waiting for that probably), but I am going to try anyway :
> > > The past is something that happened and is not now, you cannot blame
> > > people for what has taken place then, because it is not taking place now
> > > (with now I mean this Nanosecond even less). Life becomes so much easier
> > > if you obtain this view! No barriers to look back on, just plain free,
> > > non prejudiced communications. Wow we live in a great world!
> > > Forgive me my Martin logic, you will get used to it.. ;))
> > > 
> > > 
> > > 
> > > On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> > > > Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
> > > > 
> > > > > -1, its not broken, it worked.  I see little reason to fix it.
> > > > 
> > > > It is broken. We don't allow Sally Khudairi to be a member of this
> > > > community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> > > > employment and terminate his working (9 to 5) relationship with Apache,
> > > > without leaving him with the "dues" of a committer and make him "look bad"
> > > > because he disappeared.
> > > > 
> > > > Pier
> > > > 
> > > > 
> > > > --
> > > > To unsubscribe, e-mail:   
> > > > For additional commands, e-mail: 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:   
> > > For additional commands, e-mail: 
> > > 
> > -- 
> > http://www.superlinksoftware.com - software solutions for business
> > http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
> > Java
> > http://krysalis.sourceforge.net/centipede - the best build/project
> > structure
> > a guy/gal could have! - Make Ant simple on complex Projects!
> > The avalanche has already started. It is too late for the pebbles to
> > vote.
> > -Ambassador Kosh
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Martin van den Bemt]

Andy,

With this attitude nothing gets ever implemented I guess.

In this case Pier can hardly say : I am going to implement this and all
of you comply! So he can implement whatever he wants, as long as it it
still veto'd its no use investing spare time in. 
I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but
to no avail, although some were complaining about lack of time. This new
proposal will leave this kind of involvement at least open.

Mvgr,
Martin

On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote:
> On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote:
> > Even though I am not a committer / member (I try to contribute code
> > however), I just needed to express my opinion ;).
> > 
> > I am a +1 on Piers proposal. 
> > 
> > Especially the membership possibility for people who are not coding can
> > be very constructive for this community! 
> > 
> > Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> > sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> > community is more then just programming, although it is "our" core
> > business here. Others can give us a look at things we didn't have before
> > and make life a little bit easier for us code monkeys (or as I call
> > myself in dutch "tiep miep")
> > 
> 
> I see lots of ideas floating around.  Just few get implemented.  
> 
> -Andy
> 
> > Just my 2 euro cents ;)
> > 
> > Mvgr,
> > Martin
> > 
> > PS this is not a pro Pier (or whoever) and con Costin (or whoever)
> > thing. So let's keep it that way and ignore the comments about that to
> > each other. If you cannot mail something independend of the past,
> > besidees the current subject, don't mail it or mail it in private, or
> > better be the wisest to ignore it.
> > 
> > I am not here to teach values or something like that (you are not
> > waiting for that probably), but I am going to try anyway :
> > The past is something that happened and is not now, you cannot blame
> > people for what has taken place then, because it is not taking place now
> > (with now I mean this Nanosecond even less). Life becomes so much easier
> > if you obtain this view! No barriers to look back on, just plain free,
> > non prejudiced communications. Wow we live in a great world!
> > Forgive me my Martin logic, you will get used to it.. ;))
> > 
> > 
> > 
> > On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> > > Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
> > > 
> > > > -1, its not broken, it worked.  I see little reason to fix it.
> > > 
> > > It is broken. We don't allow Sally Khudairi to be a member of this
> > > community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> > > employment and terminate his working (9 to 5) relationship with Apache,
> > > without leaving him with the "dues" of a committer and make him "look bad"
> > > because he disappeared.
> > > 
> > > Pier
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:   
> > > For additional commands, e-mail: 
> > > 
> > > 
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> > 
> -- 
> http://www.superlinksoftware.com - software solutions for business
> http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
> Java
> http://krysalis.sourceforge.net/centipede - the best build/project
> structure
>   a guy/gal could have! - Make Ant simple on complex Projects!
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 



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

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

[Andrew C. Oliver]

On Sat, 2002-05-25 at 09:13, Pier Fumagalli wrote:
> Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
> 
> > -1, its not broken, it worked.  I see little reason to fix it.
> 
> It is broken. We don't allow Sally Khudairi to be a member of this
> community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> employment and terminate his working (9 to 5) relationship with Apache,
> without leaving him with the "dues" of a committer and make him "look bad"
> because he disappeared.
> 

My projects haven't come to a grinding halt.  Only on general @ jakarta
is the sky always falling and Apache coming to an end.  I prefer the
status quo.  Nothing you've said has convinced me that (it could be that
I don't know who those people are anyhow) there is a compelling reason
to change it.  There are other things I see as more pressing than the
need for more chiefs.

-Andy

> Pier
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Andrew C. Oliver]

On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote:
> Even though I am not a committer / member (I try to contribute code
> however), I just needed to express my opinion ;).
> 
> I am a +1 on Piers proposal. 
> 
> Especially the membership possibility for people who are not coding can
> be very constructive for this community! 
> 
> Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> community is more then just programming, although it is "our" core
> business here. Others can give us a look at things we didn't have before
> and make life a little bit easier for us code monkeys (or as I call
> myself in dutch "tiep miep")
> 

I see lots of ideas floating around.  Just few get implemented.  

-Andy

> Just my 2 euro cents ;)
> 
> Mvgr,
> Martin
> 
> PS this is not a pro Pier (or whoever) and con Costin (or whoever)
> thing. So let's keep it that way and ignore the comments about that to
> each other. If you cannot mail something independend of the past,
> besidees the current subject, don't mail it or mail it in private, or
> better be the wisest to ignore it.
> 
> I am not here to teach values or something like that (you are not
> waiting for that probably), but I am going to try anyway :
> The past is something that happened and is not now, you cannot blame
> people for what has taken place then, because it is not taking place now
> (with now I mean this Nanosecond even less). Life becomes so much easier
> if you obtain this view! No barriers to look back on, just plain free,
> non prejudiced communications. Wow we live in a great world!
> Forgive me my Martin logic, you will get used to it.. ;))
> 
> 
> 
> On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> > Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
> > 
> > > -1, its not broken, it worked.  I see little reason to fix it.
> > 
> > It is broken. We don't allow Sally Khudairi to be a member of this
> > community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> > employment and terminate his working (9 to 5) relationship with Apache,
> > without leaving him with the "dues" of a committer and make him "look bad"
> > because he disappeared.
> > 
> > Pier
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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

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

[Pier Fumagalli]

"Martin van den Bemt" <[EMAIL PROTECTED]> wrote:

> Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
> sys admins, people with great ideas ("the thinkers")  etc,etc.. A
> community is more then just programming, although it is "our" core
> business here. Others can give us a look at things we didn't have before
> and make life a little bit easier for us code monkeys (or as I call
> myself in dutch "tiep miep")

_THIS_ is freedom. It doesn't look like a "vicious abuse"... Thank you
Martin...

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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

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

[Martin van den Bemt]

Even though I am not a committer / member (I try to contribute code
however), I just needed to express my opinion ;).

I am a +1 on Piers proposal. 

Especially the membership possibility for people who are not coding can
be very constructive for this community! 

Designers, politicians, copywriters, lawyers, nannies, cleaning lady,
sys admins, people with great ideas ("the thinkers")  etc,etc.. A
community is more then just programming, although it is "our" core
business here. Others can give us a look at things we didn't have before
and make life a little bit easier for us code monkeys (or as I call
myself in dutch "tiep miep")

Just my 2 euro cents ;)

Mvgr,
Martin

PS this is not a pro Pier (or whoever) and con Costin (or whoever)
thing. So let's keep it that way and ignore the comments about that to
each other. If you cannot mail something independend of the past,
besidees the current subject, don't mail it or mail it in private, or
better be the wisest to ignore it.

I am not here to teach values or something like that (you are not
waiting for that probably), but I am going to try anyway :
The past is something that happened and is not now, you cannot blame
people for what has taken place then, because it is not taking place now
(with now I mean this Nanosecond even less). Life becomes so much easier
if you obtain this view! No barriers to look back on, just plain free,
non prejudiced communications. Wow we live in a great world!
Forgive me my Martin logic, you will get used to it.. ;))



On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote:
> Andrew C. Oliver <[EMAIL PROTECTED]> wrote:
> 
> > -1, its not broken, it worked.  I see little reason to fix it.
> 
> It is broken. We don't allow Sally Khudairi to be a member of this
> community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
> employment and terminate his working (9 to 5) relationship with Apache,
> without leaving him with the "dues" of a committer and make him "look bad"
> because he disappeared.
> 
> 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...

[Jeff Turner]

On Sat, May 25, 2002 at 02:04:24PM +0100, Pier Fumagalli wrote:
> [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)...

Aren't we all happy that 3.3.x exists, and is better than 3.2.x? Aren't
we all happy that we have a choice to 4.x?

Aren't we all happy that Jon was 'mislead' into not -1'ing Struts (one
of Jakarta's biggest successes)?

Perhaps people should be less certain they know what is best for the
community :P

> Anyway, nice talking to you (not).

.. and thankful that people like Costin persevere in spite of rather
vicious abuse.


--Jeff
(a happy 3.3.x and Struts user, whose sense of justice temporarily
outweighs an aversion to general@ flamewars)


> Pier
> 

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

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

[Pier Fumagalli]

Andrew C. Oliver <[EMAIL PROTECTED]> wrote:

> -1, its not broken, it worked.  I see little reason to fix it.

It is broken. We don't allow Sally Khudairi to be a member of this
community, nor James "Gonzo" Todd (ex employee at Sun), to leave his
employment and terminate his working (9 to 5) relationship with Apache,
without leaving him with the "dues" of a committer and make him "look bad"
because he disappeared.

Pier


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

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

[Pier Fumagalli]

Tim Vernum <[EMAIL PROTECTED]> wrote:
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> 
>> 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.
> 
> But it's not just about exercising rights, it's also about
> granting rights.
> 
> At the moment, you cannot grant someone one right (commit access)
> without also granting them additional rights (voting etc).
> 
> Some people (myself included) would claim that the "condition of
> entry" for those rights, are not equal.

Thanks, it seems that few people understood what I'm trying to do: freeing
the community from being tied down to a particular CVS repository and
restructuring it, for most of the otehrs I'm just someone who wants to "lock
up" this community and strip it of its freedom... Bah :)

Pier


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

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

[Tim Vernum]

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]

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

But it's not just about exercising rights, it's also about
granting rights.

At the moment, you cannot grant someone one right (commit access)
without also granting them additional rights (voting etc).

Some people (myself included) would claim that the "condition of
entry" for those rights, are not equal.

In that case, where do you set the bar? At the bottom or the top?
It seems that that is where this discussion really came from.

Pier set it at the top (the code might be good, but he wasn't 
going to grant someone full committer rights based solely on that),
while you set it closer to the bottom (the code deserved commit 
access, and that implies the other rights).

Personally I'm -0 on this.

I don't think commit access should be so widely given out, because
I think that the developer communities should be larger than the
set of committers.
The voting rules allow for the casting of non-binding votes, but 
they tend not to be used much.
It's fairly easy for non-committers to submit patches, but that puts
a responsibility onto the committers to apply them in a timely fashion.

I'm not a committer on any (sub)project, but I don't think that should
stop me participating and expressing non-binding opinions.

The community is open to non-committers, and you/we should be encouraging
that. Why the rush to vote people in?
There's a number of things that the committer status gives - which ones
are being targeted?

If all you're trying to do is avoid having to apply their patches for 
them, then that's a different discussion (i.e. How do you improve the 
patch-submit-apply process).

If you think that he project needs to include the opinions/ideas of more
people, then listen to the non-binding votes.

I would think that making someone a committer is done in the anticipation
that they will become a core member of the tomcat & Jakarta communities.
The commit/voting rights are just a side effect of that.



-- 


NOTICE
This e-mail and any attachments are confidential and may contain copyright material of 
Macquarie Bank or third parties. If you are not the intended recipient of this email 
you should not read, print, re-transmit, store or act in reliance on this e-mail or 
any attachments, and should destroy all copies of them. Macquarie Bank does not 
guarantee the integrity of any emails or any attached files. The views or opinions 
expressed are the author's own and may not reflect the views or opinions of Macquarie 
Bank. 


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

[Andrew C. Oliver]

-1, its not broken, it worked.  I see little reason to fix it.

On Fri, 2002-05-24 at 21:11, Henri Yandell 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.
> 
> 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: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


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