On Sat, Jul 3, 2010 at 6:11 PM, David Gerard <[email protected]> wrote: > On 4 July 2010 02:03, William Pietri <[email protected]> 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/ ====================================================================== _______________________________________________ foundation-l mailing list [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
