On 9 May 2013 00:23, Rob Weir <robw...@apache.org> wrote: > 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. > your work has really made it easier (I wish it had been available when I started)...I have however observed (maybe wrongly) that relative many start on the orientaion pages but only few come out on the other end....I have been wondering about why, one idea could be to question all those that started.
> 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?" > +1 a typical developer is not easy to handle, if you put them in a square box they wish for a round and visa versa. > > 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. > yes and no yes because we try to tell people to grasp the whole system in one-go "start by build AOO", that is a nice way of making a developer feel insecure. no because the build system is not really a problem, our system could be a lot better, but at least it works...look at many other projects and count the number of manual steps you have to do. Documentation is a clear issue. > > 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. > I think you are really right about a) "mentor". When I started we had that discussion, and I still think I would have saved us all for a lot of trouble had I had a mentor I could ask. Today I would not mind help mentoring newcommers, in the fields where I have knowledge. I dont really think b) and c) will make a difference in attracting new developers. What we need to do (in my opinion) is to define small tasks (preferable "hot" topics), not solve a bug (remember an office system is not really "hot" for developers, and solving bugs is boring. We could (just as an example) make a nice task, of using the google api to exchange information, or build a memory database with our text files and generate/control terminology. I know I just other words than "build the AOO" and "bugs", but it sells better. When we blog for developers, we should give them specific ideas to what they can do (and of course say it just ideas), so they can identify themself with the task....no one can come in from the street and identify with the whole system. rgds Jan I. > 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 > >
