Am 22.08.2014 04:18 schrieb "Erik Moeller" <>:
> On Wed, Aug 20, 2014 at 12:32 AM, Pine W <> wrote:
> > I am curious to hear your thoughts about the proposed Technology
> > That idea has some community support and had been discussed at some
> > on the WMF Board Noticeboard.
> I think it has merits if it's mostly used as a dispute resolution
> body. I think we need to have conflict resolution and escalation
> protocols for technology issues. Ideally WMF and a group of community
> members (whether in all cases truly representative or not) who are in
> conflict about a certain issue or outcome should be able to come to a
> consensus _between each other_. But when that's not possible, a group
> that is designed to be accountable to both WMF's mission and the
> community's consensus may need to be called upon to make a final call
> that is binding. In the current governance structure, that could be a
> group like the stewards. But it could be something new created for
> that purpose, if the community supports it.
> This all presupposes that we collectively sign up for this whole
> "shared power" idea. It's a Board creation, a guiding principle, and
> all that. But that doesn't mean the community of people who've spent
> much of their lives building Wikimedia's projects as volunteers do
> believe in it. Maybe we should ask them, as a group, offering the pros
> and cons of that approach. It's very different futures -- a WMF that
> exists purely to do what communities ask it to, or a WMF that exists -
> in part - to look forward, close gaps, and help anticipate where we
> want to be 3, 5, 10 years from now. Irrespective of what my own take
> might be, both approaches do truly have their merits.
> If we sign up collectively for "shared power", then today, we lack the
> mechanisms to implement that principle effectively, which is why we
> have conflicts over power which is not shared.  And a community
> elected committee (perhaps with some additional representation of
> external expertise) might be one such mechanism, but if we don't have
> agreement on the basic idea, no mechanism will work. If we do agree on
> the principle, we can try and play with different implementations.

erik, let me ask a little in a devils advocate style:

is the conflict not only triggered by a deliverable which was not good
enough? it did not include the authors in its use cases. the deliverable
e.g. did include one click more for the authors workflow. which make
hundreds of million clicks more if you sum it up.

in a standard business world we would see two scenarios: one, the
ecyclopaedia britannica model. the authors would own the web domain, and
sue the one who delivers bad software. the design needs to be properly
specified beforehand to do this.

two, the facebook model. a company providing software to author as primary
goal, and some mechanism built in to count reads. it does everything to
increase it and would right from the start not deliver a complicated author

the wmf tries to play both models. and it then suffers schizophrenia. the
one delivering insufficient software does not get punished.

the reason is very simple: wikipedias content is of such high quality that
one might leave it with little updates for the next 20 years. also, the
readers experience is of such high quality that one might leave it for 20

as somebody delivering software i understand your feelings quite well. you
get dug into a hole and do not know a good way to get out.

introducing additional levels of complexity is a well known strategy. but
we all know from our daily lives that we do tend to not like these levels
and bureaucracy.

erik, please can you tell me one good reason what hinders you to tackle the
source of all this, and rework the mediaviewer use case(s)?

devils adcocate mode out.

Wikimedia-l mailing list, guidelines at:

Reply via email to