Growing developer community (was Subversion Vision and Roadmap Proposal)

On Fri, Apr 2, 2010 at 5:28 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
[...]
> COMMUNITY
> [...]
>
> But communication alone isn't enough.  We need to find ways to grow our
> developer community itself.  Attendance at the recent Subversion Corporation
> Annual Members Meeting was low (by design and recommendation, of course),
> but a startling realization was made there.  When the agenda item for voting
> new full committers into membership was on the table, there were no
> candidates.  Think about that:  no new full committers for Subversion in the
> past year.  This is a bad thing.  We need to find a way to embrace and
> empower would-be Subversion contributors.  Telling them to troll through the
> issue tracker looking for bite-sized issues is not the way to do that -- it
> communicates "we can't be bothered to mentor you".  When somebody wants to
> start making contributions, our community must recognize the value of that
> contributor and mentor him or her toward full committership, for the good of
> that contributor and of the community.  Further, our public roadmap needs to
> highlight the items that we really wish we could be working on but lack the
> manpower to handle.  This would provide those looking for ways to accelerate
> Subversion's roadmap with some cues for doing that in harmony with the Big
> Picture.

FWIW, I just wanted to add my view on this, as a relative newcomer to
svn (using & administering since 1 year, and becoming more and more of
an enthusiast).

Being a software developer myself (ok, my C knowledge/experience is
pretty limited and somewhat rusty, but whatever) I've been trying for
a while to become more involved, looking around for something I could
contribute in the form of code (like [1]).

IMHO a couple of things made it unnecessarily difficult to make the
transition from enthusiast to feeling confident enough to dive into
the code:

1) Subversion Community Guide (aka HACKING): it may be a great
reference and important guideline to keep everyone in line, but it's
not very good for getting new developers started.
  * It's huge, so it takes a lot of time to read and understand.
  * The document indicates that you have to read through the entire
document before considering to contribute code ("No, wait, first read
the rest of this file, then start sending patches to
dev_at_subversion.apache.org. :-)").
  * It's not only the document itself, but also the stuff it refers to
(in "Theory and documentation" and in "Code to read"). For people like
me (the sensing type, for people that know MBTI :-)), that means I
*have to* grok all that stuff before I can move on.
  * It contains a lot of stuff that's not really that important for
someone trying to make a first contribution

Don't get me wrong: all the stuff in there is very important, and so
is the documentation it references (it helped me a lot to understand
the code), but it is a lot. It might be easier, more efficient, ...
for people considering to make their first contribution to make some
kind of "bootstrap document" out of it, and let people dive into the
code as quickly as possible.

2) Missing medium-level documentation. I'm missing something in
between the old design spec (although outdated, it's still quite
useful; however, it should really be updated) and the documentation in
the code. The code is very well documented, but as a newcomer I found
it quite difficult to get a grasp on the larger structures, flow, how
things are interconnected (layers, callbacks, ...), ... Maybe
something in between the high level design doc and the
code-documentation could help?

3) It's too difficult to get a development/debugging/testing
environment up and running, especially on Windows. That was really a
huge time sink for me ...

Just my 2 cents ...

-- 
Johan
[1] http://svn.haxx.se/dev/archive-2010-03/0503.shtml - Looking to
improve performance of svn annotate