2010/10/15 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>: You're generalizing in ways that are invalid. Your behavior on this list, MZMcBride's behavior on this list, Trevor's behavior on this list, my behavior on this list -- all those things are very specific to us as individuals, and so are the community dynamics that result. There's no inevitability of outcomes, we're shaping these outcomes together now. That's, as far as I understand it, the essence of Roan's point. We can all work together to create a constructive and healthy atmosphere, all the time. And if we take our mission and our ambitions seriously, we all have an obligation to do so. It's fair to point out when anyone of us, as individuals, fail to do so. I didn't brush aside your points earlier, nor did Danese, nor did Tim, nor did others who responded to you. If you want to feel slighted, you have all the right and time in the world to do so. But again, that's your personal choice, not "systemic". -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

On Fri, Oct 15, 2010 at 3:53 PM, Erik Moeller <erik(a)wikimedia.org> wrote: I respectfully disagree. Attitude is not important compared to concrete things that are upsetting people. The number one thing that volunteers are unhappy about is non-deployment of volunteer code. Why? Because the only reason for their participation is so that their code should be deployed. When their code is neglected while other people's code is deployed immediately, solely because those other people happen to work for Wikimedia, that will result in a great deal of frustration no matter what attitude anyone approaches it with. And the solution is simple: Wikimedia has to allocate the resources to deploy volunteer code continually, just like employee code. Which it has, and that decision will have a much greater impact on the staff-volunteer relationship than any change in attitude possibly could. If enough people make the same personal choice, it's fair to assume that there's an underlying reason for it. In that case, appealing to the choice itself is fruitless -- look at the reasons for the choice.

Roan Kattouw wrote: Letting tensions and frustrations sit for months is a fantastic way to guarantee a much larger problem in the future. MediaWiki is a community-driven project and the community is being driven away. This isn't hyperbole, it's a statement of fact. Roan Kattouw (also) wrote: The problem with mailing lists is that they're great for creating a rallying cry, but shortly after the thread dies, so does the action. (Scan the archives for discussion about something like a parser rewrite or category intersection sometime and you can see what I mean.) The issues surrounding code deployment, branches, and special exemptions for staff-written code are well documented at this point. And the solutions are all fairly readily apparent. It isn't time to say "we need to come up a plan," it's time to _implement_ a plan. The alternative is that any implementation of a proper plan to fix the backlog becomes a typical Wikimedia procrastination situation where the deadline for moving forward is always "after X," where X is the next MediaWiki release, the next fundraiser, the next Wikimania, the next whatever. Erik Moeller wrote: You're the Deputy Director of the Wikimedia Foundation. You're directly responsible for the Chief Technical Officer, and as a consequence, the tech staff. You say you agree that the code backlog is a problem and you're in a position of power to address it. So what's your plan of action? What resources are you committing in order to fix this problem? MZMcBride

On 10/15/10 8:25 PM, Alex wrote: * Several new people were added to the code reviewers list. * Brion Vibber was contracted to provide code review "office hours". That looks like "action" and "progress" to me.

Hoi, I just had a look at the staff page at http://wikimediafoundation.org and I find many of the staff are just not there to be found. While the community is this big mass of people, it would be really valuable to have a place with a picture, a short cv and an organogram. Much of it is there but it is not kept up to date. It is really important that people who work for the WMF are knowable. The notion that only permanent staff should be included is imho not helpful, some are quite visible and important to the community as well. Thanks, GerardM On 16 October 2010 12:34, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:

Hoi, I have blogged about one of the "temporary" staff on my blog. While it is nice to have a list on meta, it makes more sense to have somewhere one list of staff permanent, contract, temporary... Fractured lists prevent people from finding those they need. I was looking for the person who is involved in documentation. I wanted to learn if he knew that the software behind translatewiki.net is used for the KDE documentation. The current "some animals are more equal then others" approach sucks. There are arguments about them and us and this opaque presentation hinders the adoption of (new) people in our community. Personally I do not care who is permanent or contract, it is irrelevant to me. I care to be able to find and ask the right person the questions that I have. Thanks, GerardM http://ultimategerardm.blogspot.com/2010/10/roan-is-temp-staff-at-wikimedia… On 16 October 2010 17:38, Chad <innocentkiller(a)gmail.com> wrote:

