The basic attitude has to be that paid developers are treated identically to volunteers, except that you can tell the former what to do and expect them to put in more time.  There should not be communication between paid developers and the community, paid developers should be an integral *part* of the community rather than a separate group of people.

I do believe that it's very true and very universal (so could and should be treated this way far beyond platform development).

I mean that "communication between us and them" is error-prone concept in it very bottom.

The should be only community as "us".

Seemingly/IMHO Erik Zachte' 'story' is right example: he started his statics endeavor as volunteer and as soon as WMF started to 'expect him to put in more time' he became paid person.

Pavlo

On Wed, Jun 9, 2010 at 1:55 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:

On Tue, Jun 8, 2010 at 6:31 PM, Erik Moeller erik@wikimedia.org wrote:

...

With all this in mind, here are just a few concrete ideas for closing the gap:

1. Embedding teams funded by WMF into larger, publicly visible

workgroups which include volunteers and which meet regularly e.g. via IRC; 1 a) Outreach to grow and strengthen those workgroups with the best skills present in the Wikimedia volunteer community; 2) Publication of mini-projects which we identify and which can be tackled by self-organized volunteers, with mentoring by experienced WMF staff and volunteers (happening a bit via GSoC, but not as much outside of it yet); 3) Making development roadmaps fully transparent and open to discussion, and sharing justifications for all key priorities; 4) Further iteration of tools and processes for rapid volunteer-driven bug reporting, cross-browser testing, and submission of simple patches; 5) Stimulating larger scale contests focusing on specific areas of interest; 6) More topic-focused meetings and sprints like the multimedia usability meeting in Paris. 7) Further experimentation with tools like IdeaTorrent for large-scale brainstorming and ranking purposes (we have a prototype running at http://prototype.wikimedia.org/en-idea/ideatorrent/ ).

None of these strike me as essential for a successful bazaar-style development model, except (4).  I'd say some of the most important things are (from a development point of view, not talking about non-developer communities)

1. Rely on public mailing lists for communication as much as possible,

supplemented by IRC channels (preferably publicly logged).  Private e-mail, face-to-face meetings, and telephone meetings are impossible for volunteers to join in on, so they should be used as little as possible.  Don't try to move everyone to San Francisco -- if you do that, they'll inevitably rely heavily on face-to-face communication and lock out volunteers.  I get the impression this has happened with the usability team.

2. Make sure that every paid developer spends time dealing with the

community.  This can include giving support to end users, discussing things with volunteers, reviewing patches, etc.  They should be doing this on paid time, and they should be discussing their personal opinions without consulting with anyone else (i.e., not summarizing official positions).  Paid developers and volunteers have to get to know each other and have to be able to discuss MediaWiki together.

3. Don't needlessly fork discussion fora.  The Usability Initiative

made its own public wiki, IRC chat, etc., and those are used overwhelmingly by paid people.  This might not have happened if they stuck to existing, established fora like wikitech-l, #mediawiki, and mediawiki.org, where there are already a lot of community members reading.

The basic attitude has to be that paid developers are treated identically to volunteers, except that you can tell the former what to do and expect them to put in more time.  There should not be communication between paid developers and the community, paid developers should be an integral *part* of the community rather than a separate group of people.

---

foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On Tue, Jun 8, 2010 at 8:48 PM, Benjamin Lees emufarmers@gmail.com wrote:

I really agree with this sentiment, but it seems difficult to get staff to really be part of the community unless they're _from_ the community.  The developers I've seen discuss their personal opinions on public fora (especially in ways that are accepted in an open community but not in a business environment—one example would be criticizing their co-workers) have been those who were recruited from the community.  There's nothing wrong with having outsiders as employees, but communication is rather different in the outside world, and I get the sense that a lot of the people hired from elsewhere aren't necessarily familiar with the Wikimedia Way™ of discussing things—and even if they understand that it's there, I'm not sure they always understand that they're supposed to join in.

It's not specific to Wikimedia, it's practically universal in open-source development. To get it to happen, you need pushing from the top: formally stating it as part of people's job duties (so they don't feel they have to do "real work" instead), and forcing them to engage by only giving them public media to discuss things in with their co-workers. I recall reading that IBM improved its participation in the Linux kernel community by getting rid of all internal communications among its kernel developers, meaning they had to use the public project lists to bounce ideas off anyone.

