Being perhaps a late comer to this thread (just got back from vacation) I need to ask: what is the problem we're trying discuss here?
During my tenure at ASF I've definitely seen non-code contributing project participants being treat with utmost respect and elected all the way to PMC membership by some projects. I've also seen code contributing heavy-hitters being treated like crap by some other projects. Honestly, I don't think this is a function of terminology. An orthogonal issue, is that of community health metrics. I tend to be in the camp that considers them extremely valuable source of feedback. To that end, there's currently an effort underway to get some sort of POC in place and let others clearly see the value. Now that I'm back from my vacation (and a prior 3 weeks of corp. sprit to OSCON) I honestly expect to have more time to dedicate to the project. In anybody on this list is interested -- the more the merrier. ;-) Thanks, Roman. On Sat, Aug 2, 2014 at 3:05 PM, Pierre Smits <pierre.sm...@gmail.com> wrote: > Noah, > > First of all, and I guess that you are aware of this, the document ‘How the > ASF Works’ describes the following roles regarding non-committing > participants in the communities of the ASF projects: > > The *user*: A user is someone that uses our software. > For the sake of brevity lets accept that this can also be an organisation > that consumes the work of a project, and is represented by a person. > > The description then reads on that these ‘users’ contribute to the Apache > projects by providing feedback in the form of bug reports and feature > suggestions. And users participate in the Apache community by helping > others on mailing lists and support forums. > > The *developer* (aka the *contributor*): is a user who contributes to a > project in the form of code or documentation. They take extra steps to > participate in a project, are active in the developer mailing list , > participate in discussions, provide patches, documentation, suggestions, > and criticism. > > Both descriptions use the word ‘contribute’, but the first group of > participants is regarded as users (not contributors), and the second group > does (more or less) the same as the first group (but has this aka > ‘contributor’ which the first doesn’t have, but is also described as > ‘user’). > > I would say that a user of the work of a project participates in the > community, because he (or the organisation he represents) consumes the work > and has questions thereabouts. Questions like: > - What is this function we’re talking about? > - When will the function be released? > - Where can I find the documentation? > - Why does this function not work? > - How should this function work? > > And why is that? I would say, because nine out of ten times the second most > important work of the project is incomplete, inconclusive, to complicated, > to extensive, etc. I am talking about the documentation related to the code. > > Or he might even rant about how shitty the work or the project is. > > A contributor is a person who does more than just ask these questions. He > provides feedback in the user mailing list to such questions, he hold > presentations on the project and the work of the project, he registers bug > reports , he improve documentation or the code base of the project, or > write books about the work, blogs, tweets, etc, etc. > > Nevertheless, without the clear-cut distinction between the two there will > always be ambiguity about what a contributor is, and might lead to the > (perception of) degradation of this participant to second class. As has > been written about in the past few weeks. > > *Measuring contributors* > When talking about measuring the number of contributors in a community we > should first clear the definitions. > > Based on what a contributor does, one could say that it could be measured > by whether a participant is subscribed to the dev mailing list and/or the > equivalent of a JIRA account for registering bugs and patches. As it more > likely that a contributor will register to the dev mailing list to > participate there as well or have a Issue Mgt account than somebody who is > just using the work. > > But that is not totally conclusive, as some contributors can choose to > operate only in the user mailing list, or hold presentations. Such > activities doesn’t make them less of a contributor. So something more needs > to be done there. Or am I wrong here? > > *Measuring community activity (project liveliness)* > I agree with you that measuring the number of unanswered threads in the > user mailing list says something about community activity. But, the same > goes for unanswered threads in the dev mailing list. So that should be > included as well when trying to have something conclusive to say about the > liveliness of a project. > > But why exclude trends in influx of new users and new contributors, as both > also say something of the liveliness of the community and hence the > project? The first indicates adoption, the second commitment. > > The first aspect (new users) is easy to measure by counting the new user > mailing list registrations in a period, or even the first posting of a new > registrant, or the combination of both. This should be feasible to achieve. > Or isn’t it? > > The second aspect (new contributors) can be measured by registrations of > new accounts in the dev mailing list of a project, and/or registration of a > JIRA (or equivalent) account. Or even the number of reactions made by each > registrant to a thread in the user mailing list. But I suspect that it also > needs to be a combination of sorts. Don’t you agree? > > Best regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com
