[Haskell-cafe] poll: how can we help you contribute to darcs?

[wren ng thornton]

Eric Kow wrote:
> Dear Haskellers,
> 
> I would like to take an informal poll for the purposes of darcs
> recruitment.  Could you please complete this sentence for me?
> 
>    "I would contribute to darcs if only..."
> 
> The answers I am most interested in hearing go beyond "... I had more
> time".  For instance, if you are contributing to other Haskell/volunteer
> projects, why are you contributing more to them, rather than darcs?

...I knew how to help (and had the time).

The You Too Can Hack on Darcs blog series is a really good idea. One 
problem many open-source projects suffer from is it not being apparent 
how a new hacker would even begin to start working. An overview of how 
the project is set up along with some notice about how malleable the 
different parts are goes a long way.

It can also be helpful to take some RFI and walk through implementing 
the change, testing that it hasn't broken anything, and sending the 
patch (don't forget this step :). A follow on about getting ideas from 
the bug tracker is also good. Sometimes hands-on documentation is the 
best kind. Also documenting how a ninja developer could drop in, fix 
some things, and leave before anyone noticed is a good way to snare the 
folks who'd like to help a little but don't want to get dragged into 
being a regular developer (yet). Try-before-you-buy contributing is one 
of the best ways to get regular developers.


...I knew you needed help (and had the time).

This is an image thing, but until the recent announcement of dayjob 
syndrome I was under the impression that darcs was rumbling along just 
fine. The wiki has a developers' FAQ and all, but the overall image is 
that darcs is stable and doing fine (and in my experience it is). Part 
of the reason I haven't contributed was that I've never thought about 
it-- and that's the problem. Silly as it sounds, even people who work on 
open-source code all the time don't always think about whether a project 
they use every day could use their support. And if it works just fine, 
they don't even have the impetus of wanting to fix it.


I think it'd be good if the YTCHoD blog were more long lived than just 
something to gain developers now. A community blog for everyone hacking 
on darcs might help to demonstrate:

(a) that there's a community of humans behind the software,

[This is another thing that, silly as it sounds, people often forget 
about. For a humorous but all too true discussion of why, cf 
<http://www.cracked.com/article_14990_what-monkeysphere.html>.]

(b) that they're nice folks who'd welcome new developers,

[In the corporate world people will take a job for the money, but they 
stay (or leave) for the people. In open-source they may come for the 
code, but it's the community that keeps them around (or scares them off).]


(c) and that there are specific tractable problems they have that 
non-developers could help with.

[Bug trackers are an excellent source of tasks for active developers to 
use so things don't get lost, but they're awful for new developers. For 
someone just joining the project it's rarely clear how important a task 
is, how hard, or how far reaching its consequences (or whether someone's 
already working on it). Good trackers have fields to note these things, 
but the notes are engineered for active developers; the extent to which 
those notes are even used or accurate varies wildly from project to 
project. Hence, having a clear discussion about what things really are 
important and how much they interact with everything else is a great boon.]


-- 
Live well,
~wren