It's also worth pointing out that a good way *not* to engage with the community is to not touch preexisting code that volunteers are familiar with. All the Usability Initiative stuff was created separately: a new skin, and all other functionality in extensions. There's mostly no technical reason for this; at least some could have been integrated with the existing code. Putting most of your code in a directory called "UsabilityInitiative" is a good way of signaling "this is ours, not yours", whether that was the intent or not. If it had touched code that volunteers were familiar with, they would have been more engaged from the start, because they'd have stronger opinions on the changes and no presumption that they shouldn't touch it.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 09/06/2010 03:28, Aryeh Gregor wrote:

I recall reading that IBM improved its participation in the Linux kernel community by getting rid of all internal communications among its kernel developers, meaning they had to use the public project lists to bounce ideas off anyone.

I think this idea is key.

IBMs decision to get rid of all internal communication sounds to me as a very good practice for us. It also fits in well with the wikipedia culture of consensus in decision making.

Following this comm. strategy involves the large volunteer community, and taps on the vast knowledge of our community.

thank you, Aryeh, for bringing this up. teun

It's not specific to Wikimedia, it's practically universal in open-source development. To get it to happen, you need pushing from the top: formally stating it as part of people's job duties (so they don't feel they have to do "real work" instead), and forcing them to engage by only giving them public media to discuss things in with their co-workers. I recall reading that IBM improved its participation in the Linux kernel community by getting rid of all internal communications among its kernel developers, meaning they had to use the public project lists to bounce ideas off anyone.

It's also worth pointing out that a good way *not* to engage with the community is to not touch preexisting code that volunteers are familiar with. All the Usability Initiative stuff was created separately: a new skin, and all other functionality in extensions. There's mostly no technical reason for this; at least some could have been integrated with the existing code. Putting most of your code in a directory called "UsabilityInitiative" is a good way of signaling "this is ours, not yours", whether that was the intent or not. If it had touched code that volunteers were familiar with, they would have been more engaged from the start, because they'd have stronger opinions on the changes and no presumption that they shouldn't touch it.

---

foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Rob Lanphier wrote:

So, I'll start chipping in my work at the page Erik has started: http://usability.wikimedia.org/wiki/Product_Development_Process_Ideas

You all really just don't get it, do you? Part of the problem is that the usability wiki is viewed as a walled garden. Your "solution" is to create a page there for others to add comments?

Meta-Wiki is the Wikimedia community's wiki. Go there and create a dialogue.

MZMcBride

--- On Wed, 6/9/10, Rob Lanphier robla@wikimedia.org wrote:

One undertone that I've witnessed everywhere is that people in open source communities that have a clear organizational "owner" is that there is a very uneven distribution of people who want a peer-to-peer relationship versus a customer-vendor relationship.  This makes it really difficult to work out in the public, because some people seem to prefer the trappings of a peer-to-peer relationship (let me in on your early thinking, publish your roadmaps, work in the fishbowl), where others prefer the trappings of the customer-vendor relationship (the customer is always right, the customer is the boss).  Some will even go so far as to want a customer-to-peer relationship, which is clearly not sustainable.  To be really clear here, most of my impressions on this topic come from my previous work experience (been doing the corporate open source thing for a while), and only in a limited way with this community, but I've seen hints that the WMF<=>community relationship has some of the same traits.