Roan Kattouw wrote: This sounds fine. I don't think anyone would have a problem with this. The question becomes: how is this plan going to be implemented? Right now, from my perspective, there's a huge single point of failure in code deployment. Namely, that only one person is able to do it for regular, general code updates (that is, others have the technical ability to do updates, but only for specific revisions and under specific circumstances). Having a plan is great and it sounds like a completely reasonable plan, but currently only Tim is able to do general code updates and he's not really around, from what I understand. And even when he is around, there's more code than there is time and other resources. This makes backlogs like the current one completely inevitable. There are a few solutions to this problem; can one of them be implemented? MZMcBride P.S. Congrats on your blog fame, or something. :-)

On Fri, Oct 15, 2010 at 5:58 PM, Erik Moeller <erik(a)wikimedia.org> wrote: I entirely agree that everyone should adopt a positive attitude and try to avoid an us-vs.-them take on things. Brion wisely pointed out on IRC that my earlier giant post on this topic could have been better written as "problems with the current MediaWiki development process" instead of "community vs. centralized development" (it even had "vs." in the name!). I tried from the beginning to word myself so as to avoid confrontation, but like many techy people, I'm not terribly good at diplomacy. Still, I can always try harder, and will. However, adopting a positive attitude will not fix non-attitudinal problems such as code not being deployed for months; or people making changes in a manner that results in other interested parties not seeing them until they're deployed; or people reverting others' commits because they contradict prior decisions that the original committer had no realistic way of knowing of; or other problems of that nature. Attitude does not play a big part in those problems, and improving attitudes will not help them. Indeed, pressuring people too much to avoid conflict will mask substantive problems. So while having a good attitude is important, it's largely orthogonal to any problems we might be having with "Collaboration between staff and volunteers", the title of this thread. (I wonder where the "n" in "attitudinal" comes from.) On Fri, Oct 15, 2010 at 6:07 PM, Trevor Parscal <tparscal(a)wikimedia.org> wrote: Oh, please don't mistake me -- I'm completely against anyone attacking others, assuming bad faith, etc. I don't believe in blaming people, naming names, or factionalism, and I think everything should be phrased in positive terms to the greatest extent possible (although not to the point of ignoring serious issues for fear of upsetting people). I try to do this myself all the time, both in MediaWiki matters and everything else, and if I fail sometimes -- or often -- it's due to my social ineptitude rather than lack of trying. I've also both publicly and privately asked volunteers to moderate their tone and speak more constructively about conflicts, with some success. It's just that, despite the many merits of a good demeanor, it won't help solve underlying concrete problems. For that, we need changes in procedure, in where work is assigned, or in other concrete things. As I said, we're starting to see this with code review, which is great, since that was always the number one issue. The way people act on their unhappiness is a very separate issue from the unhappiness itself, and they shouldn't be conflated. Ideally, the latter issue should just be fixed, and then the former will be moot. On Sat, Oct 16, 2010 at 4:34 PM, MZMcBride <z(a)mzmcbride.com> wrote: I don't think anyone is treating Tim as necessary for code updates right now. There are plenty of people with the privileges to do it, and it's not especially complicated or hard. It will require a considerable amount of planning for such a huge backlog, to do things like work out all the schema updates and have enough people on hand to quickly handle all the inevitable regressions that will arise. But I don't think any particular single person needs to be the one to do it.

2010/10/18 MZMcBride <z(a)mzmcbride.com>om>: Are you suggesting we deploy a revision that's somewhere halfway between the currently deployed revision and HEAD? I'm leery of that because we don't really know what the stability of that revision is. It'll likely also have issues that got fixed later, but that may be hard to merge in because of the large difference (hence more potential for merge conflicts) between the new deployment and HEAD. This is why I would like to deploy code that's as close to HEAD as possible, and to *stay* close to HEAD by doing regular deployments. I would personally feel comfortable to do a small-sized general update (say, a week's worth of code as opposed to the gigantic update needed to catch up with trunk) if there's a few other people around ready to jump in and help me if something goes wrong. For a large update with many potential complications, I do think Tim should be involved. Roan Kattouw (Catrope)

Aryeh Gregor wrote: You don't see any reason? Simply, because it does. How did we get into the current situation? One idea floated today in #mediawiki was to make a new branch up to the revision before ResourceLoader was added (grep "branch right before that").[1] This would allow a very sizeable number of revisions to be in a branch (from April to August, roughly) but also allow deployment and code updates to move forward sooner. Sometimes the easiest way to eat an elephant isn't to try in one bite. Any thoughts on creating a branch sooner than when ResourceLoader is ready? MZMcBride [1] http://toolserver.org/~mwbot/logs/%23mediawiki/20101018.txt

