[Foundation-l] Self-determination of language versions in questions of skin?

[Eugene Eric Kim]

On Sat, Jul 3, 2010 at 6:11 PM, David Gerard <dgerard at gmail.com> wrote:
> On 4 July 2010 02:03, William Pietri <william at scissor.com> wrote:
>> On 07/03/2010 04:47 PM, David Gerard wrote:
>
>>> Well. not really. He's asking the same question Greg Maxwell and I
>>> asked last month about the language list defaulting to open rather
>>> than closed: If a wiki voted for it, would that override the usability
>>> team's dictates? That was a straight "yes or no" question, like this
>>> is, and we only got weaseling too.
>
>> That's phrased in terms of dominance. It's in effect asking who's the
>> bigger monkey. I think that's a conversation worth avoiding where possible.
>
> The dominance element was brought in, as you well know, by Trevor
> Parscal's preremptory reversion of the removal of the collapsed list.
> The dominance was, as you well know, already blatantly exercised. The
> question now is what defences are possible.

Which was then re-reverted. Many people have commit access, not just
the usability team, as this example itself demonstrated.

Both Tim and Erik's responses clearly addressed your original
question, David. Usability changes may be informed by wiki votes, but
they will not be determined by them.

Martin's original question was much more nuanced, and it's worth some
further discussion. Tim suggested that the right place to have this
specific discussion with developers is Bugzilla, and I hope that's
happening. I think there are also some broader issues worth discussing
and eventually clarifying:

1. Decision-making processes for development. Many of the large open
source projects have core teams consisting of both paid and volunteer
developers, and they typically have a decision-making process that is
independent of any single organization. For example, decisions on
Firefox are made by the Firefox core team, not by the Mozilla
Foundation. The Firefox core team happens to be mostly made up of
Mozilla Foundation developers, but that is not a structural
requirement. I believe the same holds true for MediaWiki, and if this
is the case, it's worth making explicit. Where there's ambiguity, it's
worth naming the ambiguity.

2. Developer versus community control. Wikimedia projects retain some
measure of independence and control, not just on the development side,
but also on the policy side. This is a good thing on many levels. On
the development side, it's not realistic to expect that a small team
of developers will be able to determine the best set of defaults for
700 different projects. However...

3. Mechanisms for informing decisions. As Erik pointed out, decisions
need to take into account different stakeholders, many of whom have no
voice in the process. So the question (and opportunity) is, how can we
give voice to the voiceless? One way is through the usual wiki and
mailing list channels. Another (perhaps less well utilized) is
considering OTRS feedback. I think the big opportunity is exposing and
incorporating more behavioral data. The usability team has already
started down this road, and I think there will be many more things to
come in the future. Incorporating this kind of data will better inform
both developers and contributors, which will hopefully help move us
toward a more informed and effective consensus process.

Note that there's been some good discussions/explorations on what sort
of data to look at and how to expose it on the strategy wiki:

http://strategy.wikimedia.org/wiki/Task_force/Analytics

=Eugene

-- 
======================================================================
Eugene Eric Kim ................................ http://xri.net/=eekim
Blue Oxen Associates ........................ http://www.blueoxen.com/
======================================================================