Since the discussion about staff collaboration with volunteers started a few weeks ago, actions and statements by staff members have undergone an increasing amount of scrutiny and criticism. That in itself is not a bad thing necessarily: staff members need to be kept on their toes and not be allowed to get away with doing bad things, and some scrutiny and criticism is needed to accomplish this.
In recent weeks, however, posts on this mailing list have gone way beyond 'some' scrutiny and criticism, instead suggesting something closer to distrust and paranoia. Statements made by staff members have been picked apart, with anything that could be interpreted to suggest an exclusive, disrespectful or otherwise negative attitude towards volunteers being interpreted this way, along with the occasional ominous warning about how the world will end if this attitude won't change.
This extreme behavior comes from just a few people, but I'm seeing a less extreme version of it in other people too. Unlike the former group, the latter group doesn't seem to be particularly paranoid or uncivil, but they seem to be getting increasingly critical of staff members as well.
Quite understandably, staff members aren't gonna be encouraged to be more collaborative when they get the feeling that their attempts to do so more often than not result in increased scrutiny, criticism or drama and that their sometimes unfortunate but nevertheless good-faith and well-intentioned actions or words backfire the way we've seen happen a few times recently. Rather than feeling this environment encourages them to collaborate (which it should), they'll feel this environment is hostile and will be driven away from it if it continues to feel hostile.
A crucial point that I think is being missed by a number of people right now is that collaboration is a two-way street. Staffers and volunteers are both responsible for making it work. While staff members have to be open to, respectful of and collaborative with volunteer developers, the reverse is also true: volunteers are supposed to make staff members feel welcome and appreciated, and treat them as their equals. Right now, the opposite seems to be happening, which I fear will lead to a negative spiral.
A few weeks ago, staff members were called upon to adjust their attitudes to do their part in fostering collaboration between staff and volunteers. Volunteers, in turn, should be aware that they have a part to play too. Also, both sides should realize behaviors don't change overnight, and should give each other time to adapt and cut each other some slack in the meantime.
Roan Kattouw (Catrope)
On Fri, Oct 15, 2010 at 2:40 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
Since the discussion about staff collaboration with volunteers started a few weeks ago, actions and statements by staff members have undergone an increasing amount of scrutiny and criticism. That in itself is not a bad thing necessarily: staff members need to be kept on their toes and not be allowed to get away with doing bad things, and some scrutiny and criticism is needed to accomplish this.
This is a symptom of the tension between staff and volunteers. Naturally, volunteers are more likely to express their frustration here, because they don't have to act professional and because they're the ones who feel wronged in this case. Some of those who aren't overtly expressing their frustration are just cutting back their contributions. It's a warning sign.
A crucial point that I think is being missed by a number of people right now is that collaboration is a two-way street. Staffers and volunteers are both responsible for making it work. While staff members have to be open to, respectful of and collaborative with volunteer developers, the reverse is also true: volunteers are supposed to make staff members feel welcome and appreciated, and treat them as their equals. Right now, the opposite seems to be happening, which I fear will lead to a negative spiral.
Entirely possible, if no action is taken to correct it. This is the sort of thing that tends to end in the volunteer community either dissolving or forking. Forking isn't practical in MediaWiki's case, because volunteer developers are almost all interested in MediaWiki due to Wikimedia projects, so the volunteer development community will probably just disappear over time if matters don't improve. I suspect that process is already well underway, although I only have anecdotal evidence.
A few weeks ago, staff members were called upon to adjust their attitudes to do their part in fostering collaboration between staff and volunteers. Volunteers, in turn, should be aware that they have a part to play too. Also, both sides should realize behaviors don't change overnight, and should give each other time to adapt and cut each other some slack in the meantime.
The problem is not about attitudes, it's systemic. The negative attitudes are a byproduct of various concrete problems, both social and technical. You could either tell the volunteers they shouldn't be frustrated and negative, and then watch them either ignore you or leave because the reasons for their frustration aren't addressed. Or you could actually take them seriously when they tell you *why* they're frustrated, and fix the cause of the frustration.
The only progress I've seen in this regard at all is that Wikimedia has finally deployed more review manpower. If volunteer commits actually get back to being deployed as often as employee commits, most of the reason for frustration will vanish, and so eventually the frustration will be reduced too. But it will take a long time for the neglect to be forgotten, and it will easily be remembered again if there's a lapse.
The bottom line is that you're not going to have a happy volunteer community unless you consistently pay attention when it complains. I think the response to the thread I started about this a while ago was a pretty clear-cut example of complaints that a huge proportion (~100%) of volunteers agreed with and many prominent volunteers felt were important, but which were simply brushed off by staff as unreasonable. When you do that, you will very predictably find that volunteers' attitude toward staff will sour.
But instead of seeing volunteers' frustration as something that needs to be addressed by staff if you expect to keep a healthy community going, you see it as a problem in its own right which is the fault of the volunteers. This perspective has, unfortunately, been typical of Wikimedia staff for some time now.
On 15 October 2010 20:17, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
The bottom line is that you're not going to have a happy volunteer community unless you consistently pay attention when it complains. I think the response to the thread I started about this a while ago was a pretty clear-cut example of complaints that a huge proportion (~100%) of volunteers agreed with and many prominent volunteers felt were important, but which were simply brushed off by staff as unreasonable. When you do that, you will very predictably find that volunteers' attitude toward staff will sour. But instead of seeing volunteers' frustration as something that needs to be addressed by staff if you expect to keep a healthy community going, you see it as a problem in its own right which is the fault of the volunteers. This perspective has, unfortunately, been typical of Wikimedia staff for some time now.
+1
- d.
2010/10/15 Aryeh Gregor Simetrical+wikilist@gmail.com:
The problem is not about attitudes, it's systemic.
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".
What is this?
I have never read something like this before ...(since 28-2-2002)
Maybe some people need to take a phone and talk with other people. There are some things that can't be conducted by emails.
On Fri, Oct 15, 2010 at 3:53 PM, Erik Moeller erik@wikimedia.org wrote:
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.
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.
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".
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.
2010/10/15 Aryeh Gregor Simetrical+wikilist@gmail.com:
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.
+1
I whole-heartedly agree with the analysis that deploy backlog is at the hear of this. I have some gut feelings I can't word very well right now that say the "solely because they're not WMF" isn't completely fair, but what you've stated multiple times in various guises is true: what matters is perception, fair or not. If volunteers *feel* ignored, that's bad. We can all go "oh but we're not really ignoring /just/ you, we're ignoring others too!", that's not very convincing.
We need to come up with a plan that takes us back to regular (weekly?) deployments. I think cleaning up the CR backlog is an uncontroversial first step. What I have in mind personally is to have this move to regular deployments coincide with the 1.17 release, but that should be discussed in a separate thread I guess.
Roan Kattouw (Catrope)
Roan Kattouw wrote:
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.
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:
We need to come up with a plan that takes us back to regular (weekly?) deployments. I think cleaning up the CR backlog is an uncontroversial first step. What I have in mind personally is to have this move to regular deployments coincide with the 1.17 release, but that should be discussed in a separate thread I guess.
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:
I think that we agree more than we disagree here. Obviously a huge code review and deployment backlog is bad for everyone.
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/2010 9:37 PM, MZMcBride wrote:
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.
+1
I really don't understand why this is so difficult, nor why progress is so slow. Code review and regular-ish updates are somethings that *were happening* just a year or 2 ago. As I pointed out one of the last times this was discussed[1], the number of commits has only decreased while the amount of tech staff has hugely increased, so I don't believe that "more commits to review" or "lack of resources" (not the same as "resources not allocated well") are to blame. That discussion was more than a month ago. What progress has been made since then?
Why does this need some elaborate plan that will take multiple months to implement? The infrastructure for actually doing code review is already there; it just needs someone to actually do it.
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2010-September/049255.html
On 10/15/10 8:25 PM, Alex wrote:
That discussion was more than a month ago. What progress has been made since then?
* 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.
2010/10/16 Alex mrzmanwiki@gmail.com:
Why does this need some elaborate plan that will take multiple months to implement? The infrastructure for actually doing code review is already there; it just needs someone to actually do it.
I didn't mean to suggest an elaborate plan needs to be concocted, nor that /implementing/ it would take months. Executing it most probably would, though. By way of example, my "plan" is give below. It's mostly obvious stuff, but I see how people might disagree on the order or timing of things, which is why I think there should be (some) discussion before settling down on something. I didn't really want to put this in this thread because I think that discussion deserves its own, but here it is anyway:
1. Catch up with the code review backlog (about 1,200 revs currently). I expect this to be entirely uncontroversial, and this can be (and is being) done while we argue about the rest 2. When trunk is fully reviewed and we feel it's probably stable, release 1.17.0beta1 and deploy it on Wikimedia 3. Fix the numerous bugs that will inevitably rear their ugly heads when 8 months' (or more) worth of code is deployed 4. Once deployment stabilizes, rebranch from trunk (picking up trunk changes since the last deployment that weren't specifically aimed at fixing the site), release and deploy that. 5. Repeat 2-4 until we feel comfortable releasing the currently deployed code as 1.17.0 6. From there on out, do weekly deployments of trunk
Exactly as MZMcBride feared, this is an "after X" plan, where X is the next release. I disagree that that necessarily implies procrastination, however. Sometimes there are valid reasons to do X first, then Y, and I think this is such a case.
Roan Kattouw (Catrope)
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@gmail.com wrote:
2010/10/16 Alex mrzmanwiki@gmail.com:
Why does this need some elaborate plan that will take multiple months to implement? The infrastructure for actually doing code review is already there; it just needs someone to actually do it.
I didn't mean to suggest an elaborate plan needs to be concocted, nor that /implementing/ it would take months. Executing it most probably would, though. By way of example, my "plan" is give below. It's mostly obvious stuff, but I see how people might disagree on the order or timing of things, which is why I think there should be (some) discussion before settling down on something. I didn't really want to put this in this thread because I think that discussion deserves its own, but here it is anyway:
- Catch up with the code review backlog (about 1,200 revs currently).
I expect this to be entirely uncontroversial, and this can be (and is being) done while we argue about the rest 2. When trunk is fully reviewed and we feel it's probably stable, release 1.17.0beta1 and deploy it on Wikimedia 3. Fix the numerous bugs that will inevitably rear their ugly heads when 8 months' (or more) worth of code is deployed 4. Once deployment stabilizes, rebranch from trunk (picking up trunk changes since the last deployment that weren't specifically aimed at fixing the site), release and deploy that. 5. Repeat 2-4 until we feel comfortable releasing the currently deployed code as 1.17.0 6. From there on out, do weekly deployments of trunk
Exactly as MZMcBride feared, this is an "after X" plan, where X is the next release. I disagree that that necessarily implies procrastination, however. Sometimes there are valid reasons to do X first, then Y, and I think this is such a case.
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Oct 16, 2010 at 8:20 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
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.
Contractors are not listed there. A lot of "staff" fall into this category. There are various reasons why they aren't listed there.
While there is no "official" contractor list, there is a community-run effort to keep track of this group on Meta[0].
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,
I agree wholeheartedly.
-Chad
[0] http://meta.wikimedia.org/wiki/Wikimedia_Foundation_contractors
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@gmail.com wrote:
On Sat, Oct 16, 2010 at 8:20 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, I just had a look at the staff page at http://wikimediafoundation.organd 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.
Contractors are not listed there. A lot of "staff" fall into this category. There are various reasons why they aren't listed there.
While there is no "official" contractor list, there is a community-run effort to keep track of this group on Meta[0].
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,
I agree wholeheartedly.
-Chad
[0] http://meta.wikimedia.org/wiki/Wikimedia_Foundation_contractors
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Oct 16, 2010 at 1:51 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
The current "some animals are more equal then others" approach sucks.
Yes it sucks, but according to US employment law, some animals are indeed more equal than others.
-Chad
Roan Kattouw wrote:
2010/10/16 Alex mrzmanwiki@gmail.com:
Why does this need some elaborate plan that will take multiple months to implement? The infrastructure for actually doing code review is already there; it just needs someone to actually do it.
I didn't mean to suggest an elaborate plan needs to be concocted, nor that /implementing/ it would take months. Executing it most probably would, though. By way of example, my "plan" is give below. It's mostly obvious stuff, but I see how people might disagree on the order or timing of things, which is why I think there should be (some) discussion before settling down on something. I didn't really want to put this in this thread because I think that discussion deserves its own, but here it is anyway:
- Catch up with the code review backlog (about 1,200 revs currently).
I expect this to be entirely uncontroversial, and this can be (and is being) done while we argue about the rest 2. When trunk is fully reviewed and we feel it's probably stable, release 1.17.0beta1 and deploy it on Wikimedia 3. Fix the numerous bugs that will inevitably rear their ugly heads when 8 months' (or more) worth of code is deployed 4. Once deployment stabilizes, rebranch from trunk (picking up trunk changes since the last deployment that weren't specifically aimed at fixing the site), release and deploy that. 5. Repeat 2-4 until we feel comfortable releasing the currently deployed code as 1.17.0 6. From there on out, do weekly deployments of trunk
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. :-)
2010/10/15 Aryeh Gregor Simetrical+wikilist@gmail.com:
I respectfully disagree. Attitude is not important compared to concrete things that are upsetting people.
I think that we agree more than we disagree here. Obviously a huge code review and deployment backlog is bad for everyone. Volunteers should feel that their contributions are wanted, supported, and appreciated (so should staff). And we are, in good faith, working together to make sure this happens. We all want to build a healthy community, and reminding us that we all can contribute to that, I think, what Roan was mainly trying to do in this thread. :-)
On Fri, Oct 15, 2010 at 5:58 PM, Erik Moeller erik@wikimedia.org wrote:
I think that we agree more than we disagree here. Obviously a huge code review and deployment backlog is bad for everyone. Volunteers should feel that their contributions are wanted, supported, and appreciated (so should staff). And we are, in good faith, working together to make sure this happens. We all want to build a healthy community, and reminding us that we all can contribute to that, I think, what Roan was mainly trying to do in this thread. :-)
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@wikimedia.org wrote:
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.
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@mzmcbride.com wrote:
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.
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.
Aryeh Gregor wrote:
On Sat, Oct 16, 2010 at 4:34 PM, MZMcBride z@mzmcbride.com wrote:
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.
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.
I don't see any evidence to support what you're saying. For the past half-decade or so, there have only been two people doing general code updates: Tim and Brion. Both are now out of commission, from what I understand. We've both noted that others have the technical ability to do general code updates, but I don't believe that anyone else has (or has the social ability to do so).
To put it another way, if the code backlog were eliminated today, I think the exact same frustrations and annoyances would exist among the developer community because the code would sit reviewed, but un-deployed. When we say "the biggest issue is a huge code review backlog," it's misleading. The reality is that the biggest issue is a huge code review _and deployment_ backlog.
I'm not going to knock anyone for focusing on half the problem (review), but that doesn't make the other half (deployment) resolve itself.
Broadly, I don't see any reason why it's beneficial to engage in Great Reveal-style code updates to the site. There are thousands of uncontroversial revisions already reviewed that could be deployed today. Waiting for more revisions to build up makes diagnosing and finding problems more difficult (same size needle, larger haystack). You know this and I know this, which is why I'm trying to pivot the conversation toward what I view as the bigger question: who's going to be doing general code updates in the future? And subsequent to that, is there any reason to hold off on deploying incrementally?
MZMcBride
2010/10/18 MZMcBride z@mzmcbride.com:
Waiting for more revisions to build up makes diagnosing and finding problems more difficult (same size needle, larger haystack).
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.
You know this and I know this, which is why I'm trying to pivot the conversation toward what I view as the bigger question: who's going to be doing general code updates in the future?
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)
On Sun, Oct 17, 2010 at 6:58 PM, MZMcBride z@mzmcbride.com wrote:
I don't see any evidence to support what you're saying. For the past half-decade or so, there have only been two people doing general code updates: Tim and Brion. Both are now out of commission, from what I understand. We've both noted that others have the technical ability to do general code updates, but I don't believe that anyone else has (or has the social ability to do so).
There is no reason to believe that Tim and Brion couldn't both be around to help oversee the big general code update that will be needed when the current review is done. It's a one-time deal, after all. After that, there are plenty of people who could handle regular incremental code updates, like Roan.
To put it another way, if the code backlog were eliminated today, I think the exact same frustrations and annoyances would exist among the developer community because the code would sit reviewed, but un-deployed. When we say "the biggest issue is a huge code review backlog," it's misleading. The reality is that the biggest issue is a huge code review _and deployment_ backlog.
I don't see any reason why deployment would lag far behind review. Review takes a lot of time, deployment is quick. We'd just need a lot of people on hand to do damage control when stuff breaks unexpectedly after such a huge deployment.
Broadly, I don't see any reason why it's beneficial to engage in Great Reveal-style code updates to the site. There are thousands of uncontroversial revisions already reviewed that could be deployed today.
I don't think it would be wise at all to try deploying something less than trunk. Deploying trunk means we can commit any fixes to trunk and only trunk. Branching some earlier point and deploying that would mean we have to maintain the branch. Plus, we'd have to have several large deployments instead of one giant one. Better to have one giant deployment so that there's at most one point of massive user inconvenience, and then stick to only small ones from then on.
who's going to be doing general code updates in the future?
There are plenty of candidates, including Tim, Roan, and Trevor. It's kind of trivial to do the actual deployment, you just need to make sure people are around to fix any breakage.
And subsequent to that, is there any reason to hold off on deploying incrementally?
IMO, no.
Aryeh Gregor wrote:
On Sun, Oct 17, 2010 at 6:58 PM, MZMcBride z@mzmcbride.com wrote:
To put it another way, if the code backlog were eliminated today, I think the exact same frustrations and annoyances would exist among the developer community because the code would sit reviewed, but un-deployed. When we say "the biggest issue is a huge code review backlog," it's misleading. The reality is that the biggest issue is a huge code review _and deployment_ backlog.
I don't see any reason why deployment would lag far behind review. Review takes a lot of time, deployment is quick. We'd just need a lot of people on hand to do damage control when stuff breaks unexpectedly after such a huge deployment.
You don't see any reason? Simply, because it does. How did we get into the current situation?
Broadly, I don't see any reason why it's beneficial to engage in Great Reveal-style code updates to the site. There are thousands of uncontroversial revisions already reviewed that could be deployed today.
I don't think it would be wise at all to try deploying something less than trunk. Deploying trunk means we can commit any fixes to trunk and only trunk. Branching some earlier point and deploying that would mean we have to maintain the branch. Plus, we'd have to have several large deployments instead of one giant one. Better to have one giant deployment so that there's at most one point of massive user inconvenience, and then stick to only small ones from then on.
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 Erik Moeller erik@wikimedia.org:
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.
Thank you, Erik, for writing the final paragraph of my original post for me. I wanted to close with a very similar paragraph, but couldn't get the words out right.
Roan Kattouw (Catrope)
2010/10/15 Aryeh Gregor Simetrical+wikilist@gmail.com:
But instead of seeing volunteers' frustration as something that needs to be addressed by staff if you expect to keep a healthy community going, you see it as a problem in its own right which is the fault of the volunteers. This perspective has, unfortunately, been typical of Wikimedia staff for some time now.
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 Fri, Oct 15, 2010 at 5:07 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
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.
Okay, I think we mean different things by "staff" here. I generally mean *all* of staff, while you seem to be thinking of staff developers in particular. Just to be clear, I don't think there's much that either staff developers *or* volunteer developers can do here. Since the problems are systemic, they can only be fixed by the people who have the ability to fix them. That means staff as opposed to volunteers, but particularly the ones in charge of staff, like I guess Danese or Erik. They're the only ones who can make decisions like "we have to devote more resources toward code review", and those decisions are the only things that can fix the underlying problems.
I don't blame anything on staff *developers*, and I don't think I ever criticized them in particular. My suggestions have all been about ways to change the system so that it lends itself to a more unified development community. To the extent that staff developers are collectively not acting as I'd like, it's because of the environment they're working in, not because of individual personal decisions.
In that sense, then, I do think the volunteer developers have little role to play here, just like the staff developers -- except for making their feelings known. It's not a two-way street. It would be most accurate to say that the decision lies in the hands of just a few people.
But, to reiterate, I think most of the problem will disappear when we have regular code deployment again. At this point, it's best to focus solely on that and forget about all other complaints. If problems linger for long after everyone's code is getting deployed on a regular basis, we can talk about that then, and I think everyone will be talking on much more amicable basis.
On 10/15/10 2:44 PM, Aryeh Gregor wrote:
It's not a two-way street. It would be most accurate to say that the decision lies in the hands of just a few people.
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
On 10/15/10 3:07 PM, Trevor Parscal wrote:
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.
+1
2010/10/15 Aryeh Gregor Simetrical+wikilist@gmail.com:
But, to reiterate, I think most of the problem will disappear when we have regular code deployment again. At this point, it's best to focus solely on that and forget about all other complaints. If problems linger for long after everyone's code is getting deployed on a regular basis, we can talk about that then, and I think everyone will be talking on much more amicable basis.
+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@gmail.com wrote:
...
+4,294,967,295
see what you did to poor Roan, in this "always be positive" environment this is the only way he can write -1.
Somebody's been confusing their signed and unsigned ints…
Roan Kattouw wrote:
[The volunteers'] 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.
Please pardon an outside comment which may be misinformed, or too blunt; I haven't been part of this discussion or followed all of it, and I'm not well-informed on the tensions which motivated it. But:
It seems to me that if we're talking about backpats, it's the volunteers who are more likely to need them, not the paid staff. Since you hire the paid staff, you can presumably pick people who are professional enough to understand their job requirements and remuneration structure, and the special issues involved in working with volunteers. One of those issues is that the volunteers are sometimes going to be cantankerous, or even downright vituperative, and if in spite of this you think it's primarily the volunteers whose job it is to "keep the environment positive", you're likely to be disappointed.
You don't hire the volunteers, of course, and you're somewhat stuck with the ones you get. If one of them gets his nose bent out of joint over some perceived slight, then you might have to give him a pat on the back (even if you think he doesn't deserve it), because you can't get rid of him if you think he's being oversensitive, and you certainly can't tell him to quit his blubbering and be happy with the paycheck he's getting.
The volunteer's primary job is to donate real work for free, and if he imagines that one of the perks of the role is the right to get kvetchy from time to time (perhaps due to a twinge of jealousy that the staff are getting paid and he's not), then that's okay, and it's the staff's job to humor him, with a pat on the back if necessary. Unfair and asymmetrical it may be, but the staff does *not* get to get kvetchy in turn about a negative or unwelcoming atmosphere.
[Disclaimer: I am not at all trying to suggest that Wikimedia's volunteers *are* a bunch of praise-craving blubberers. But if anyone's going to act that way, it should be the volunteers, not the staff.]
On 10/15/10 3:19 PM, Steve Summit wrote:
Please pardon an outside comment which may be misinformed, or too blunt; I haven't been part of this discussion or followed all of it, and I'm not well-informed on the tensions which motivated it. But:
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2010/10/15 Steve Summit scs@eskimo.com:
It seems to me that if we're talking about backpats, it's the volunteers who are more likely to need them, not the paid staff. Since you hire the paid staff, you can presumably pick people who are professional enough to understand their job requirements and remuneration structure, and the special issues involved in working with volunteers.
Just please keep in mind that the folks who work for WMF are, without exception, there because of the mission, or they won't be there for long, and many folks were formerly part of the volunteer community, and will be again in future. Staff and contractor positions at WMF are paid well below market, and yet people put in many, many more hours than can be asked from them. So, for example, you might legitimately feel that a project like the original UsabilityInitiative didn't incorporate volunteer contributions well, but that doesn't mean the folks who worked on it didn't give it their all, not because they were (under)paid, but because they passionately want to support our mission.
This is why folks get so frustrated when good faith partnership breaks into us/them or finger-pointing. When folks are treated -- by action or by implication -- like corporate drones because they draw a paycheck, they get just as frustrated and demotivated as any volunteer, and will eventually quit, just like any volunteer. So I don't agree that things are quite as asymmetrical as they may seem at times. This is a mission-driven group of people. That's why we're having this conversation. :)
And with that, I'll follow Roan's lead and let the coders go back to work.
wikitech-l@lists.wikimedia.org