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 <[email protected]> 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 <[email protected]>: > > > > 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 <[email protected]>: > > > > 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 <[email protected]>: > > > > 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 <[email protected]> wrote: > > > On Tue, Oct 10, 2017 at 7:31 AM, Andreas Kolbe <[email protected]> > 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: [email protected] > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > > <mailto:[email protected]?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 > [email protected] > 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: [email protected] > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:[email protected]?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: [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[email protected]?subject=unsubscribe>
