Sent from a mobile device, please excuse mistakes and brevity On 18 May 2013 17:42, "Noah Slater" <nsla...@apache.org> wrote: > > Hey folks, > > I've been talking a lot about what "committer" means recently. As a person > with a vote on the project, do we award this position to people who > contribute code, or people who we trust? And are there instances where we > trust someone with a vote (i.e. they've shown merit, sustained > contributions, etc), even though they do not (and are not likely to) > contribute code?
IMHO Merit should be earned for all constructive engagement with an ASF project. > > One of the things that occurred to me is that I have no idea how other > people do it across Apache. I'm involved in two TLPs (CloudStack and > CouchDB) and the approaches are quite different. > > So I was thinking how I might learn more about this. I know ComDev is here > to document stuff, but I recently took a look your website, and I noticed > that some things are being recommended that seem a little unusual, and > there is no mention of how common that thing is across Apache. > > (In this instance, we were talking about how to elect people to the PMC, > and the ComDev website says that in most cases, all committers are on the > PMC. This is interesting, because I believe this is actually the minority > position across TLPs. But I have no data to back that up.) > Where does it say "most"? The only relevant bit I can find is where we have template emails for inviting committer. On that page it says " Some projects make committers PMC members automatically, if this is the case then merge this with the following template (PMC Vote Template)" Personally I do think it is "most" but like you only have my own experiences to go by. Either way the ComDev site should discuss the benefits and drawbacks of each approach not appear to make recommendations. > And it occurred to me that it would be interesting to do a survey of the > Apache TLPs. i.e. Just ask people. Then collect that data, and present it > in some meaningful format. > Maybe. But in this specific case what does it matter how many projects do and how many do B? What is important is that each project makes an informed decision. > This is a project I am quite interested in doing, with a little guidance > from people on this list. Assuming, that is, that you folks think this is > interesting / worth doing. I certainly don't want to discourage you with my comments above. I do think the information would have value, I'm just not sure we'd want to give the impression that statistics are more important than understanding. Of course, part of understanding can be statistics. > > So, the next questions are: > > 1. What sorts of stuff are we interested in finding out? > Off the top of my head... requirements for committership Requirements for PMC Rotating PMC Chair or not RTC Vs CTR Patches via mailing list or JIRA/Bugzilla Merit for documentation? Merit for marketing? Merit for user support? Merit for administration? (E.g. bug triage, release management, infra management, build maintenance etc) > 2. What's the best way to conduct surveys? A Google doc form is pretty simple and works well if the number of questions is low. However be aware that conducting surveys is very hard. The creation of a set of questions that don't lead to a limited set of answers is hard. The more conversational approaches you mention below are more reliable but as you observe much harder to evaluate. > > I think 1 can be handled separately to this thread, and on an ongoing > basis. That is, I have some ideas, but I think they ought to be > discussed separately. Sorry already dumped a few above :-) Ross > > My thinking is that this should be a long, slowly-paced activity. I don't > want to tire anyone out. And I think it could form part of a continual > data-gathering activity. > > Right now, I am thinking about 2 > > A few ideas: > > a. Send an email to each dev@ list with a set of questions. (I think each > survey should be small, focused on a specific topic, which ought to > increase the chances that people respond and also produce meaningful > discussion.) I'm not sure, but I think this is likely to result in fewer > answers, but more discussion. Collecting and analysing the results would be > a little harder, but not impossible. > > b. Send an email to each dev@ list with a link to a survey. I could use > something like SurveyMonkey. This allows for very structured > questions/responses. It also means that people are answering in isolation, > which means more people might respond (i.e. are not put off responding > because someone else already said stuff). But is also likely to result in > less discussion on the list about the topics/questions raised. > > c. Send an email to committers@ with a link to a survey. Should result in > less discussion, but might also result in less participation. (I expect > less than 10% of the subscribers to respond.) I would certainly not want to > put the questions in the email if I was sending to committers@, because > discussion on that list would not be appropriate. > > Would using something like SurveyMonkey be problematic? As part of the > activity, I would make sure that all the data was made available after the > fact. That is, just use SurveyMonkey as a tool, and then put the data back > on to a mailing list, or wiki, or perhaps even into a repository if ComDev > has a repository for me to commit to. > > Would love to have your thoughts on this. > > As I mention, this is something I have in mind as a project I would like to > undertake with the guidance from people on this list. > > Thanks, > > -- > NS
