On Wed, May 8, 2013 at 6:49 PM, janI <j...@apache.org> wrote: > 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. >
Frogs lay a million eggs and only some survive. A human has one and carefully minds each one for 20 years. Both species survive. That's what matters. The fact is good documentation leverages the time of one volunteer (the author) in a reusable form that then can scale. That combined with a strong outreach capability means that we're more like frogs. If you want something more like a mammal then you need parents (mentors) willing to spend an intense amount of time on that task rather than on coding tasks they would rather work on. > >> 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. > Attracting new volunteers is not the issue. Want 20 new dev volunteers on the mailing list by Monday? I can give you that, easily. Getting them to get up to speed with building and contributing to the project -- that is the hard part, right? > 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. > Certainly it makes sense to reinforce the idea of AOO as being a platform for innovation, of an app used by millions, where you can try out new ideas. We've tried that approach before, e.g., in the GSoC blog post: "OpenOffice software is central to the daily work of its users, with text documents, spreadsheets and presentations. There are good opportunities to explore applications that connect OpenOffice to cutting-edge disciplines such as text analytics, natural language processing, social network analysis, the semantic web, etc." The results speak for themselves. It attracts volunteers, but getting them to scale the wall of AOO development is still the problem. > 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. > If someone already has the skills needed to contribute and is someone who finds 'hot" topics interesting, then they are most likely have their own "hot" ideas that they want to implement. In fact we've had no shortage of people proposing "hot" new ideas that they want to work on. But getting started means learning to walk before starting to run, and that means the build complexity and the dev documentation are still the critical paths. It is worth searching the list archives for new volunteer posts over the past year or two to see how this plays out. What I'm saying is not theoretical. It is what I've seen over and over again. Note: mentoring and developer doc pretty much accomplish the same thing. But we probably want the stuff that everyone needs to know into accurate doc, and save the more precious resource of developer time for those who have mastered the basics. In summary, think of it as a funnel, widest at the top: 1) The universe of people who might want to help 2) Those who are motivated to investigate helping 3) Those who take the first step of posting to the list and volunteering 4) Those who actually have the skills needed to reasonably contribute to development 5) Those who actually do contribute 6) Those who become long-term contributors/committers At the top of the funnel is thousands. Even 3) can be hundreds. We lose people after that. Whether it is because of lack of skills or something else we don't know. Certainly our wide calls for volunteers (the frog approach) will tend to that result. Regards, -Rob > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
