On 04/09/10 03:39, Aryeh Gregor wrote:
On Fri, Sep 3, 2010 at 1:20 AM, Tim Starling tstarling@wikimedia.org wrote:
Your recommendations seem insensitive and unrealistic. What works for you does not necessarily work for everyone.
It works for many, many open-source projects.
I don't think you really know that. It's hard to see how much work goes on behind closed doors when you only have a cursory involvement with the project.
None of the open source projects I've been involved with fit the model you describe. For instance, Squid makes heavy use of face-to-face meetings, despite their geographically distributed development team. PHP has projects developed by individuals and small groups which are then reviewed on the mailing list.
Does Wikimedia want to be among them, or does it want to be among the projects that are open-source but have a stagnant community because they don't involve volunteers enough and the code is tightly controlled by a sponsoring organization? There are countless projects of both types -- both strategies work, to a degree. Completely closed-source development works too. Wikimedia is free to pick whichever model best fits its needs and ideals.
I think that's a false dichotomy. For a start, control and design are two different things, as the case of the collapsed interlanguage links demostrates. Just because an individual or small group designs something doesn't mean the community will accept it.
Design by individuals or small groups, with open community review and consensus decision-making, is entirely consistent with a thriving community. I'll grant that it's not be ideal, and that an open design process should be encouraged where possible, but it's not a contradiction as you seem to imply.
My goal as a developer is to support the community such as it is, not to browbeat shy or otherwise sensitive developers into either posting their comments in public or keeping their thoughts to themselves. And my goal as a community leader is to seek consensus on all decisions and to defuse conflict wherever possible by finding compromises. I don't think these two things are contradictory.
I can say that despite being a nobody at Mozilla and having gotten only one (rather trivial) patch accepted, I feel like I'm taken more seriously by most of their paid developers than by most of ours.
I'm sorry to hear that, and I'd like to know (off list) which paid developers are making you feel that way. I've made it pretty clear to Danese that I think you're one of our best volunteer developers, and that you should be given whatever you ask for, which, I think it's understood, includes respect. Maybe I can help to get that message to filter down to the rest of the organisation.
I know more about what Mozilla is planning to do in their next release than what Wikimedia employees are planning. I've had lengthy discussions on occasion with core Mozilla developers, and sometimes I've gotten something changed because of it. I can say none of these things about any Wikimedia project that's dominated by paid employees.
There are two projects which Wikimedia employees are working on for the next core release: the resource loader and the new installer. Both of them have been discussed on wikitech-l, and both have invited community involvement by way of design documents published on mediawiki.org. Both of them did their initial development in a branch, which anyone was free to review and contribute to.
-- Tim Starling