Community, collaboration, and cognitive biases

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

Aryeh Gregor
On Wed, Jun 9, 2010 at 8:46 PM, Rob Lanphier <[hidden email]> 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 <[hidden email]> 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.

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

John Mark Vandenberg
On Fri, Jun 11, 2010 at 7:00 AM, Aryeh Gregor
<[hidden email]> wrote:

>....
>
> 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.
> ...
>...  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.

Mozilla is an excellent example of a non-profit organisation who also
have a similar policy of expecting their staff to do their work out in
the open, and they regularly recruit from within their community.

Read more about their governance, etc here

http://www.mozilla.org/about/governance.html

See point 8 of the Mozilla Manifesto

http://www.mozilla.org/about/manifesto

"8. Transparent community-based processes promote participation,
accountability, and trust."

You can see a list of their mailing lists here:

http://www.mozilla.org/community/forums/

.. including a vibrant list about governance ;-)

http://groups.google.com/group/mozilla.governance

They do have private lists as well, and (had?) a private bug database
for in-the-wild security issues, however these are subject to review

http://wiki.mozilla.org/GovernanceIssues#Shouldn.27t-Be-Private_Mailing_Lists

--
John Vandenberg

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

Michael Snow-3
In reply to this post by Austin Hair
On 6/9/2010 2:01 AM, Austin Hair wrote:

> On Wed, Jun 9, 2010 at 12:55 AM, Aryeh Gregor
> <[hidden email]>  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.)
>    
When it comes to the board, along with others who have oversight
responsibilities like management staff, there's an additional factor in
this. It's not generally appropriate, or good for staff morale, to
publicly go through the work of employees or contractors when you're in
such a position. There are good reasons that work evaluations and other
personnel matters are considered confidential. I don't mean to say that
staff shouldn't be discussing code, roadmaps, or rationales as widely
and openly as possible, but 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


_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

John Mark Vandenberg
On Fri, Jun 11, 2010 at 4:49 PM, Michael Snow <[hidden email]> 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

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

Chad
In reply to this post by Michael Snow-3
On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow <[hidden email]> 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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

Michael Snow-3
Chad wrote:

> On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow <[hidden email]> 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

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

Aryeh Gregor
On Fri, Jun 11, 2010 at 11:22 AM, Michael Snow <[hidden email]> 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.

Someone pointing out bugs in your code shouldn't be demoralizing
unless there's some kind of insanely unrealistic social expectation
that your code isn't *supposed* to have any bugs.  That might exist in
dysfunctional corporate bureaucracies, where people are expected to
try hiding all flaws from their bosses, but in an open-source
environment where everyone finds problems in everyone else's code all
the time, it should be no special problem.

