Hi Aryeh, Thanks for bringing this topic up. It looks like its been a pretty productive conversation so far, so I hope I don't ruin it. ;-)
Here's where I think you and I are on common ground. We seem to disagree about magnitude (e.g. "more" vs "all" or "less" vs "none"), but I think we can agree on direction: a. More peer-to-peer communication needs to occur on public channels. As many of you know, prior to starting at Wikimedia Foundation, I had been a (very) peripheral member of the development community (lurking on IRC, contributing a patch or two, developing extensions, attending Wikimania 2006 dev days). I knew I had a lot to learn about the development process, but I've been surprised about how little I did know, which is in part due to the fact that many conversations that I expected to be public and discoverable by search engine weren't. It makes it much easier to involve and vet newcomers if we can watch their participation in our peer-to-peer communications. b. Volunteers need the opportunity to participate as peers. If someone demonstrates competence, a track record for useful contribution, and an ability not to make the existing core contributors all stabby, they deserve a seat at the table. We can't make everyone a full development peer in the same way that we can't make everyone a sysop in their respective editing community, but we should push the boundaries the same way our editing communities do. c. Being on the staff at Wikimedia Foundation shouldn't automatically confer any special authority on MediaWiki trunk or even an automatic seat at the table when deciding what belongs there. Of course, many of the people at WMF are there because they've earned a special place in the community already, but getting hired shouldn't be a shortcut to that. Wikimedia Foundation staff dominates MediaWiki development as the primary financial contributor to its development, and by virtue of running many of the highest traffic MediaWiki websites. But we shouldn't have norms which keep other organizations and individuals from operating as peers in a more diverse developer ecosystem. Many of the greatest open source projects have organizational diversity in their contributor base (Linux, Apache, etc), and it's great to aspire to that. d. No one should be so sure to what degree Wikimedia Foundation employees need exclusive control of the code that runs on Wikimedia's production servers. There is a certain unique responsibility that Foundation employees have to keep the servers running, and to support the strategic goals as laid out by the community, the board, and our executive staff. However, that doesn't mean the correct answer is to become control freaks or lock out the volunteers that helped us get where we are, let alone shut the door to new volunteers. It just means that, unlike with point "c" above, we're in much more uncharted territory. There aren't many examples of open source projects for which the community is as involved in the version and configuration of the software running on the production cluster as this community is. The difference between "c" and "d" above is very important, because it seems to be where the core of the disagreements are about direction setting. If most non-Foundation developers that have weighed in on this thread are most interested in "c", this would be a straightforward problem to solve. However, I suspect many people care about "d" every bit as much, and as a result, I think we're talking past each other a little bit. I'm not going to stake out a firm position on "d"; it's a complicated matter, and I think I can argue both sides of it. I think it's a fruitful area for discussion on foundation-l, since a lot of the tension has to do with non-technical staff and community members being more involved in the direction setting now that the Foundation budget actually allows for such a thing (and some of the direction-setting comes from the budget itself; e.g. directed grants with deliverables and schedules). Points "a" and "b" are points that I plan to push harder on, partly as a result of this thread. The monthly update that the EPM team put together [1] is a step in that direction. Merely broadcasting what we are doing isn't sufficient to actually achieve a peer-to-peer relationship, but the information is an important prerequisite. We should be able to draft the October version of the update on mediawiki.org.[2] You now should have a better idea of the program managers to pester to get involved in something we're working on. There are still plenty of internal meetings, but I think I might be able convert at least one or two of the ones I'm responsible for into public IRC-only in the near future. Inviting the general public to our telecons won't scale, but I think we should keep an open mind about inviting key non-WMF contributors to more of our conversations, and come up with more collaboration tools that scale better but also have many of the positive properties of face-to-face collaboration and/or telecons. One potential model to look at is the IETF model [3], where face-to-face conversations are acknowledged as a necessity, but decisions aren't final until they're made on the list. I suspect it will depend on the nature of the decision and the speed with which it needs to be made (the downside of emulating a standards body is that all of them, including the IETF, are legendary for being rather slow to act). Aryeh, I doubt we'll go as far or as quickly as you probably are hoping for, but I think it's fine to push for more and keep us honest. Rob [1] September WMF Engineering update: http://techblog.wikimedia.org/2010/09/wmf-engineering/ [2] Stub draft of October WMF Engineering update: http://www.mediawiki.org/wiki/WMF_Engineering_Overview_October_2010 [3] Tao of IETF: Section 5.2 "Getting Things Done in a Working Group": http://www.ietf.org/tao.html#getting.things.done _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
