Re: Coders and projects

[Roger Dingledine <arma@seul.org>]

In message <199811170055.TAA21032@csrlink.net>, dloss@csrlink.net writes:
>I think Justin Maurer asked a crucial question--who do we have with c/c++
>coding experience, and with GNOME/gtk+ experience?  From the answers is looks
> to me as though we have a reasonable core of experience c/c++ programmers,
>although most haven't had any exposure to GNOME/gtk+.  To me this suggests
[snip]
>we want to be able to do with them.  Once _that's_ done, we should have a
>reasonable functional description of the programs we want and can code away.
>
>I admit that I don't have any experience managing a major coding project, but
> I think Justin Bradford does (right?).  Justin, did my sequence above sound
>about right, or is there some better way to come up with a framework to work
>within?
>
>If you're not an accomplished programmer, don't think that there won't be
>anything for you to do in these efforts.  Coming up with the functional
>descriptions requires some logical thought but not necessarily programming
>expertise.  Testing the programs is also something that benefits from people
>not closely involved in their development.  Writing documentation is also
>important, as is being one of the brave souls who first trys to use the
>program in a real-world situation.  There's something for all of us here.

I just want to reiterate some of Doug's points.

The difference between successful projects and unsuccessful ones is
that successful projects produce. They don't necessarily create the
coolest thing ever seen; they simply make something that's good enough
for people to actually use it. Now, this 'product' doesn't have to be
a program. For instance, it might be a good list of already-available
programs and a concise evaluation of what each of those is good at.
(But I think our end goal here is to enable schools to use Linux for
everything -- this means writing code.) Another feature of many
successful projects is that they produce *early*. Too much discussion
means that people get bored and leave, and by the time people get ready
to actually produce they've lost critical mass. I'm not saying we're
anywhere near that point yet -- just keep it in mind. :)

I think Doug left an important category out of his "list of what
non-programmers can do" -- organizers. People who look through the
archives (and watch the list), and sort and summarize useful posts by
topic. People who keep track of everything we've done or learned about
a certain topic (eg a gradebook, or possible grants that institutions
can apply for). People who watch for inconsistencies, maybe make a list
of frequently answered questions (or just frequently answer them). Such
documents can be consulted as project summaries by those who are working
on them, and also used by new workers to get up to speed quickly, or by
people casually wondering whether they want to join the project. Organizers 
need to be really intelligent people who can keep a handle on everything
that's going on. They would probably work alongside the technical leader
to let him focus more on the technical side of things.

In a lot of projects they would actually be the technical leader, since
good organizers are tough to find. But I think that while we do have some
good programmers here, we seem to have a lot of people who aren't
"accomplished programmers" but who still want to help out in a really
substantial way. In addition, I think many of the real programmers here
won't actually be using these programs -- this makes it even more vital
that somebody with an actual stake in the end product be closely involved
in its creation.

(Volunteers? :)
--Roger