From the vantage point of the "vendor" in this case, the problem is compounded by the cognitive bias Erik pointed to (belief that the group you're a member of is diverse, whereas other groups are not).  The net result of different expectations in the community is that, from the vendor point of viewer, it looks like the community is demanding a customer-to-peer relationship, since that is the "average" opinion of a pretty large and diverse group.  That's why I'm generally pretty careful about using the term "the community", because for those not used to working out in the open, it's really scary to get mixed up in public conversations.

One thing to consider about the IBM example is that IBM is a company of about 400,000 employees, and was probably in the middle of their "we're spending $1 billion/year on Linux" year when they instituted that policy. They could probably stand to be a little inefficient in the name of insinuating themselves in the community.  We're not working with that sort of cushion.

As someone who currently works from Seattle (and worked on a distributed team in my last job), I also know that long distance collaboration (even in the same timezone as SF) has its disadvantages from an efficiency perspective.  Most people have a strong preference for face-to-face communication for collaboration for good reason...it's high bandwidth.  Even people who are really good at doing it take some time to figure out how to be effective using only email and IRC; forcing people who aren't good at it is really a productivity hit.

My recommendation is to strive to make it incredibly compelling for WMF staff to work out in the community.  That means adhering to WP:BITE and WP:GOODFAITH in spades, and reminding each other that we're all on the same team here.  It means making sure that it actually feels like it's increasing our productivity to do it, rather than feeling like a drag.  That's not to say the burden needs to be solely on you all, but I think "forcing" employees to work in the community is some customer-vendor thinking at play.

Don't get me wrong: I think it's an incredibly good idea for us to figure out how to all work together better, and clearly a big part of that is going to be strengthening our working relationship with non-employees.  It wasn't that long ago I was a non-employee Wikipedian, and may be one again soon.  I share your goal.  We have an amazingly diverse community with (very importantly) a fantastic volunteer work ethic, and I think we should be able to figure this out.

I think you are conflating two very seperate issues here. There is a peer-to-peer relationship between developers (staff and volunteer) and a customer-vendor relationship between the larger non-technical consensus that is formed and developers (both staff and volunteer). Although I don't think I would describe it as "the customer is always right"; technical vetos by developers are common. The suggestion here is to eliminate the barriers between two groups of developers. There will always be some kind of barrier between the largely non-technical community and developers. There are a alot of rough edges to that customer-vendor relationship, but the volunteer developers have had alot of experience with the pitfalls there and can help staff developers navigate them.

Birgitte SB

On Wed, Jun 9, 2010 at 8:46 PM, Rob Lanphier robla@wikimedia.org wrote:

As you know, any time you want to compel someone to do something, there's always the carrot and the stick.  One thing I don't like about the way you've phrased that is that is that you seem to be advocating the stick.  Am I reading that right?

I'm not clear what you're asking in practice. I don't think Wikimedia should be penalizing people for not making enough wikitech-l posts per week or anything, no. I do think it's reasonable for it to make organizational decisions, like what sort of communication fora are used for developing its software. I also think it's reasonable for it to ask its paid employees to try to treat volunteers similarly to paid people: ask that they try to respond when intelligent questions are raised, maybe review patches, that kind of thing. Some people don't do well in community-oriented jobs, and that's fine; there are an enormous number of non-community-based development jobs available at other organizations.

One undertone that I've witnessed everywhere is that people in open source communities that have a clear organizational "owner" is that there is a very uneven distribution of people who want a peer-to-peer relationship versus a customer-vendor relationship.  This makes it really difficult to work out in the public, because some people seem to prefer the trappings of a peer-to-peer relationship (let me in on your early thinking, publish your roadmaps, work in the fishbowl), where others prefer the trappings of the customer-vendor relationship (the customer is always right, the customer is the boss).

Are you talking about people paid by the organization, or volunteers, or users? As far as I've seen, the users and volunteers here overwhelmingly prefer a more peer-to-peer approach. If someone applies for a job at the Wikimedia Foundation, on the other hand, they should expect to be dealing with the community on a day-to-day basis, and shouldn't apply if they don't want to do that. Every development job I can find at http://wikimediafoundation.org/wiki/Special:PrefixIndex/Job_openings has "You must be comfortable in a highly collaborative, consensus-oriented environment" as a requirement.

One thing to consider about the IBM example is that IBM is a company of about 400,000 employees, and was probably in the middle of their "we're spending $1 billion/year on Linux" year when they instituted that policy.  They could probably stand to be a little inefficient in the name of insinuating themselves in the community.  We're not working with that sort of cushion.

Is vendor-to-customer development more efficient than peer-to-peer in the end? A lot of open-source projects (e.g., Firefox) have as many features as their closed-source counterparts, on a much smaller budget. And of course, Wikipedia managed to become awfully large on a tiny budget, based almost exclusively on community (i.e., non-Wikimedia) contributions. Paid developers get less work done, but you encourage an effective development community. Volunteers don't only do development themselves, they also provide a pool of people to recruit who won't need to spend time getting up to speed when hired.

As someone who currently works from Seattle (and worked on a distributed team in my last job), I also know that long distance collaboration (even in the same timezone as SF) has its disadvantages from an efficiency perspective.  Most people have a strong preference for face-to-face communication for collaboration for good reason...it's high bandwidth.  Even people who are really good at doing it take some time to figure out how to be effective using only email and IRC; forcing people who aren't good at it is really a productivity hit.

On the other hand, by involving volunteers as much as possible, you get a great deal of free labor. Empirically, this seems like a very effective approach for organizations that don't have much money, like Wikimedia or Mozilla. Open-source software is turned out on far lower budgets than typical commercial software.

My recommendation is to strive to make it incredibly compelling for WMF staff to work out in the community.  That means adhering to WP:BITE and WP:GOODFAITH in spades, and reminding each other that we're all on the same team here.

This is exactly what's *un*important. Many of the most community-oriented projects are notoriously vitriolic, while cathedral-style developers virtually always treat even completely braindead users as though they were made of glass. Being nice is a good thing (to a point), but it's not at all essential.

The essential thing is to give developers the ability and the will to contribute. For them to have the ability to contribute, development must all be public and easily followed, even if that results in superficial efficiency hits. How can anyone contribute usefully to the Usability Initiative (say) if they have no idea what the rationale was behind any of the design decisions, because the decision-making was done face-to-face or by phone? That's more efficient for the employees, but sure as heck less efficient for the volunteers.

For volunteer developers to have the will to contribute, they need to be rewarded, and one of the surest rewards is respect. Respect means that they're treated according to their history of contribution. It means that they can object to something and be listened to even if their objection contradicts what some paid people agreed to in a closed room. It means that an established volunteer contributor has more say in practice than a new hiree. It means they make decisions, they don't just give feedback.

That's not to say the burden needs to be solely on you all, but I think "forcing" employees to work in the community is some customer-vendor thinking at play.

I don't understand what you mean by this at all. Neither an employee or an employer plays the role of a customer in any sense here.

On Thu, Jun 10, 2010 at 12:37 AM, Rob Lanphier robla@robla.net wrote:

Um, ok: http://meta.wikimedia.org/wiki/Product_Development_Process_Ideas

Wiki pages can be used for collecting ideas, but I don't think that's important right now. We have ideas, we just need to discuss them to figure out which ones are best. Mailing lists are a good way to do that -- wikis are bad for discussion.

On Wed, Jun 9, 2010 at 12:55 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:

2. Make sure that every paid developer spends time dealing with the

community.  This can include giving support to end users, discussing things with volunteers, reviewing patches, etc.  They should be doing this on paid time, and they should be discussing their personal opinions without consulting with anyone else (i.e., not summarizing official positions).  Paid developers and volunteers have to get to know each other and have to be able to discuss MediaWiki together.

I like the "discussing their personal opinions without consulting with anyone else" bit, and you bring up a very good point.

I don't think (and I don't mean to imply that anyone else does) that anyone's conspiring to keep the community out, or saying "leave this to the professionals, we know better." When you're hired onto a team, though, you're wary of saying anything that would cause strife or confusion. This isn't necessarily out of fear of retribution from your employer—it's simply conventional professional ethics, and it's usually not even a conscious thing. (It's also not limited to paid staff—the people we put on the Board specifically for their vocal opinions on things often fall into this, for understandable reasons.)

This "united front," however, results in the "us vs. them" mentality that we're all now lamenting. Volunteers are now "giving feedback" rather than "making decisions," as Greg put very well, and we wind up with questionable UI decisions becoming surrogate arguments for the roles of community and staff.

I don't think that there's a magic fix for this—it's simply a matter of culture, and making sure everyone involved understands it and can work effectively in it. We can point to the little things, but the systemic problem needs to be addressed.

Austin

On Fri, Jun 11, 2010 at 4:49 PM, Michael Snow wikipedia@verizon.net wrote:

... if for example I was qualified to review a staff member's patch (which I'm not), I might want to think twice about what audience gets that feedback.

