db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: New contributors?
Date Thu, 07 Sep 2006 20:35:58 GMT
Jean T. Anderson wrote:

> Daniel John Debrunner wrote:
>>Susan L. Cline wrote:

> It might be helpful for reviewers to clearly separate "must fix" items
> from "nice to have" items in their comments.

Sounds great, but what is a must fix? I think most reviewer's comments
are "nice to have". Reviewers don't have any power to say "you must fix
it", unless:
    1) They place a valid technical veto (-1 vote) against the patch. I
think putting -1 against patches as the common practice is not a good
direction, even less friendly.
    2) It's some requirement of the ASF, like no copyright statement in
the code.

I think reviewer's comments are more of the form, "*I* believe the patch
would be better if this was done", and maybe for a committer "*I'm* more
likely to commit the patch if this was done". Maybe we need to make that
clearer. Call them "patch suggestions"?

>>A contributor should be free to challenge or discuss any
>>comment, rather than assume the reviewer is correct. On some of the
>>style issues I raised, related to clarity, I did ask the question "do
>>they add value?". By "add value", I really meant does it increase the
>>clarity of the code? In such cases a contributor is free to come back
>>and say in their opinion it does and why, and maybe the reviewer and
>>community learns something as well, it's a two way street.
> If we want to encourage new contributors to contribute to Derby, we need
> to make sure that the two way street doesn't involving throwing down the
> gauntlet to a new contributor -- otherwise, we'll simply chase new
> contributors away.
> The need to defend a patch can be quite a surprise to new contributors
> who might think that the several days or hours they spend producing
> something will be appreciated, but find they need to pour extra time
> into defending it. 

Not sure "defending" is how we should be putting it. It's more that I
expect contributors to be willing to accept and discuss
comments/suggestions for their patch. It's also about not having
contributors blindly accept that reviewers are correct, it's a peer
based system, new ideas and viewpoints are just as valuable as those of
the existing community members.

We could take the approach that all patches are accepted in any form,
and just hope that contributors turn into community members who care
about "consistently high quality software" rather than continuing on as
contributors who find Derby a great place they can dump any patch in any
state, and someone else will clean it up. This is a valid open source
model. My belief is that it's actually more efficient for the community
if one can address issues at the initial stages rather than once a patch
has landed in the code line and been established for a while. I've spent
too much time cleaning up code in Derby to think any other way :-(

I think it would be great to lower the barrier to get patches into
Derby, but I don't think it should be so low that we are afraid to
provide any feedback to a new contributor for fear of scaring them off.
I hope that at least the contributors get to know the community a little
before diving in, thus have the correct expecations of how things work
and what is required.

One other concern is that a lot of code development is done by copying
existing code, thus non-ideal code has the ability to multiply, almost
by itself. :-) So code without comments leads to more code without
comments, leading to a harder to understand code base leading to less
new contributors getting involved.

> If we want new Derby contributors, I think we should do everything we
> can to encourage and increase the confidence of new contributors. Yes,
> there will be items to fix in patches. Let's make an extra effort to be
> clear about what's required and what's nice to have.
>>It's also valid for the contributor to say, those are great ideas, I
>>don't have time to address them now. Then it's up to the committers to
>>decide if one of them has the confidence in the patch.
> I would encourage reviewers to be proactive with new contributors -- for
> example, in your "nice to have" items go ahead and mention that those
> don't have to be done before the patch is committed if the contributor
> doesn't have time. Don't assume that the new contributor is fully versed
> in life at Apache. Make this a confidence-building opportunity.

And it's a two way street, I would encourage new contributors to be
proactive with the community. Discuss items with the community before
working on something rather than being surprised when it's not
immediately accepted by the community.



View raw message