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
http://subversion.apache.org/docs/community-guide/roles.html#patch-manager
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
though.
- Try to tackle the "Improve 'svn help'." item on the OPW ideas page:
http://subversion.apache.org/opw.html
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:
http://svn.haxx.se/dev/archive-2008-03/0088.shtml
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.
Thanks!