Ugh.

You are implicitly expecting that the patch submitter and the code reviewer are staff members, and that the patch submitted is not very good! ;-)

Most open source developers have been lambasted in a public code review; they either pick up their game and look back at their previous code and cringe, or they go work for a company that has ten layers of bureaucracy to protect their feelings and prevent their crappy code from making it into the wild.

The content community is constantly putting up their work for public review, and working collaboratively with the reviewers.

The simple solution is: Don't employ bad coders! ;-)

Or said another way, require that applicants have existing open source/content contributions under their belt (preferably on mediawiki/wikimedia), so that you can inspect the caliber of their work before employing them.

With Mozilla, patches are uploaded onto bugzilla for review by *the community*. Code review comments go on the *public* bug page. etc. Staff members talk privately among themselves, but then so do community members. No special process for staff vs community; the only difference should be that the priorities of the staff are strategically set by the organisation.

-- John Vandenberg

Chad wrote:

On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow wikipedia@verizon.net wrote:

...

...if for example I was qualified to review a staff member's patch (which I'm not), I might want to think twice about what audience gets that feedback.

--Michael Snow

Why? If they're contributing a patch to MediaWiki, they should go through the same public patch/feedback -> commit/feedback cycle as everyone else. The only acceptable time to develop in private is when we're looking at active security vulnerabilities, and even then once a patch has been written the code is committed and the issue becomes public knowledge.

