--On Wednesday, November 6, 2002 2:31 PM +1100 Peter Donald
<peter@apache.org> 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
|