In the past, this mailing list has been used for discussions of staff conduct, which I am not sure is the best idea when identifiable people are involved. I suggest that a first line of approach would be to discuss the matter civilly with the people directly involved including the employee and other volunteers, and if that doesn't get results, then go to the employees' supervisor.
WMF HR has told me in the past that they can also step in with situations like this. Pine On Thu, Jul 3, 2014 at 10:57 AM, Isarra Yos <zhoris...@gmail.com> wrote: > Hey, all. Bit of a question, here. > > Basically, how does "comment on the content, not the contributor" apply to > staff and contractors? What can we, as volunteers, do when we believe staff > have gone too far (besides create drama on a mailing list)? > > > In many of our communities, we have a saying: "comment on the content, not > the contributor". When working with others, this is quite useful, and > something we definitely want to remember, because it reminds us to > cooperate and find use for whatever content is good, and it also helps us > to avoid making personal attacks and other generally unhelpful comments > about the people involved that tend not to be relevant to the situation. > > Of course, this depends a great deal on the situation itself - this > applies to an edit dispute or a bug report or an RfC about content or > features or what have you, but what about when the contributor IS a > relevant topic? In volunteer circles it generally boils down to a question > - is the contributor causing more trouble than they're worth? If so, an > appropriate committee or whatever can do something sanctiony, and the > situation will be resolved for the time being. > > But what if it's not a volunteer? What if it's a staff developer who is > consistently ignoring project consensus and needs, or a team that refuses > to justify their decisions even in light of scrutiny, or a contractor hired > to do something specific and community-facing who won't actually do it, and > on top of that won't let volunteers do the needful either? With a > volunteer, it's often a pretty simple matter to simply remove an individual > or group from a topic or project, but with staff, the situation is a lot > more complicated - not just because they're paid, but also because they > have specific obligations and requirements, as well as the power and > authority the position grants. Volunteers come and go, and answer to other > volunteers. Staff are supposed to do things, and paid to be doing things, > and answer to staff (and also the board and crap, but at the level I'm > talking about it's basically just other staff). > > There's a very real disconnect here, and though community liaisons are > supposed to be bridging that gap, this works far better on content projects > than in development, where developers and designers and whatnot need to > communicate with each other, no matter who they are, in order to get things > done. And indeed, most staff here are pretty great about this and you can > totally go right up to them and talk about their work and collaborate and > what have you, but sometimes they aren't. And that's a problem. > > So what can we, as volunteers, do in such cases? What are our channels for > bringing up issues with staff, so that we don't just wind up bringing it up > somewhere completely inappropriate, where we really should be commenting on > the content itself? > > -I > > _______________________________________________ > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ > wiki/Mailing_lists/Guidelines > Wikimedia-l@lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe> _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
