incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Code ownership (was Re: whoweare.html)
Date Wed, 06 Nov 2002 03:35:51 GMT
--On Wednesday, November 6, 2002 2:31 PM +1100 Peter Donald 
<> wrote:

> If you do that then it would be unlikely to be changed. I think I
> know what  Nicola is talking about and I think it is great :) You
> may also notice that  the project who have the bigger healthier
> communities (at least in  jakarta/xml land) tend to do this all the
> time.

Erk!  (tries to pick up jaw)

> For example, someone submits some code that doesn't follow various
> conventions  that have been established in the project. Do you tell
> the contributor -  sorry can't take that till you fix it? No.
> Usually what happens is that you  commit the code. Then you go
> through and fix up style/semantic/logical  violations. As the
> commit messages go past the end user sees the corrections.  Next
> time they are more likely to work the way the project operates.

Nuh-uh.  That's so wrong.

You need to encourage providing feedback not doing someone else's job 
for them.

"Give a man a fish and you feed him for a day.
Teach a man how to fish and you feed him for a lifetime."

We should be attempting to fostering communities by teaching people 
the processes, not being arrogant and commiting their fixes for them.

> If there are massive fixes required the user will generally see the
> patch  rejected with recomendations for a fix but usually it is
> better to commit and  teach by example IMHO.

I couldn't disagree more.  If someone does a bogus commit, then it is 
on them to fix it.  Not me or anyone else.  Teach new committers to 
take responsibility for their actions.  If they refuse to fix it or 
revert their change, yank their commit privs (emphasis on privs not 
rights).  -- justin

View raw message