Can we be a bit harsh sometimes? Sure. But we're equal opportunity offenders here. Anyone who submits code--staff or volunteer--is subject to the same treatment on Bugzilla and Code Review. If your patch sucks, we're going to tell you about it, and there's absolutely no reason to sugarcoat it.

If someone can't take public criticism, then quite frankly they probably shouldn't be working on open source software.

The replies to my comment are missing the point. Sure, the developers themselves need to be able to handle public criticism of their work, just like wiki editors. But I was responding to Austin's comment in particular about board members being cautious with their opinions. In cases like that, there are additional concerns, like the propriety in publicly critiquing someone's work when you also can presumably influence their continued employment. That requires that certain feedback go through other channels, even when the same feedback could be given openly if it were coming from the general public.

--Michael Snow

Aryeh Gregor wrote:

On Fri, Jun 11, 2010 at 11:22 AM, Michael Snow wikipedia@verizon.net wrote:

...

The replies to my comment are missing the point. Sure, the developers themselves need to be able to handle public criticism of their work, just like wiki editors. But I was responding to Austin's comment in particular about board members being cautious with their opinions. In cases like that, there are additional concerns, like the propriety in publicly critiquing someone's work when you also can presumably influence their continued employment. That requires that certain feedback go through other channels, even when the same feedback could be given openly if it were coming from the general public.

Oh, okay. I was about to respond to you too, but I did miss the point. :) What you seem to be saying is that code review should be public, but people like board members shouldn't review code because criticism might make people worry that they'll be fired or something. I think you're overestimating the morale impact of negative code review -- in serious review-then-commit systems like Mozilla uses, virtually no code gets accepted in its original form without modifications, even when written by experienced developers.

Well, board members shouldn't review code because they're mostly not qualified to do so. The comment as it relates to morale is a more general point, it's not limited to the specific context of MediaWiki development. So it's less about how the process side of code review should work, and more about the organizational challenges for the foundation in interacting with community or public process. I think that's also related to what Rob was trying to say in different terms.

--Michael Snow

