Hoi,
I am happy for you that you think the reader experience is so great in the
"devils advocate mode". In reality when I read a Wikipedia article because
I want information all too often I hate what I get. The fact that it is the
best around does not make me like the lack of clarity, the inconsistency of
where information is found. All too often articles are written to overcome
the power struggle around NPOV and suffer as a result.
Erik indicated that WMF has written software predominantly for editors and
not for readers. All our projects suffer as a result from not getting to
our intended audience and not achieving what we aim to achieve; share in
the sum of all knowledge. Remember, our projects are first and foremost
about providing information / knowledge to people. We are stuck in the
process of producing the data that may once become information.
More focus on our end-users, even to the extend of "marketing" our data is
what will get us significantly more readers and consequently achieve our
goals more successfully.
Thanks,
GerardM
On 22 August 2014 07:54, rupert THURNER <rupert.thurner(a)gmail.com> wrote:
Am 22.08.2014 04:18 schrieb "Erik Moeller"
<erik(a)wikimedia.org>rg>:
On Wed, Aug 20, 2014 at 12:32 AM, Pine W <wiki.pine(a)gmail.com> wrote:
> I am curious to hear your thoughts about the proposed Technology
Committee.
> That idea has some community support and had
been discussed at some
length
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
experience.
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
years.
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.
rupert
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>