On Fri, Sep 3, 2010 at 3:05 AM, Aryeh Gregor <[email protected]> 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 [email protected] a publicly logged mailing list. I see no reason why it should not be (you may create a separate internal mailing list). _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
