On Thu, Sep 2, 2010 at 8:40 PM, Roan Kattouw <roan.kattouw(a)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(a)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(a)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(a)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(a)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:
1. Eliminate single points of failure / bottlenecks
2. 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.