(Of course, we don't use a review-then-commit system.  Hypothetically
it's commit-then-review, but realistically more like
commit-then-hopefully-glance-over.  Personally, I'd be happy if
*anyone* seriously reviewed my code and pointed out little things I
had gotten wrong, rather than silently marking it "ok" and/or pointing
me to the bugs it caused after they've already happened.)

Needless to say, things like work evaluations can still be private!
Who Wikimedia employs isn't the development community's concern, at
least not directly.  Nor necessarily what general type of feature it
chooses to fund.  The development community *is* concerned with things
like what code gets committed and how things are implemented.  I don't
mind if the Board and CTO confer among themselves and decide "We're
going to be hiring people X, Y, and Z to work on
usability/upload/whatever", but the resulting code needs to go through
the *exact* same process that a volunteer's code goes through to get
accepted, from design to deployment.

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

Michael Snow-3
Aryeh Gregor wrote:

> On Fri, Jun 11, 2010 at 11:22 AM, Michael Snow <[hidden email]> 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

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

Sue Gardner
In reply to this post by Chad
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 <[hidden email]>
Date: Fri, 11 Jun 2010 07:13:37
To: Wikimedia Foundation Mailing List<[hidden email]>
Subject: Re: [Foundation-l] Community, collaboration, and cognitive biases

On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow <[hidden email]> 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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

phoebe ayers-3
In reply to this post by Michael Snow-3
On Fri, Jun 11, 2010 at 8:22 AM, Michael Snow <[hidden email]> wrote:

> Chad wrote:
>> On Fri, Jun 11, 2010 at 2:49 AM, Michael Snow <[hidden email]> 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

If I understand Michael's point it doesn't have anything to do with
code. Insert "criticizing how the Foundation is managed" here instead,
and I think it makes more sense. Nobody wants their boss to publicly
provide an evaluation of them to the world (even if it's not all
negative, and even if it's only about one part of a greater whole.)

The Board is in a particularly touchy position here, because they are
providing guidance and oversight for the whole Foundation, including
the performance of the E.D., who in turn can hire and fire people. But
it was recently pointed out to me that they are not the only ones;
given how our community *does* work with bottom-up leadership, if a
respected community member speaks out criticizing something they are
likely to be listened to, and the sting of criticism felt, regardless
of the outcome. It is easy to give such criticism -- just about as
easy as typing a Foundation-l message -- but not many of us subject
our own personal work to ongoing potential for public criticism like
this (not even on-wiki, except for administrators and those routinely
doing controversial things).

This is where Sue's note on having mutual respect is applicable, I
think. And yes, I imagine how criticism affects you depends on your
personality, and what the job at hand is. I don't mind criticism at
all... unless you criticize my writing, and then I get instantly more
touchy. Am I a perfect writer? Obviously not, and I have no
expectation of being so, but my reaction is instinctual because it's
something I care about. We all have our issues like this, I think;
often you don't know what they are for someone else. Keeping a tone of
respect helps.

I believe there is a particular additional issue with the
staff/community divide in that there are differing expectations when
you are assigned a job and when you take that job on yourself with no
managerial control. I have done both as a Wikimedia volunteer -- I
have been assigned jobs in the context of Wikimania, and it feels
quite different from being bold and choosing to do something yourself,
regardless of whether you're getting paid or not. This is not a
good/bad difference, simply a difference -- and one that I think we
need to collectively consider in the context of how community
governance and the process of "bold, revert, discuss" should work for
a staff-community project like usability.

-- phoebe

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Reply | Threaded
Open this post in threaded view
|

Re: Community, collaboration, and cognitive biases

Chad
In reply to this post by Sue Gardner
On Fri, Jun 11, 2010 at 2:25 PM,  <[hidden email]> wrote:
> 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.
>

I personally think it's part of your job :) I'd much rather have a boss who
stands up for me than one who lets me get dragged under the truck. I've
worked both, and the former is certainly preferable. And I certainly don't
think of this as us-vs-them, as someone (Rob?) pointed out earlier, we're
all on the same side here!

> (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.
>

That is a very good point, and I do think people forget it (myself included).
As a volunteer, you can walk away for days/weeks/months if you get
overwhelmed/pissed off/bored with contributing. We also get the benefit of
being able to work on the stuff that interests us 100% of the time, not
necessarily what the Foundation needs. Staff of course do not have these
luxuries--at least not if they want to stay employed :)

On a minor sidebar, I'm a huge advocate--and I know others are as well--
of making sure that staff have some time to work on things that interest
them in addition to their normal work. Some stuff we do is boring, and being
able to relax and do something that is interesting, challenging or fun makes
us happier (and IMHO a bit more productive).

> 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 :-)
>

Mailing lists can be ruthless ;-) But yes, we could all could do well to
be a bit nicer sometimes. The pseudo-anonymity of the Internet
sometimes encourages people to be a bit less judicious in how they
say things.

I've personally said things that were a little overly sarcastic, overly
blunt, or probably just downright rude and I know others have too.
But we all mean well and we're all working toward a common goal.
The majority of Wikipedia's growth occurred entirely under volunteer-
driven effort. Now that we've got a Foundation-driven staff, there
are bound to be some struggles as everyone settles into their roles
for the long-term. The Foundation and community are growing up,
we're facing a few growing pains, but I think it's a Good Thing.

-Chad

_______________________________________________
foundation-l mailing list
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
12