2010/10/15 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>: To repeat the subject line of this thread: it's a two-way street. I acknowledge that the current tensions are a byproduct of certain crises, and by no means meant to imply that staff members are practically innocent and that it's all the volunteers' fault. I also acknowledge that the staff has a part to play in fixing this situation (I literally said this), but the volunteers have a part to play too. That's what two-way means. To reiterate: I am *not* saying this problem is somehow disconnected from the other one or is somehow exclusively the volunteers' fault and responsibility. What I *am* saying is that both sides have roles to play. The staff's role is to collaborate with the volunteers better: this has been discussed extensively, so I won't go into detail there. Instead, I chose to highlight the volunteers' role in this thread. Their role, IMO, is to keep the collaborative environment positive. This means being welcoming to new staff, embracing them, pat them on the shoulder when they to things right and correct them when they do things wrong, while keeping their patience. I feel that especially the shoulder-patting and patience parts have been lacking lately, at least in the perception of the staff members I spoke to. This leads to them perceiving the environment as predominantly negative towards them, which does not encourage them. To expand on the patience part a bit more: staffers coming from outside the community need to adapt, and adapting takes time. If they, while still in this process, demonstrate that they "don't get it" (which may very well be the case, but I'd like to add "yet!" to that), they should be cut some slack on the grounds that some of this stuff is new to them, even after having worked at WMF for quite some time. Don't underestimate how long this process takes. We as a community go way back, and "outside" staffers have missed all that history. Roan Kattouw (Catrope)

On 10/15/10 2:44 PM, Aryeh Gregor wrote: If the problem is truly being caused by a few people's choice of action, then volunteers should be sympathetic to staff developers, and voice their grievances to those "few people" who can do something about them. In the mean time, I see you disagreeing with Roan that volunteers should cut the staff developers, especially the newer members thereof, some slack and assume good faith, which just doesn't connect. You should be agreeing with him - we should all be looking for ways to be nicer and more understanding of each other. If volunteers continue attacking staff developers then those few people will only hear about how the volunteers are being unfair, mean, and are more trouble than they are worth... Now - I don't want to accuse of you dissagreeing, I'm just stating that I found your message to be conflicting. As Erik has said on list just now - I think we all agree far more than we dissagree. And that's something that should bring us all together, not tear us apart. There is no crisis here, there's only a bunch of passionate people working to make things better - and I personally am thankful that we all care enough to talk about this. If the community was really dieing, this thread would have been one post long. - Trevor

2010/10/15 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>: +4,294,967,295 Let's focus on the code review situation and shelf this whole "staff/volunteer/community collaboration" discussion for a while. And by that, I also mean trying to keep references to it to a minimum and being less like the lines of "see? THIS is what's wrong with the staff folks" when something goes bad, something I've been hearing to an increasing degree lately (that's what the original post was arguing against). Like Trevor says, let's be nice to each other and be patient while the code review and deployment situation gets fixed. This'll probably take months, so I know I'm asking for quite a bit of patience here. But I believe Aryeh is right that regular code deployments will cure most of the problems we've been discussing, and I'm willing to bet on that by putting my disagreements with other people regarding this topic aside for the next few months, until we've gotten back to regular code deployment, at which point we can re-evaluate. My understanding is that Aryeh is also doing that, and I call upon you all to join us. Roan Kattouw (Catrope)

On Wed, Oct 20, 2010 at 11:37 PM, Domas Mituzas <midom.lists(a)gmail.com> wrote: Somebody's been confusing their signed and unsigned ints… -- Andrew Garrett http://werdn.us/

On 10/15/10 3:19 PM, Steve Summit wrote: well read this: http://lists.wikimedia.org/pipermail/wikitech-l/2010-October/049877.html I don't think Roan is saying the community should be the driving force of positivity, but there's a line that gets crossed where a volunteers unprofessional behavior is more of a problem than their contribution is worth. Volunteers are not really free for the Wikimedia Foundation. We spend a lot of paid employee time on communicating, nurturing and sometimes barely tolerating volunteers. We do this because it's valueable to us, not just for "free" work, but because we only exist to support this community. It's a key part of our mission. In short - volunteers should not have unlimited rights to abuse staff members just because they have contributed some kind of work without receiving payment, but staff members should never cease to work towards understanding and supporting the volunteers. There's a balance here, and Roan is just trying to remind people of that. - Trevor