On Wed, May 8, 2013 at 6:03 PM, janI <j...@apache.org> wrote: > On 8 May 2013 23:28, Rob Weir <robw...@apache.org> wrote: > >> On Wed, May 8, 2013 at 5:20 PM, janI <j...@apache.org> wrote: >> > On 8 May 2013 23:10, Rob Weir <robw...@apache.org> wrote: >> > >> >> In Wed, May 8, 2013 at 5:03 PM, janI <j...@apache.org> wrote: >> >> > Hi. >> >> > >> >> > I have done an analysis of our svn tree (trunk, ooo-site.....), and >> would >> >> > like to share the results with the community. >> >> > >> >> > I counted the committer/revisions (NOT files) made over different >> periods >> >> > of time: >> >> > >> >> > The last 2 years, 80 committers have been active. >> >> > - top five was: arist, robweir, kschenk, hdu, alg >> >> > The last year, 58 committers have been active. >> >> > - top five was: robweir, hdu, arielch, alg, jani >> >> > This year, 26 committers have been active. >> >> > - top five was: jani, hdu, robweir, alg, paveljanik >> >> > >> >> > The top five list is only for fun, some of us commit single files, >> others >> >> > bunch of files in a single release, so it tells nothing about the real >> >> > activity. >> >> > >> >> > If we look at committers with a regularity (at least 1 commit pr >> month) >> >> > figures get different: >> >> > The last 2 years, 37 committers have been regulary active. >> >> > The last year, 38 committers have been regulary active. >> >> > This year, 18 committers have been regulary active. >> >> > >> >> > For interested details are available as: >> >> > people.apache.org/~jani/topCommit6mdr.txt >> >> > people.apache.org/~jani/topCommit1year.txt >> >> > people.apache.org/~jani/topCommit2year.txt >> >> > >> >> > Considering that we are now heavely preparing for the 4.0 release, I >> >> would >> >> > have expected the opposite pattern (more committers today). >> >> > >> >> > It is always dangerous to interpret numbers, but I think it is save to >> >> say, >> >> > we need to work harder (rob have already done a lot) to attract active >> >> > members. >> >> > >> >> >> >> Remember, not all contributors are committers. It might be worth also >> >> looking at names in the SVN commit memo for "Patch by:" >> >> >> > That is a fair point...I looked at the mailing archive, and did not find >> a >> > lot of mails with patches. >> > >> >> Shouldn't need to look at the mailing list. We've been trying to >> encode this in the logs consistently per these conventions: >> >> >> http://subversion.apache.org/docs/community-guide/conventions.html#crediting >> > > out of 7.595 revisions (over 2 years) 507 have "patch by" and most of these > are the names of committers (e.g. ariel, pavel). >
507 patches? Cool. Of course we did not use that convention for recording patches for the entire duration of the project, but it would probably be too much work to tease out those. > This year we have had 2 patches f and last year 6 patches, so it does not > really change the picture. > Ah, the picture. Yes. A few things to think about: 1) We have a powerful ability to get the word out when we want something, via our mailing lists, web site, blog, Facebook, etc. We can get any message in front of 10's of thousands of people in a day. 2) We've had mixed success with "call for volunteers". It is very easy to get a dozen people to respond to a call for volunteers and post to the mailing list and offer to help. With a QA call for volunteers we even had 50 people respond! But getting them to actually contribute in a meaningful way... well, willingness to help is not enough. 3) That's why I created the new volunteer orientation pages on the website. It attempts to get volunteers started, familiar with the project, etc. It seems to work better with the more structured areas of the project, like translation and QA. In those cases we have a regular set of tasks to pick from, a well-defined process and workflow. It is easier for a volunteer to get started. That approach has worked relative well there. 4) However, the "here's a website -- read it and get started" approach doesn't work as well for the more open-ended areas like coding and (interestingly) marketing. Those areas don't have a set workflow. It requires more initiative from the volunteers. It is more self-directed, "What do you want to do today?" 5) Development is also made more difficult by the intrinsic complexity of the code base, the build system and the poor state of the developer documentation. That's my observation on recruitment. I think that doing better with development volunteers will probably require that existing coders spend time either a) mentoring new volunteers one-on-one, b) cleaning up the build system, c) improving the documentation, or all tree. The new "rejuvenation" branch looks like it could be a move in the right direction. Regards, -Rob > rgds > jan I. > > >> That way, we can use the Contribulyzer script to create a tally: >> >> http://www.red-bean.com/svnproject/contribulyzer/ >> >> I just mention this since inevitably someone tries to compare with >> projects using distributed version control, were contributor names are >> included in the core VCS metadata even if they don't have rights to >> pull into the main repo. With our use of SVN only core developers are >> recorded in the core metadata. The others are manually encoded into >> the log. >> >> Regards, >> >> -Rob >> >> >> >> >> Also, watch out for how branch -> trunk integration is tracked. For >> >> example, if a developer does months of work in a branch and then >> >> integrates it into the trunk, how is that recorded in your script? I >> >> saw one analysis of our commits that took months of work on the >> >> Sidepanel and called it all a single commit when it was integrated! >> >> >> > >> > I did not only look at trunk....it is the total commits from trunk, all >> > branches, ooo-site and a little bit in dev-tools. >> > >> > You can see that commits in branches count, otherwise I would never have >> > made top 5. >> > >> > The script does not catch if committers use git locally and only commit >> > when something is finished...but please dont look too much at the commit >> > numbers (top five) they are for fun >> > >> > The number of different committers is what really matters, and if we had >> > one volunteer that did many patches he/she would have been nominated >> > committer. >> > >> > rgds >> > jan I. >> > >> >> >> >> -Rob >> >> >> >> > Rgds >> >> > Jan I. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
