On Feb 23, 2016, at 10:24 AM, Mardetanha
<mardetanha.wiki(a)gmail.com> wrote:
it would be great if someone could give us tl;dr version of this mail
Mardetanha
On Tue, Feb 23, 2016 at 5:21 PM, James Hare
<jamesmhare(a)gmail.com> wrote:
Hello everyone,
Of the many issues, real or perceived, currently under discussion, one of
them is the matter of strategy: of the Wikimedia Foundation and of the
movement in general. I’ve been editing Wikipedia since November of 2004 and
have noticed that the general points of tension have revolved around who
has authority or responsibility to do what. I will explain what I mean by
that.
There is no one “strategy.” Or rather, strategy has different components
to it, and it is important to note and understand these different
components because they have their own histories and associated arguments.
There is no possible way I can capture every nuance of this, but when we
say “strategy” we should think of at least three things: content strategy,
program strategy, and product strategy.
Content has, almost exclusively, been a prerogative of the communities of
the various Wikimedia projects, and not that of the Foundation. [1] English
Wikipedia, for example, argues bitterly over what is notable, what is not
notable, and what should and shouldn’t be deleted on a given day, but the
Wikimedia Foundation is not involved in that. While the Wikimedia
Foundation does fund content creation initiatives from time to time, it
does not decide, for instance, which monuments are worthy of Wiki Loves
Monuments, or which artists should be the focus of Art+Feminism. I’m not
pointing this out because it’s remotely interesting, but because it’s so
widely agreed upon that the WMF has no editorial authority that we don’t
even need to talk about it.
There are other areas that we do need to talk about; not necessarily to
devise a master plan, or to draw lines in the sand, but to at least
understand who thinks what and where our opinions diverge. This brings me
to my second point: programs. I am referring to initiatives to get more
people involved in the Wikimedia projects, to build bridges with other
organizations, to make Wikimedia as much a part of the offline world as the
online world. The Wikimedia Foundation did some of the original programs in
the late 2000s, with mixed success. Chapters came along and also came up
with programs; GLAM, for instance, was developed outside of the Wikimedia
Foundation. Over time, the Foundation decided that it was not so interested
in running programs directly as much as they were interested in funding
others to carry them out and serving as a sort of central hub for best
practices. As far as I can tell, as someone who has served on the board of
a Wikimedia chapter for almost five years, there seems to be a general
consensus that this is how programs are done. This operating consensus was
arrived at through a combination of the Wikimedia Foundation’s “narrowing
focus” and by the enthusiasm of chapters, groups, and mission-aligned
organizations to carry on outreach work.
Then there is the product strategy, which is the most contentious of them
all. By “product” I am referring to the subset of technology that readers
and editors interact with on a day-to-day basis. The sacred workflow. (Much
of the arguments about technology are out of my depth so I won’t be
commenting on them; they also include rather arcane infrastructural stuff
that I don’t think most Wikimedia users or contributors care about.) All of
our arguments, from the usability initiative to the present day, have
focused on: who is in charge of the user experience? I have heard different
things; one perspective holds that “the community” (usually not further
specified) gets to make the final decision, while I have also heard from
some that technological matters are purely the prerogative of the Wikimedia
Foundation. [2] I am not sure what the present-day company line is but I
suspect it’s somewhere in the middle.
I do not know what the “true” answer is, either. There is a lot to be said
for treating the user experience as products to be professionally managed:
there has been tremendous study in the area of how to design user
experiences, and Wikipedia is notorious for being difficult to edit as a
newcomer. With this in mind, the Wikimedia Foundation did the best it
could, with limited resources, and despite some successes managed to create
some ham-fisted products that did not address the needs of the users and—at
worst—threatened disruption. This has gotten better in time; the visual
editor, for example, has made tremendous progress on this front. But not
every issue is settled. What about the products that need substantially
more improvement before they can be used at large? What about things that
we should be working on, but aren’t, or are doing so at a glacial pace
because we are being stretched too thin? And now that WMF grantees can
develop code for deployment in production (such as MediaWiki extensions),
what is the relationship between these projects and the overall product
strategy of the Wikimedia Foundation? On the Reading half of the equation,
who gets to decide how content is presented, and how are these decisions
made?
I am sure we each as individuals have answers to these questions, but we
do not have a common understanding, whatsoever, the same way we generally
understand that the Wikimedia Foundation does not do editorial policy, or
that the Wikimedia Foundation generally avoids doing on-the-ground program
work the same way chapters do. We do not even agree on how much the
Wikimedia Foundation should focus on the software product aspect as opposed
to other aspects.
Nor do I think we will arrive at this conclusion through developing a
grand strategy and an overall movement framework. We’re big and
decentralized, and we need to accommodate opportunities where they exist.
Exhaustive planning documents do not lend themselves to that. And it is
unlikely we can all come to a happy solution that accommodates everyone and
everything.
This is why it is up to the Wikimedia Foundation to define its own role
within the movement. My hope is that they do so by actively seeking out the
needs of the entire movement, since they are in the unique position where
they can support a large share of the movement. But it will need to define
its role in the development of products—whether they be editing products,
or products that present Wikimedia content. Whether it will seek to control
the presentation of content or merely advise on the community’s own
decisions. The most feasible way forward I see is that the Wikimedia
Foundation decides what it is best suited to do, set its own boundaries,
and call on the rest of the movement to fill in the gaps. This will help
the Wikimedia Foundation focus its work: by explicitly saying “no” to some
things and determining they are not within their remit, it opens the doors
(through grant funding or some other mechanism) for other people or groups
to do things that they are best suited to do. With programs being handled
by non-WMF entities and some software development (including my own work at
WikiProject X) being handled outside of the Foundation, this is possible.
The Wikimedia movement is a broad movement, and it would not be practical
to come up with a movement-wide strategy. However, the Wikimedia Foundation
specifically should try to define its own role with respect to software and
call on the rest of the movement to fill in the gaps based on its needs.
Respectfully,
James Hare
[1] I’m not counting their rare interventions—for legal purposes—as
editorial control.
[2] I honestly do not remember who said it or when. My point is not that
someone out there has (or had) a heretical (or righteous) opinion, but that
people have very divergent opinions on this.
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: