Re: Census - Or who are all these hoopy froods anyway?

Am 29.01.2004 um 16:11 schrieb Matt Brozowski:
> Christopher Lenz wrote:
>>> One issue that I think prevents some projects from reaching their
>>> potential is a lack of 1) documentation about how to get involved, 2)
>>> the ability to delegate *small* tasks to people who wish to 
>>> contribute
>>> but don't know enough yet to be effective or don't have too much 
>>> time.
>>
>> There are many different theories about how to build effective
>> development communities ;-) Providing "Getting involved" documentation
>> is important, but I've never seen a delegation model succeed in
>> open-source. Of course, the other extreme of committers being 
>> reluctant
>> to let non-committers do the work and applying their patches is very
>> harmful.
>
> I think the point Tom is making is not that we figure how to delegate 
> to
> people so they do the work for us but instead make it as simple as 
> possible
> for people to get involved including those with limited time.  I 
> personally
> have been unable to contribute to projects that I really enjoyed 
> because the
> hurdles of figuring out where I could best contribute were greated 
> than the
> time I had allotted to do the work.
>
> I think it is essential to have a number of small tasks on the lists 
> so that
> someone who come in and desires to contribute can take a shot at these 
> and
> use them to gain experience in developing for the project.  It seems 
> to me
> that someone who has been able to even in a small way is much more 
> likely to
> contribute more in the future.

I completely agree. I think that over time the issue tracker should 
contain a lot of open issues that can be investigated by people who 
want to participate. That's simply a matter of the committers not 
having all the time in the world to work on this project, rather than 
issues being left open intentionally.

> When I work with new members of development teams here at work.  I 
> always
> have bugs that I know how to fix.  I take them to the code, show them 
> the
> problem, show them the solution and them tell them to fix it and 
> verify that
> its actually fixed..  This allows them to focus on overcoming the 
> hurdles of
> devleopment and test setup, building, debugging, etc.  Then they learn 
> the
> process of submitting a fix.  This goes a long way to getting them 'up 
> and
> running' from a contribution perspective.  Once they can do all of 
> those
> things, they are able to contribute much more readily and in much more
> sophisticated ways.

This is a nice model for commercial development, but in open-source you 
can't tell a contributor to go fix issue #65879. In addition, we want 
to fix issues we know how to fix (and have the time to fix) because we 
want to build a great product, and a great product attracts users and 
thus potential contributors.

> I think this is essential to having true collaboration on this project 
> and
> getting more interest in other developers contributing.  With 
> thousands of
> various projects on sourceforge alone, ours is just one among many 
> that want
> development support.  If it is onerous to figure out how to get 
> involved, or
> if the time requirements to get involved are too high, then developers 
> will
> just move on the the next project.

Well, people don't come to SourceForge and look at the lists of 
projects to find interesting ones to which they may want to contribute. 
I think that most contributors come from the users of the product 
developed by the project team. Users find an issue that annoys them, or 
have an idea for enhancement. Some will post to the forum, others will 
submit issues to the tracker. Some might prepare a patch that fixes the 
issue (or implements the functionality they need). Some might be guided 
to provide a patch.

The important prerequisites for this model to work are (IMHO):

* Open, active discussion on the developer mailing lists. If the 
vision, development plan and current work items of the project are 
locked away in their heads of the developers, or discussed in private 
or non-archived forums such as IRC or IM, potential contributors will 
get the impression that there's some inner circle with secret plans, 
and that impression will scare many away.

* Provide documentation on how to get involved, including information 
on how to check code out from CVS, how to prepare patches, how to get 
the patches in the hands of the project committers.

* Give potential contributors the feeling that they can influence the 
project. Review and apply patches as soon as possible. Nominate regular 
contributors to be given committer status.

I hope that some of this spirit is captured in the proposed project 
charter.

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn