Hi Stefan, I appreciate the immense help and guidance given by the subversion community and agree that the tasks I have been pursuing haven't been particularly easy for me (although I did cater the confidence that i will be able to catch up.). You are right in saying that I would instead need to focus on tasks which match my skill set more than the ones which I would want to pursue since I took them up in the first place. Thanks a lot for those options, I will certainly look into those and try being more towards the contributing side and a little less on the "querying" side. Yes, being from a CS stream, I would rather prefer coding based tasks, though it is absolutely justified for me to take up say things like FAQ maintenance since they will enhance the little knowledge I have as of now.
Thanks, Shivani On Wed, Apr 3, 2013 at 5:52 PM, Stefan Sperling <s...@elego.de> wrote: > 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! >