Chad, I'm hesitant to reply to your note, because I feel like "defending the staff against the community" is a bad role for me: it tends to polarize and divide, rather than helping us all work together well. And I think I do, for the most part, agree with you.

(As someone pointed out here the other day, Wikimedia recruits with that in mind: all our job postings specifically call out that people need to be comfortable in an open, collaborative environment, and we aim to only recruit people who can thrive in that context. We've learned the hard way to really probe on that in hiring interviews -- to pose open-ended scenario questions, and to use real-world examples. Practically everyone believes they are inclined to be collaborative, but that doesn't mean their definition is the same as ours. And we've found, unsurprisingly, that people who are already members of the Wikimedia community are pretty much the only people guaranteed to be risk-free in that regard: to a certain extent, hiring outside the community always carries a certain amount of risk. Which is fine and unavoidable: we do what we can to pick people we believe can succeed.)

But I do want to make one small point that I think is sometimes missed. And that is, the staff can't take wikibreaks. Volunteers are always free to take a break if they get irritated or discouraged or stressed: their contribution is voluntary, and they can walk away any time. The staff can't. They need to come in every day and work hard, even on those (fortunately fairly rare) days when they are getting yelled at on mailing lists, when it might be harder than usual to feel motivated.

We try really hard to hire people who are personally resilient, and I think we've succeeded at that reasonably well. Personally though, I think harshness and offence are mostly avoidable, and I think we should avoid them whenever we reasonably can. (Of course, I am female, and women are socialized to value harmony more than men. It doesn't stick for us all, but it did stick a fair bit, for me.) Personally, I think it's mostly possible to be frank without being rude, and I think it's worth trying to do that. I'm not arguing that people should handle the staff with kid gloves: I would actually argue, and have argued, that an uptick in kindness would be good for everyone. I realize that not everyone needs that, and it's obvious that not everyone will get it, whether they need it or not. But I think it's a worthy goal :-)

Thanks, Sue

-----Original Message----- From: Chad innocentkiller@gmail.com Date: Fri, 11 Jun 2010 07:13:37 To: Wikimedia Foundation Mailing Listfoundation-l@lists.wikimedia.org Subject: Re: [Foundation-l] Community, collaboration, and cognitive biases

On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow wikipedia@verizon.net wrote:

...if for example I was qualified to review a staff member's patch (which I'm not), I might want to think twice about what audience gets that feedback.

--Michael Snow

Why? If they're contributing a patch to MediaWiki, they should go through the same public patch/feedback -> commit/feedback cycle as everyone else. The only acceptable time to develop in private is when we're looking at active security vulnerabilities, and even then once a patch has been written the code is committed and the issue becomes public knowledge.

Can we be a bit harsh sometimes? Sure. But we're equal opportunity offenders here. Anyone who submits code--staff or volunteer--is subject to the same treatment on Bugzilla and Code Review. If your patch sucks, we're going to tell you about it, and there's absolutely no reason to sugarcoat it.

If someone can't take public criticism, then quite frankly they probably shouldn't be working on open source software.

-Chad

_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Hoi, The water is nice, I have tried it .. http://prototype.wikimedia.org/en-idea/ideatorrent/ I even blogged about it ... http://ultimategerardm.blogspot.com/2010/06/ideatorrent-for-mediawiki-ideas.... Thanks, GerardM

On 9 June 2010 01:28, phoebe ayers phoebe.wiki@gmail.com wrote:

On Tue, Jun 8, 2010 at 3:31 PM, Erik Moeller erik@wikimedia.org wrote:

<a long, thoughtful, and really important post>

...

7. Further experimentation with tools like IdeaTorrent for large-scale

brainstorming and ranking purposes (we have a prototype running at http://prototype.wikimedia.org/en-idea/ideatorrent/ ).

I was super excited to see this go up the other day. Can we move it to, say, strategywiki to try out? Any thoughts on scope? Not having used this much I don't know if you'd want separate torrents by broad topic (ideas for the wikimedia foundation, ideas for mediawiki, ideas for the projects, ideas for outreach) or one big one that could be sorted by topic.

-- phoebe

---

foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l