Hi everybody --

I just wanted to follow up quickly that this report has been published and
is available here:


> I know that some folks were wondering about all the consultation comments
> about features, interfaces, and product improvements that didn't get
> incorporated into the strategy. We knew from the beginning of the processes
> that we'd certainly get quite a few of these requests that were too
> specific to be integrated into long-term strategic thinking and planned
> accordingly to document them. The goal was to consider how they might be
> taken up by either Foundation staff or interested volunteer developers. As
> a result, we're publishing a “Features report” written by Suzie Nussel that
> summarizes these requests, and should be a useful starting point for
> specific improvements that could be addressed in the shorter term.


 The PDF version is at:
https://commons.wikimedia.org/wiki/File:Wikimedia_Movement_
Strategy_2017_-_2017_Features_and_programs_(cycle_1).pdf

and the wiki version of the report is at:
https://meta.wikimedia.org/wiki/Strategy/2017/Reports/
Features_and_Programs_report_summary

The Audiences team will be using this report as an input into future
product discussions and annual planning.

-Toby

On Fri, Oct 20, 2017 at 10:13 AM, Katherine Maher <kma...@wikimedia.org>
wrote:

> Hi all,
>
> Sorry for the delay in chiming in. It's been a busy few weeks, and while I
> haven't made a public update about strategy in a while, work has been
> continuing! We've now closed Phase 1, and we're heading into Phase 2, in
> which our objective is to start thinking about how we make the strategic
> direction into a plan of action and implementation. It's an opportunity to
> create greater clarity about how we each understand the direction, how we
> might set goals against it, what we may need to change to achieve these
> goals, and how we can contribute -- as projects, communities, and
> individuals. I’ll be sending my next weekly update shortly but I wanted to
> acknowledge the contributions in this thread first.
>
> I've read through this entire thread, and I've agreed, disagreed, agreed
> again, and started emails only to see new ones come in and have to scrap my
> drafts. While I found myself often agreeing with Erik, I dig the challenges
> you all have put forward and appreciate the diversity of opinions. Some of
> our differences stem from the unique contexts of the groups and individuals
> responding and will result in differences in implementation in each
> community. Other differences, such as questioning the very concept of
> source credibility, will certainly require additional discussion. But
> regardless of where we end up, it has been a delight to follow such a rich,
> substantive conversation. This has been one of the best, and
> most thought-provoking, Wikimedia-l threads I've read in some time, and I
> hope that it is the first of many as we go into Phase 2 of the movement
> strategy process.
>
> A few more responses inline:
>
> 2017-10-04 11:19 GMT-07:00 Lodewijk <lodew...@effeietsanders.org>:
> >
> > I don't understand what exactly that direction is headed towards, there
> is
> > too much space for a variety of interpretation. The one thing that I take
> > away though, is that we won't place ourselves at the center of the free
> > knowledge universe (as a brand), but want to become a service. We don't
> > expect people to know about 'Wikipedia' in 10 years, but we do want that
> > our work is being put to good use.
>
> It's always helpful to read critique as a challenge to our logical
> assumptions. Lodewijk, I see where your interpretation comes from here, but
> it is vastly different than how I interpret from this statement. To the
> contrary, I wouldn’t say "service" and "brand" are mutually exclusive. I do
> think that Wikimedia should want to continue to be known as a destination
> for free knowledge, and we do want to increase brand awareness, especially
> in areas and contexts where we are not yet well (or not at all) known. Our
> brand (including our communities) and visibility are some of our most
> valuable assets as a movement, and it would be strategically unwise not to
> build on them for long-term planning.
>
> When I think about knowledge as a service, it means that we want this, *and
> much more*. It’s additive. We want to be who we are today, *and* we want to
> provide a service to other institutions. We want to use that brand and
> visibility to work with others in the ecosystem. We also want to be present
> in new experiences and delivery channels, in order to preserve the direct
> interface connection with Wikipedia's contributors and readers that we have
> on the web. I see this as essential - for our readers, it's about ensuring
> a core promise: that the chain of evidence for the information they seek is
> unbroken and transparent, from citation to edit. For our contributors, it's
> about extending ways to contribute as our digital interfaces evolve.
>
> We know from the Phase 1 research that many readers see Wikipedia as a
> utility, whether we like it or not. We know that people reuse our content
> in many contexts. My interpretation of “knowledge as a service” is not that
> we vanish into the background, but that we become ever more essential to
> people's lives. And part of our doing so is not only enriching the
> experience people have on Wikipedia, but investing in how Wikipedia can
> promote the opening of knowledge overall. Today, MediaWiki and Wikibase are
> already infrastructures that serve other free knowledge projects, in turn
> enriching the material on which our projects can draw. What more could we
> do if we supported openness more systemically?
>
> I understand that the direction may still feel too vague. A direction for
> the 2030 horizon is bound to lack specifics. I actually think this is okay.
> The direction comes from a small-ish group of drafters trying to make sense
> of 8 months of thousands of perspectives. In that sense, a small group can
> only do so much. It is now our responsibility, as movement actors, to take
> this direction and interpret it in our respective contexts, based on our
> respective experiences. This will be a major part of Phase 2 of the
> movement discussions.
>
> 2017-10-09 17:44 GMT-07:00 Erik Moeller <eloque...@gmail.com>:
> >
> > With an eye to 2030 and WMF's long-term direction, I do think it's
> > worth thinking about Wikidata's centrality, and I would agree with you
> > at least that the phrase "the essential infrastructure of the
> > ecosystem" does overstate what I think WMF should aspire to (the
> > "essential infrastructure" should consist of many open components
> > maintained by different groups).
>
> There is indeed an element of aspiration in that phrase. I knew it would be
> controversial, and we talked about it quite a bit in drafting, but
> advocated that we include it anyway. After all, our vision statement is "a
> world in which every single human can freely share in the sum of all
> knowledge." That's certainly inclusive (it has no single parties or
> ownership) but it is also wildly aspirational. But despite the
> impossibility of our that aspiration, it has worked quite well: we've made
> great strides toward a project that is "impossible in theory".
>
> For each person who felt we should moderate the language of the direction,
> there was another who wanted us to be more bold and recapture this
> ambition. They wanted us to believe in ourselves, and give the world
> something to believe in. As Wikimedians, we tend to prefer matter-of-fact,
> sometimes plain and noncommittal statements. While that works well for NPOV
> content, a strategic direction also seeks to inspire ambitious efforts. The
> drafting group removed much of the flowery language from the earlier
> versions of the draft, but the goal was to keep just enough to inspire
> movement actors and external partners.
>
> 2017-10-09 17:44 GMT-07:00 Erik Moeller <eloque...@gmail.com>:
> >
> > Wikidata in particular is best seen not as the singular source of
> > truth, but as an important hub in a network of open data providers --
> > primarily governments, public institutions, nonprofits. This is
> > consistent with recent developments around Wikidata such as query
> > federation.
>
> Personally, I couldn’t agree more. I see federated structured data as an
> inevitable (and very favorable) outcome of the concept of a service-based
> model. Distribution enables greater flexibility in implementation and
> customization across the network while improving the resilience of the
> whole system. This is true in terms of technical stability, political
> influence or censorship, and breadth and depth of content. If one starts to
> understand Wikidata as a project, and Wikibase as a platform, we start to
> really be able to see how a broader adoption of open structures and
> attribution models can only enrich and increase the open ecosystem overall.
>
> I also think the Wikidata model is one that has been working very well and
> one that others in our ecosystem could benefit from. Today, on our newest
> Wikimedia project, we work with governments, the private sector, and
> individual community members, in largely constructive ways. And in many
> cases, the very existence of Wikidata makes it possible for these
> institutions to be open, when they would otherwise lack the expertise or
> resources to build their own open data infrastructure.
>
> For me, “Knowledge as a service” means supporting those institutions by
> providing the infrastructure that they can use for this purpose, and also
> accompanying them through the social and institutional changes that come
> with opening data and freeing knowledge. That infrastructure could be
> Wikidata, it could be other Wikimedia projects, or it could be other
> Wikibase instances, depending on what makes the most sense for each
> context.
>
> Anyway, there's a lot more to discuss, and thank you all again for these
> excellent conversations!
>
> I know that some folks were wondering about all the consultation comments
> about features, interfaces, and product improvements that didn't get
> incorporated into the strategy. We knew from the beginning of the processes
> that we'd certainly get quite a few of these requests that were too
> specific to be integrated into long-term strategic thinking and planned
> accordingly to document them. The goal was to consider how they might be
> taken up by either Foundation staff or interested volunteer developers. As
> a result, we're publishing a “Features report” written by Suzie Nussel that
> summarizes these requests, and should be a useful starting point for
> specific improvements that could be addressed in the shorter term.
>
> See you soon with the next strategy update.
>
> Katherine
>
>
> On Thu, Oct 12, 2017 at 8:01 AM, Erik Moeller <eloque...@gmail.com> wrote:
>
> > On Tue, Oct 10, 2017 at 7:31 AM, Andreas Kolbe <jayen...@gmail.com>
> wrote:
> >
> > > Wikidata has its own problems in that regard that have triggered
> ongoing
> > > discussions and concerns on the English Wikipedia.[1]
> >
> > Tensions between different communities with overlapping but
> > non-identical objectives are unavoidable. Repository projects like
> > Wikidata and Wikimedia Commons provide huge payoff: they dramatically
> > reduce duplication of effort, enable small language communities to
> > benefit from the work done internationally, and can tackle a more
> > expansive scope than the immediate needs of existing projects. A few
> > examples include:
> >
> > - Wiki Loves Monuments, recognized as the world's largest photo
> competition
> > - Partnerships with countless galleries, libraries, archives, and museums
> > - Wikidata initiatives like mySociety's "Everypolitician" project or Gene
> > Wiki
> >
> > This is not without its costs, however. Differing policies, levels of
> > maturity, and social expectations will always fuel some level of
> > conflict, and the repository approach creates huge usability
> > challenges. The latter is also true for internal wiki features like
> > templates, which shift information out of the article space,
> > disempowering users who no longer understand how the whole is
> > constructed from its parts.
> >
> > I would call these usability and "legibility" issues the single
> > biggest challenge in the development of Wikidata, Structured Data for
> > Commons, and other repository functionality. Much related work has
> > already been done or is ticketed in Phabricator, such as the effective
> > propagation of changes into watchlists, article histories, and
> > notifications. Much more will need to follow.
> >
> > With regard to the issue of citations, it's worth noting that it's
> > already possible to _conditionally_ load data from Wikidata, excluding
> > information that is unsourced or only sourced circularly (i.e. to
> > Wikipedia itself). [1] Template invocations can also override values
> > provided by Wikidata, for example, if there is a source, but it is not
> > considered reliable by the standards of a specific project.
> >
> > > If a digital voice assistant propagates a Wikimedia mistake without
> > telling
> > > users where it got its information from, then there is not even a
> > feedback
> > > form. Editability is of no help at all if people can't find the source.
> >
> > I'm in favor of always indicating at least provenance (something like
> > "Here's a quote from Wikipedia:"), even for short excerpts, and I
> > certainly think WMF and chapters can advocate for this practice.
> > However, where short excerpts are concerned, it's not at all clear
> > that there is a _legal_ issue here, and that full compliance with all
> > requirements of the license is a reasonable "ask".
> >
> > Bing's search result page manages a decent compromise, I think: it
> > shows excerpts from Wikipedia clearly labeled as such, and it links to
> > the CC-BY-SA license if you expand the excerpt, e.g.:
> > https://www.bing.com/search?q=france
> >
> > I know that over the years, many efforts have been undertaken to
> > document best practices for re-use, ranging from local
> > community-created pages to chapter guides and tools like the
> > "Lizenzhinweisgenerator". I don't know what the best-available of
> > these is nowadays, but if none exists, it might be a good idea to
> > develop a new, comprehensive guide that takes into account voice
> > applications, tabular data, and so on.
> >
> > Such a guide would ideally not just be written from a license
> > compliance perspective, but also include recommendations, e.g., on how
> > to best indicate provenance, distinguishing "here's what you must do"
> > from "here's what we recommend".
> >
> > >> Wikidata will often provide a shallow first level of information about
> > >> a subject, while other linked sources provide deeper information. The
> > >> more structured the information, the easier it becomes to validate in
> > >> an automatic fashion that, for example, the subset of country
> > >> population time series data represented in Wikidata is an accurate
> > >> representation of the source material. Even when a large source
> > >> dataset is mirrored by Wikimedia (for low-latency visualization, say),
> > >> you can hash it, digitally sign it, and restrict modifiability of
> > >> copies.
> >
> > > Interesting, though I'm not aware of that being done at present.
> >
> > At present, Wikidata allows users to model constraints on internal
> > data validity. These constraints are used for regularly generated
> > database reports as well as on-demand lookup via
> > https://www.wikidata.org/wiki/Special:ConstraintReport . This kicks
> > in, for example, if you put in an insane number in a population field,
> > or mark a country as female.
> >
> > There is a project underway to also validate against external sources;
> see:
> >
> >   https://www.mediawiki.org/wiki/Wikibase_Quality_
> > Extensions#Special_Page_Cross-Check_with_external_databases
> >
> > Wikidata still tends to deal with relatively small amounts of data; a
> > highly annotated item like Germany (Q183), for example, comes in at
> > under 1MB in uncompressed JSON form. Time series data like GDP is
> > often included only for a single point in time, or for a subset of the
> > available data. The relatively new "Data:" namespace on Commons exists
> > to store raw datasets; this is only used to a very limited extent so
> > far, but there are some examples of how such data can be visualized,
> > e.g.:
> >
> >   https://en.wikipedia.org/wiki/Template:Graph:Population_history
> >
> > Giving volunteers more powerful tools to select and visualize data
> > while automating much of the effort of maintaining data integrity
> > seems like an achievable and strategic goal, and as these examples
> > show, some building blocks for this are already in place.
> >
> > >> But the proprietary knowledge graphs are valuable to users in ways
> > >> that the previous generation of search engines was not. Interacting
> > >> with a device like you would with a human being ("Alexa/Google/Siri,
> > >> is yarrow edible?") makes knowledge more accessible and usable,
> > >> including to people who have difficulty reading long texts, or who are
> > >> not literate at all. In this sense I don't think WMF should ever find
> > >> itself in the position to argue _against_ inclusion of information
> > >> from Wikimedia projects in these applications.
> >
> > > There is a distinct likelihood that they will make reading Wikipedia
> > > articles progressively obsolete, just like the availability of Googling
> > has
> > > dissuaded many people from sitting down and reading a book.
> >
> > There is an important distinction between "lookup" and "learning"; the
> > former is a transactional activity ("Is this country part of the Euro
> > zone?") and the latter an immersive one ("How did the EU come
> > about?"). Where we now get instant answers from home assistants or
> > search engines, we may have previously skimmed, or performed our own
> > highly optimized search in the local knowledge repository called a
> > "bookshelf".
> >
> > In other words, even if some instant answers lead to a drop in
> > Wikipedia views, it would be unreasonable to assume that those views
> > were "reads" rather than "skims". When you're on a purely
> > transactional journey, you appreciate almost anything that shortens
> > it.
> >
> > I don't think Wikimedia should fight the gravity of a user's
> > intentions out of its own pedagogical motives. Rather, it should make
> > both lookup and learning as appealing as possible. Doing well in the
> > "lookup" category is important to avoid handing too much control off
> > to gatekeepers, and being good in the "learning" category holds the
> > greatest promise for lasting positive impact.
> >
> > As for the larger social issue, at least in the US, the youngest (most
> > googley) generation is the one that reads the most books, and
> > income/education are very strong predictors of whether people do or
> > not:
> > http://www.pewresearch.org/fact-tank/2015/10/19/slightly-
> > fewer-americans-are-reading-print-books-new-survey-finds/
> >
> > >> The applications themselves are not the problem; the centralized
> > >> gatekeeper control is. Knowledge as an open service (and network) is
> > >> actually the solution to that root problem. It's how we weaken and
> > >> perhaps even break the control of the gatekeepers. Your critique seems
> > >> to boil down to "Let's ask Google for more crumbs". In spite of all
> > >> your anti-corporate social justice rhetoric, that seems to be the path
> > >> to developing a one-sided dependency relationship.
> >
> > > I considered that, but in the end felt that given the extent to which
> > > Google profited from volunteers' work, it wasn't an unfair ask.
> >
> > While I think your proposal to ask Google to share access to resources
> > it already has digitized or licensed is worth considering, I would
> > suggest being very careful about the long term implications of any
> > such agreements. Having a single corporation control volunteers'
> > access to proprietary resources means that such access can also be
> > used as leverage down the road, or abruptly be taken away for other
> > reasons.
> >
> > I think it would be more interesting to spin off the existing
> > "Wikipedia Library" into its own international organization (or home
> > it with an existing one), tasked with giving free knowledge
> > contributors (including potentially to other free knowledge projects
> > like OSM) access to proprietary resources, and pursuing public and
> > private funding of its own. The development of many relationships may
> > take longer, but it is more sustainable in the long run. Moreover, it
> > has the potential to lead to powerful collaborations with existing
> > public/nonprofit digitization and preservation efforts.
> >
> > > Publicise the fact that Google and others profit from volunteer work,
> and
> > > give very little back. The world could do with more articles like this:
> > >
> > > https://www.washingtonpost.com/news/the-intersect/wp/
> > 2015/07/22/you-dont-know-it-but-youre-working-for-facebook-for-free/
> >
> > I have plenty of criticisms of Facebook, but the fact that users don't
> > get paid for posting selfies isn't one of them. My thoughts on how the
> > free culture movement (not limited to Wikipedia) should interface with
> > the for-profit sector are as follows, FWIW:
> >
> > 1) Demand appropriate levels of taxation on private profits, [2]
> > sufficient investments in public education and cultural institutions,
> > and "open licensing" requirements on government contracts with private
> > corporations.
> >
> > 2) Require compliance with free licenses, first gently, then more
> > firmly. This is a game of diminishing returns, and it's most useful to
> > go after the most blatant and problematic cases. As noted above, "fair
> > use" limits should be understood and taken into consideration.
> >
> > 3) Encourage corporations to be "good citizens" of the free culture
> > world, whether it's through indicating provenance beyond what's
> > legally required, or by contributing directly (open source
> > development, knowledge/data donations, in-kind goods/services,
> > financial contributions). The payoff for them is goodwill and a
> > thriving (i.e. also profitable) open Internet that more people in more
> > places use for more things.
> >
> > 4) Build community-driven, open, nonprofit alternatives to
> > out-of-control corporate quasi-monopolies. As far as proprietary
> > knowledge graphs are concerned, I will reiterate: open data is the
> > solution, not the problem.
> >
> > Cheers,
> > Erik
> >
> > [1] See the getValue function in
> > https://en.wikipedia.org/wiki/Module:WikidataIB , specifically its
> > "onlysourced" parameter. The module also adds a convenient "Edit this
> > on Wikidata" link to each claim included from there.
> >
> > [2] As far as Wikimedia organizations are concerned, specific tax
> > policy will likely always be out of scope of political advocacy, but
> > the other points need not be.
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> > wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> > wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
> >
>
>
>
> --
> Katherine Maher
> Executive Director
>
> *We moved! **Our new address:*
>
> Wikimedia Foundation
> 1 Montgomery Street, Suite 1600
> San Francisco, CA 94104
>
> +1 (415) 839-6885 ext. 6635
> +1 (415) 712 4873
> kma...@wikimedia.org
> https://annual.wikimedia.org
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to