On Thu, Sep 2, 2010 at 8:40 PM, Roan Kattouw <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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.

_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to