On Fri, Sep 3, 2010 at 3:05 AM, Aryeh Gregor
<Simetrical+wikilist(a)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(a)wikimedia.org a publicly logged mailing
list. I see no reason why it should not be (you may create a separate
internal mailing list).