On Fri, Sep 3, 2010 at 3:05 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
- Consider what to do about code review. This is pretty much the
hardest problem on this list, which is why I don't propose a specific solution here, but there has to be a better solution than "assume a bunch of employees are trusted enough to sync their own code, force everyone else to wait months for central review".
There are three ways this problem may be dealt with: * People responsible for code review focus on code review. * People responsible for code review involve more people to review code. * People responsible for code review don't do code review and don't want to lose the control over code review process -- what is done now, does not work. The review backlog is one of the things I stopped contributing at some point.
- Stop concentrating tech employees in San Francisco. Either have
most of them work from home, or perhaps establish other small offices so that they're split up. The point is, make them rely on telecommunication, because if you put people in the same office they'll talk a lot face-to-face, and volunteers simply cannot participate. The purpose of putting people together in an office is so that they work together as a team, and this is exactly what you do *not* want, because volunteers cannot be part of that team. This is the second-hardest problem, or maybe the hardest, and I can't give a full solution for it either. I'd suggest checking with Mozilla about how they do it, because I know they do have offices, but they're a perfect example of community-oriented development.
That won't work. Face-to-face communications are extremely efficient for many things (like Roan pointed out, it works well with code review).
- Explicitly encourage all paid developers to do everything in public
and to treat volunteer developers as they would paid ones. I'm not saying this should be enforced in any particular manner, but it should be clearly stated so that everyone knows how things are intended to be.
Or at least document all their decision in public.
- Shut down the secret staff IRC channel. Development discussion can
take place in #mediawiki, ops in #wikimedia-tech, other stuff in #wikimedia or whatever. If users interfere with ops' discussions sometimes in #wikimedia-tech during outages or such, set all sysadmins +v and set the channel +m as necessary. That's worked in the past.
AFAIK this is mostly a sysadmin channel.
- Shut down #wikimedia-dev (formerly #wikipedia_usability, kind of).
The explicit purpose of the channel is to allow development discussion with less noise, but "noise" here means community involvement. In community development, you do get a lot more discussion, but that's not something you should try avoiding. In general, use existing discussion fora wherever possible, and if you do fragment them, make sure you don't have too much of a staff-volunteer split in which fora people use.
I'd rather rename it to #mediawiki-dev.
- Stop using private e-mail for development, at least to any
significant extent. If there are any internal development mailing lists or aliases or whatever used for development, retire them.
Or at least make usability@wikimedia.org a publicly logged mailing list. I see no reason why it should not be (you may create a separate internal mailing list).