[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Contributing to SVN (was: Re: [PATCH] Adding tests for some functions in svn_checksum.h in SWIG bindings for python)

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 3 Apr 2013 14:22:19 +0200

On Tue, Apr 02, 2013 at 05:18:46PM -0400, C. Michael Pilato wrote:
> I confess I'm a bit confused by the early parts of the test changes, which
> appear to be more about testing the 'random' module and less about testing
> Subversion.

Hi Shivani,

please allow me to divert this discussion away from the patch you
are submitting. I think there is a need to make a more general point
about your approach to contributing to the Subversion project.

We appreciate your contributions very much, but from my point of view
it is becoming increasingly clear that your current contributions to
the bindings do not have a good chance of getting anywhere (and I'm
quite sure others share this opinion). I hope what I'm about to say
below will prevent you from eventually giving up in frustration.

I would like to encourage you to drop the bindings task in favour of
some other task, a task that more closely matches your current skill level.

As I've mentioned before, the bindings task is one of the items I put
up on the OPW ideas page without much consideration, and it is not an
easy item to tackle for a novice programmer.
Based on the submissions you've made during the OPW application phase,
as well as after, and based on the feedback you've received since,
I'm convinced the bindings task requires skills that you don't have yet.

And furthermore, I don't think the Subversion community has the capacity
to teach you these skills. This is not because we wouldn't like to, it
is because we are only equipped to deal with contributions from submitters
who are self-reliant in the sense that they can digest feedback without
requiring further help beyond the hints can we communicate via email
during patch review.

Teaching things that go further beyond a contributor's level of
expertise is something that colleges and universities are equipped to do.
But open source projects cannot do this. Open source projects rely on
participants to assess their own skill level and pick an appropriate
task based on that self-assessment, or acquire the necessary skills
themselves without relying on much help from the community. If necessary,
participants need to be able to drop a task that they recognize is too
hard for them and focus on something else. Usually this happens
automatically, but in your case it seems you need a gentle push ;)

And please keep in mind that not many Subversion developers know the bindings
very well, which means that your patch submissions have a fairly limited
audience. If you made submissions which can be handled by more people you
would experience quicker turnaround and get more feedback.

Off the top of my head, here are some alternative tasks I think you
could work on in a more productive way:

 - Share the patch manager role with Gavin Baumanis, see
   This would give you a good idea about the kind of changes others
   are working on. You'll also be paying more attention to the way
   people react to patch reviews. Perhaps being patch manager for a
   while will help you with finding a suitable coding task as well.
   You could also try reviewing patch submissions from others to
   gain more technical experience as part of this role.
 - Become an FAQ manager. We'd have to define the exact details of
   this role first, but I think some maintenance work on the FAQ is
   in order as it is partly outdated and probably has many omissions.
   This task can give you broad knowledge of Subversion, since the FAQ
   contains a wealth of information on various areas and subsystems,
   which you'd be maintaining and extending.
   This way, you might find an area that sparks your technical interest
   and that is more accessible to you than the bindings are.
   You might also be able to make important contributions to the
   Subversion book (see http://svnbook.red-bean.com).
   However, this is pure documentation task, so I'm not sure if you'd
   really like to do this. It is a good precursor for a technical task

 - Try to tackle the "Improve 'svn help'." item on the OPW ideas page:
   This task involves both documentation and code changes, but the code
   changes should not be very difficult to perform and to review. Pretty
   much any Subversion developer can review patches to 'svn help' so
   you'll have a larger audience when making contributions in this area.

 - Try to update the CHANGES file on trunk to list important changes
   that were made during the 1.8 development phase (since 1.7.x was
   branched in r1145993). This is usually done by a group of people
   since the number of changes made since the last minor releases is
   too large for a single person to comb through. However, someone needs
   to organise this effort and find volunteers, which is something you
   could do. See here for how this was done in the past:
   A few changes are already listed in CHANGES for 1.8, but there are
   many more which could be listed, no doubt.
   This is not a technical task either, and has similar implications
   as the FAQ manager task, and also involves community management
   which is a very important aspect of open source development.
   Moreover, it needs to be done, since there is nobody currently steering
   this effort and the 1.8.0 release is approaching. So there is a gap to
   be filled and you're welcome to give it a try.

I cannot think of any other tasks to suggest right now. But I'm sure there
are more. If you have any ideas yourself please share them. Ideas from others
are also welcome, of course.

Received on 2013-04-03 14:22:59 CEST

This is an archived mail posted to the Subversion Dev mailing list.