On Tue, Oct 25, 2016 at 02:19:06PM +0000, Ross Gardler wrote: > First, I'm tired of hearing it too but let's not be fooled, most of the time > it comes from people ill informed about how the ASF works.
I have no doubt about that. Maybe we can do a better job telling people how we work then? > We use social controls within the projects and we have a fully independent > board to handle escalations should a community member feel that their (or > anothers) merit not be recognized. Let me tell you a story to illustrate what kind of problem I see with that (and I'm happy to be told, that this is just me having that problem or not reading the docs): I came to the ASF when nutch went from sourceforge through the incubator to be a sub project of Lucene. Being the naive student I was I had no idea what this whole ASF thingy was - all I knew about was the web server in my Debian Woody distribution with the same name. I was blissfully ignorant to what kind of contributions would be welcome in the project and what merit I should gain through that. A year or two later I was a bit closer open source at Apache, I had subscribed not only to nutch but also to Lucene mailing lists. A learnt about a conference related to the projects close to where I was working back then - namely in Amsterdam. I looked at the ticket prices expecting to see something like FOSDEM, Chaos Communication Congress, Linuxtage or some such which I happened to know. But the prices were just way above and beyond anything I could afford. And my research group would only really pay for scientific conferences. Fast forward another year or two, I was working for a small company in Berlin (neofonie, back then doing search consultancy mainly), I had co-founded Apache Mahout, as a result I was entitled to get a committer discount. I asked my manager for vacation days to go - and got a "let me check if we can actually send you there on our cost" as a reply. Back at that Apache Con EU 2008 in Amsterdam was when I first understood some of the basic concepts of how things are supposed to work around here, what kind of contributions should be rewarded. Only much later did I come across books like Producing Open Source Software, did I watch several keynotes on how things work over at Debian and friends, did I read about C4 at ZeroMQ, did I see things like the "Poisonous People" video. To cut a really long story short: I may be mistaken, but I think even with the incubator community members may not even be aware of a lack of merit. Look at the thread over here: http://mail-archives.apache.org/mod_mbox/community-dev/201610.mbox/browser isn't that already showing that some questions arise only way after incubation? > If this is breaking down then its a problem within the PMC not with the > process, which has served us well for many years across many projects and > should, IMHO, serve us well for many more. Rather than starting to look for a > solution to a problem purebred by others perhaps we should look at why they > have this perception. Just for the record: I don't think we have a process problem per se here. We might have an education problem: In terms of what (even if it's little) we expect from projects, in terms of what people should do when they see those expectations not being met, in terms of what is being done within the ASF to keep things in line (or phrased more bluntly: If everything goes wrong, what can you expect the board to do to your project? How did we educate projects in the past?) > Here's my thoughts... > > Open source, in general, has changed. Its gone from mostly individual hackers > from small collaborating companies "scratching their own itch" to mostly big > business and will funded startups paying individuals who sometimes don't care > on a personal level. This has resulted in the emergence of a different flavor > of open source. One in which money and metrics count more than community and > code. I'm the money and metrics model success means market disruption rather > than collaboration on code. This matches with some of what I see as well. > I maintain that the Apache Way is still a highly valuable and repeatable > process that when applied correctly brings the highest chance of success > (where success is valuable open source code). It is a process that is > designed to ensure that those who care on a personal level have as much > influence as those who are motivated by external need. It is a process that > leaves money and metrics at the door but recognizes community and code > contributions quickly. The "recognizes *community* and code contributions *quickly*" is something I would like to see validated across communities. I'm pretty sure even Mahout is guilty of having waited long to hand committer status out to people who contribute on a non-Java-level. > I'm not a fan of metrics. They are often misleading and allow any story to be > told. I'm much more interested in people taking responsibility for the health > of their community than taking the easy route and monitoring an arbitrary > metric. Those people should be working within project PMCs to ensure all > contributions (code or otherwise) are being recognized. They should be > identifying new committees not a "number of commits" metric that ignores the > individual who facilitates consensus and merit recognition on our mailing > lists. Just for the record: "number of commits" IMHO is way too short sighted. Documentation, help on mailing lists, providing use cases in JIRA to issues all count. > If a PMC is devoid of such individuals then it is nothing more than a shared > code base regardless of how many new committers are brought in. Those > projects exist, but they should not exist in the ASF where we stand for > "community before code". > > The current metric, reported quarterly, to a vendor neutral and member > elected board is "last addition of a committer". This is good. When it goes a > long time the board should ask "why". Sometimes its because a project is in > maintenance mode (no problem with that) other times its because a PMC is not > recognizing contributions and needs reminding. This is a good start, and I've seen people ask why often in the past. I'm not sure it captures the balance between busy projects with paid contributors that are being added routinely and people contributing as a side project but on a continuous basis. I have no idea how to capture that balance well though. > Do we really need metrics? Perhaps we need more awareness in our communities > about why building a personal profile in a project is good for both career > and community. Then we can help people build those personal profiles by > ensuring we recognizing all contributions that bring stability, independence > and health to a project community. +1 Isabel --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
