2010/9/3 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>:
* 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".
The current code review
situation is a problem, and I don't have a
ready-to-go solution for it either. Just wanted to point out I do
completely agree with one of your important points before I start
disagreeing with parts of almost all your other points.
* 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.
I personally don't think it
should be necessary to enforce discipline
(i.e. doing stuff in public) this way. Sometimes, you just want to
bounce your ideas off this one person that happens to be an expert in
that specific field. To give another example, I did in-person code
review at the office with Ryan Kaldari last week, which was very
productive. Both are inherently one-on-one and don't need to happen in
public: in the bouncing ideas case, you're gonna take it public later
after one person has told you it's not totally insane, in the code
review case there's barely any benefit to doing it in public because
it's really this one guy reviewing revisions written by this other
guy.
I also think that we already have a fair number of tech employees
outside of San Francisco, and AFAIK we're definitely open to hiring
remote people for tech jobs unless in-person interaction is essential,
say for a CTO or an EPM (although we do have a half-remote EPM). I do
agree that the current level of community participation and feeling
like you're part of the community is lacking, but I don't agree with
your solutions.
* 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.
I mostly agree here. As I said above I think there's things that don't
need to happen in public (little to no added value while raising the
bar: walking over to someone's cubicle is easier than broadcasting
your possibly stupid idea to the world), but I agree that we're not
doing enough in public at this time.
* 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.
You're
assuming that development discussions actually take place in
these channels, which is not the case. We mostly use them for
chit-chat and private or office-related things. Questions like "how
should I design X in my code" very rarely show up in these channels,
and I don't think anyone would have a problem with being more
conscious about this and moving to a public place for such a
discussion.
* 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.
No, "noise" means bots and people trying to support people
with
questions like "how do I disable anon reads on my wiki" as opposed to
developers (paid and unpaid alike) being engaged in a design
discussion. Maybe #wikimedia-dev should be renamed to #mediawiki-dev
to remove the suggestion of WMF-exclusivity, but I definitely see the
value of a channel dedicated to communication between developers with
support questions and bots kept out.
* Don't conduct teleconferences about development,
ever. Even if
volunteers are invited (are they?), time zones and non-MediaWiki
obligations make all synchronous communication much harder for
volunteers to participate in. Rely primarily on mailing lists, and
secondarily on publicly-logged IRC channels (where at least it's easy
to read backscroll).
* 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.
These points are mostly fair in that the usability team (which I was
on) used to have a lot of discussions on the phone and over private
e-mail. However, we (features engineering team, which pretty much all
the usability folks got moved into) now have a weekly meeting format
that focuses more on what each individual has been doing the past week
and will be doing the upcoming week and less (still nonzero in some
cases, that's something I'm sure Alolita will be willing to fix) on
discussions about features.
I don't know how seriously these suggestions will
be taken in practice
by the powers that be, but I hope I've made a detailed and cogent
enough case to make at least some impact.
Some of your points are good, some I disagree with, and some I think
are based on paranoia-fed overestimations as to how secretive we're
being. I definitely think we need to move more discussions to public
places and I will advocate for that to happen, but I don't think we
need to take things quite as far as you propose. So let's start by
getting the powers that be behind that idea and see if we can improve
the situation that way first.
Roan Kattouw (Catrope)