2010/9/3 Aryeh Gregor <simetrical+wikil...@gmail.com>: > * 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) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
