On Thu, Sep 2, 2010 at 8:40 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
I also think that we already have a fair number of tech employees outside of San Francisco, and AFAIK we're definitely open to hiring remote people for tech jobs unless in-person interaction is essential, say for a CTO or an EPM (although we do have a half-remote EPM). I do agree that the current level of community participation and feeling like you're part of the community is lacking, but I don't agree with your solutions.
What solutions do you propose?
You're assuming that development discussions actually take place in these channels, which is not the case. We mostly use them for chit-chat and private or office-related things. Questions like "how should I design X in my code" very rarely show up in these channels, and I don't think anyone would have a problem with being more conscious about this and moving to a public place for such a discussion.
I'm not assuming that -- I've been idling in the secret channel for a while now. (I keep almost saying its name, argh. Channels that aren't access-restricted and rely on secret names are annoying.) Most of it is just chitchat. But that's exactly something that the broader community should be part of, so that staff doesn't form its own group that excludes volunteers. 95% of it could easily be public, and the rest could easily be taken to private e-mail or PM. There is not enough stuff that needs to be private to justify a whole channel.
Some of your points are good, some I disagree with, and some I think are based on paranoia-fed overestimations as to how secretive we're being.
Let me put it this way: I am saying what I perceive as a volunteer. If the goal is to make volunteers feel like they're a full-fledged part of the development community, then the fact that I made this post and the fact that every single volunteer who's commented so far appears to basically agree with me means that ipso facto, my complaints are valid.
You're looking at it from the perspective of someone who sees all this stuff. "Oh, don't worry, it's nothing important." Well, thank you for reassuring me -- but I'm capable of deciding myself whether something is important, if I can see it. Maybe I'll find some of it important. But I'm given no opportunity. Nor is any other volunteer. The problem isn't necessarily the actual content of what we can't see, but the mere fact that so much is clearly hidden. It draws a line that need not exist.
When you hide things from volunteers, you cannot turn around and blame them for inaccurate speculation about what you've hidden. If you don't want speculation (or paranoia, as you put it), there's an easy solution: make it public. Anything short of that is not really going to solve the problem.
On Thu, Sep 2, 2010 at 8:08 PM, MZMcBride z@mzmcbride.com wrote:
In large part, the problems and solutions are obvious (you pointed out most of them, and this is hardly the first time this has come up). The issue is that those in power (those who sign the paychecks and employment contracts) are deliberately choosing to ignore these problems and their solutions.
I will reply to you in this thread only to say that as usual, you are being aggressive and unconstructive, and your input is unwelcome. Personally, I didn't even read any of your posts, or the responses to them, because I knew from long experience that it would be a waste of time. Part of building a successful community is allowing anyone the chance to speak, and part of building a successful community is evicting those who took their chance and blew it. Your contributions consistently clock in only moderately above the level of unconstructiveness that would justify actually banning you, and your endorsement of the point I'm making here will do nothing but harm it. You will not accomplish anything positive by attacking against the people who are responsible for fixing the problem, even if you were actually correct about the cause of the problem (which you are not). My advice to you right now is that the most useful thing you can do is not comment in this thread again.
On Thu, Sep 2, 2010 at 9:20 PM, Erik Moeller erik@wikimedia.org wrote:
I don't agree with unrealistic suggestions (e.g. face-to-face meetings have very real and very serious productivity advantages that we don't want to lose)
But somehow most open-source projects do very well without them, including projects much bigger and better-funded than MediaWiki. I did try to emphasize this in my initial post, but several people apparently missed it. Do you think Wikimedia could do better than to emulate any of the high-profile projects that use almost no face-to-face conversation?
but we've generally been trending in this direction.
My observation as a volunteer is the opposite.
Finally, most of these decisions aren't made by "executive fiat" -- Wikimedia is a very collaborative organization, and virtually all the decisions about how/where to communicate and work have been made by the people doing the work.
Except that volunteers can't do the work on some projects, because we're treated as outsiders and aren't interested in committing lest we be summarily reverted. Platonides' reverted usability commit (even if later reverted back) only confirmed the suspicion that a lot of us held and still hold, that participating in paid projects is a waste of time. I'm not the only one who feels that way, by far. You cannot claim to be a bottom-up meritocracy when a large segment of developers are excluded from the bottom to begin with.
Put it this way: what you're saying here would be akin to allowing a Wikipedia to disabling editing by anonymous users. Sure, it's a bottom-up decision, but it's one that's antithetical to the way that Wikimedia projects are supposed to run. Such requests have been made, and they were always denied (to my knowledge). If you're going to say that Wikimedia wants to allow more centralized development because you think it's more efficient, or something -- fine. That's your decision to make. But please don't say that it's not up to you to decide.
On Fri, Sep 3, 2010 at 1:20 AM, Tim Starling tstarling@wikimedia.org wrote:
Your recommendations seem insensitive and unrealistic. What works for you does not necessarily work for everyone.
It works for many, many open-source projects. Does Wikimedia want to be among them, or does it want to be among the projects that are open-source but have a stagnant community because they don't involve volunteers enough and the code is tightly controlled by a sponsoring organization? There are countless projects of both types -- both strategies work, to a degree. Completely closed-source development works too. Wikimedia is free to pick whichever model best fits its needs and ideals.
On Fri, Sep 3, 2010 at 3:51 AM, Danese Cooper dcooper@wikimedia.org wrote:
I'm not going to deconstruct your suggestions; I actually agree with several of them (although I think you'd find the reality of flagship open source projects somewhat different than the legend).
I can say that despite being a nobody at Mozilla and having gotten only one (rather trivial) patch accepted, I feel like I'm taken more seriously by most of their paid developers than by most of ours. I know more about what Mozilla is planning to do in their next release than what Wikimedia employees are planning. I've had lengthy discussions on occasion with core Mozilla developers, and sometimes I've gotten something changed because of it. I can say none of these things about any Wikimedia project that's dominated by paid employees.
Gradually I decided these were the most serious problems (in order of importance) to tackle with a new design WMF Tech:
- Eliminate single points of failure / bottlenecks
- Reconfigure into teams designed to encourage faster (shorter
duration) and more accurate projects / deployments 3. Develop programs to encourage / grow volunteers into paid staff...recognizing that as a non-profit WMF needs to plan for more frequent turnover in the Tech department to ensure that we can grow expertise across the dev community rather than concentrating it in a few core people. 4. Restore the balance between community-led and foundation-led efforts so WMF feels again like a partnership rather than concentric circles of permission / blame
I can agree with that list of priorities. Wikimedia has a bunch of problems right now, and 3-4 are definitely less important than 1 (not sure about 2). I think there are changes that could be made right now with little administrative effort that would greatly improve 3-4, which I've outlined -- all of my proposals but the first two. I'm somewhat disappointed that no one of importance took any of them seriously. But if you say you'll get to the issue later, well, I can hope.
Let me ask one thing, though. When you do get to the questions of volunteer involvement, start out by ignoring everything the paid people think or say. Compile a list of everyone who's made at least twenty commits as a volunteer (so including contractors outside their contract work) in the last couple of years, or whatever. Round up a smaller group of them in #mediawiki or wikitech-l and have them make a survey, with questions like: "What motivated you to volunteer for MediaWiki? What do you think would encourage more volunteers? What are the biggest things that prevent you from contributing more? Have you contributed to Wikimedia-sponsored projects like the Usability Initiative? If not, why not?" Preferably, do not allow any paid staff to have the final decision on what goes into the survey -- ask a volunteer to decide. Send the survey to the whole list, post the answers publicly, and let everyone digest them.
What has happened so far in this thread, by and large, is that paid employees have said they don't think things like private mailing lists are a problem. But if you're trying to involve volunteers, paid employees' opinions don't matter. You need to find what volunteers think. Maybe in the end you'll decide that something would annoy paid people too much to implement, or whatever -- but you have to start by acknowledging what is actually turning off volunteers, according to them, not what you think is or should be turning them off. This has not happened so far.