Page MenuHomePhabricator

Wikimedia Developer Summit 2018 Topic: Advancing the Contributor Experience
Closed, ResolvedPublic

Description

Participants, please read/think about/research these, ahead of time:

  • Session description:
    • This session is about how people participate in the creation of our works of knowledge. Lowering barriers to entry, while expanding on the knowledge we serve. To do so inclusively and resiliently.
    • Topics that likely will come up in this session are:
      • Structured discussions
      • Collaborative editing
      • Content other than our traditional encyclopedia
        • sister wikis, news content, wikisource, wikivoyage
        • oral history
        • video, topology, statistics creation and consumption
        • creating trust in content without access to newspapers
        • copyright violation detection
      • Metadata
        • Adding annotations to content
        • Location info
        • Categories, banners, pageimages etc.
      • Privacy and safety for contributors and readers
  • Session Goals:
    • Determine if we need new forms of distribution and what priority should these have
    • Identify the most valuable tools we can provide to contributors and what we need for those
    • Do we prioritise Wikipedia type content or other types of content ?
    • What are the smallest technology investments we can do, with the biggest returns ?
  • Pre-event questions for discussion
    • The strategic direction statement opens with this sentence: "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge, and anyone who shares our vision will be able to join us." For the latter part of this statement, does this simply mean others can join us if they do things our way? Or does it mean the MW system will evolve to allow for others to participate and contribute using different systems? For example, if people want to contribute via videos or forums (message boards), will MW handle integration of that content?
    • Some of the submissions for this topic talk about changing to a decentralized, distributed architecture. Some submissions talk about how this would enable remote or censored users to contribute to a secondary server and their revisions would be synchronized into the primary database. One submission talks about using a data pirate's approach. I think even this submission is related to a distributed architecture. This ability to synchronize multiple servers is a common theme. Can and should MediaWiki support multiple distributed servers that can synchronize asynchronously?
    • It seems like many of the other submissions are centered around transforming the way we communicate the data in Wikipedia and the way we communicate about Wikipedia. These topics include real-time collaboration (like etherpad), yet another discussion page tool (Extension:Structured Discussions), git-like features (forks, branches, etc), and social tools (find people who know about the same topics as you to collaborate). A lot of these talk about non-encyclopedic formats and structuring the data in a way to allow for new interfaces and experiences. Are these ideas in conflict with "What Wikipedia is not"? Should we challenge some of the "rules" on the What Wikipedia is not page? In order to consider these new approaches to knowledge sharing, should that encyclopedic stance evolve?
    • Should we challenge the assertion that Wikipedia is the "sum of all knowledge"? Currently, Wikipedia does not allow for tutorials or guide-books. So one can learn about the basic concept of an automobile starter, but one cannot learn how to change the starter on a 2016 4Runner. For that, they have to go to YouTube or message boards. So it seems Wikipedia is currently only "some of all knowledge". Should MediaWiki evolve so it can integrate all these different knowledge formats into a single knowledge portal?
    • The title of our session is "Advancing the Contributor Experience". Is our goal to make things better for those already contributing? Or are we trying to make the experience of contributing better in the hopes of enticing new contributors? We really need to ask "who is not contributing and why?" Some research has been done, but has it all been put to use?
    • As a viewer/consumer, when we want to know something we typically start with Google and Wikipedia. But if we don't find the answer there, we'll search YouTube, message boards, and stack exchange sites. So we should really think about what content is in those videos and message boards and why those people didn't post it to Wikipedia.
    • Let's say someone learned something and wants to share it. As a contributor, they might first think to share it on Wikipedia. But Wikipedia only wants it if it's "encyclopedic". There are other wikis and there is Wiki Data and Commons, but a casual user might be intimidated and not know where to add their input. So the natural progression is to post a video on YouTube or to make a post on some message boards or a stack exchange site. Maybe it's just the "formal" feeling of Wikipedia compared to other online media. Is there potential opportunity to pull in more Wikipedia contributors if Wikipedia's interface and system had some of the attributes of YouTube and message boards? What is the overlap between Wikipedia contributors and YouTube or Stack Overflow contributors?
    • How do we deal with the ever increasing complexity by doing more and more, and the effects this complexity has upon our contributors
    • Contributors seem to want to do a lot of experimentation with 'knowledge', but often seem stuck in current forms of our projects and/or the inabilities of our platforms. how can we meaningfully help them ?
    • Going back to the submission papers for this topic, which of these ideas do we think would actually entice contributors to other web resources to begin contributing to Wikipedia? Which of these ideas would appeal to the YouTubers, the Stack Overflowers, the message board posters, and the bloggers?
    • Our technology influences the people that work with it. How do we responsibly steer this 'social' impact we make.

Session notes:


Topic Leaders (@Darenwelsh @TheDJ), please

  • Add more details to this task description,
  • Coordinate any pre-event discussions (here, IRC, email, hangout, etc),
  • Outline the plan for discussing this topic at the Developer Summit.
  • Optionally, include what it will not try to solve.
  • Update this task with summaries of any pre-event discussions.
  • Include ways for people not attending to be involved in discussions before the summit and afterwards.

This is one of the 8 Wikimedia Developer Summit 2018 topics.


Post-event Summary:

  • ...

Action items:

  • ...

Event Timeline

Rfarrand triaged this task as Normal priority.Dec 20 2017, 12:07 AM
Rfarrand created this task.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 20 2017, 12:07 AM
Reedy renamed this task from Wikimedia Developer Summit 218 Topic: Advancing the Contributor Experience to Wikimedia Developer Summit 2018 Topic: Advancing the Contributor Experience.Dec 20 2017, 12:07 AM
TheDJ added a subscriber: TheDJ.Dec 20 2017, 10:36 AM
Anomie added a subscriber: Anomie.Dec 20 2017, 2:16 PM
debt edited subscribers, added: debt; removed: hey_ok_deb.Dec 20 2017, 5:10 PM
Quiddity updated the task description. (Show Details)Dec 23 2017, 12:53 AM
ssastry added a subscriber: ssastry.Jan 3 2018, 3:53 PM
Tpt added a subscriber: Tpt.Jan 8 2018, 5:58 PM
Quiddity updated the task description. (Show Details)Jan 9 2018, 9:27 PM
Quiddity added a subscriber: Darenwelsh.
brion added a subscriber: brion.Jan 9 2018, 9:30 PM
Darenwelsh updated the task description. (Show Details)Jan 12 2018, 12:26 AM
TheDJ updated the task description. (Show Details)Jan 12 2018, 10:12 AM
TheDJ updated the task description. (Show Details)Jan 15 2018, 10:20 AM
Quiddity updated the task description. (Show Details)Jan 17 2018, 10:36 PM

These are great starting questions for dialogue... I don't have time to dig into the meatier questions right now, but I did want to add something to this point:

As a viewer/consumer, when we want to know something we typically start with Google and Wikipedia. But if we don't find the answer there, we'll search YouTube, message boards, and stack exchange sites. So we should really think about what content is in those videos and message boards and why those people didn't post it to Wikipedia.

On the ground research done through New Readers and the movement strategy both showed that many people (especially the younger generation) are preferring YouTube and other multimedia content for learning. Some of them even go straight to youtube.com rather than through google, which means they may never find Wikipedia content. I'm not 100% sure if that's captured in the final reports, but it is something we saw on the ground quite a bit.

As media habits change, that's influencing education structures as well to meet changing student needs/norms... I don't think we can expect the general population to be committed to long-form text forever. I'm interested in exploring what implications this has for us.

TheDJ updated the task description. (Show Details)Jan 21 2018, 7:20 PM
TheDJ added a comment.Jan 21 2018, 8:30 PM

Some of my own ideas:

We need to lower the barrier to entry
Because:

  • We won't find many new long form prose writing editor than we have now
  • To avoid them vs us culture
  • There are editors out there that we are not using but now have to spend too much time to do anything meaningful

By making use of:

  • Making the steps between starting users and advanced users, smaller, simpler, more logical and transparent.
  • Make sure registered users and unregistered users both get equally responsive experience
  • Lowering the cost of participation (think databundels). This is why offline content distribution is more valuable than distributed right now.
  • Micro contributions

We should use more external content

  • but how do we make sure our communities keep the control they ask for (see inefficiencies with using sisterproject and osm content in wikipedia)

Because

  • just as with development, "not invented here syndrome" is a thing in content production too
  • it makes us more flexible and content agnostic
  • We can use the flexibility a content partner has in innovating, instead of slowing ourselves down burden on us (KaaS)

Using

  • iframes
  • make standard for revisioning external content
  • whitelisting per community vote
  • pending changes for external content

Adding infrastructure for Micro contributions

  • mostly by way of asking to help to filter and judge content and content suggestions
  • for: wikivoyage banners, page images, mix n match, adding location info, report a content problem, fair use review, speedy deletions etc.

Because:

  • New form of editing, which will allow a new group of editors to participate
  • Can be supported by computers and algorithms and thus scales
  • Already done with less efficient manual
  • All history and infra is now outside of the project in wmflabs

Using:

  • some form of queues and labels.
  • supergood import and export functionality
  • the less opinionated the more flexible and the better

Appification
Because:

  • People have very differing workflows and needs, and the more information we have to present, the harder it becomes to not be overwhelming yet, efficient
  • we need to make it easier to create customised, more targeted, experiences for the website, allowing people to optimise their workflow and consumption
  • we need this to be a first class citizen, instead of living on wmflabs, or as windows only apps (AWB), or badly maintained gadgets, or 2 year MediaWiki betas, WikiWand etc.

Using:

  • Special pages + Gadgets + api's + ui toolkits on steroids / browser extensions
  • Strong versioning
  • Entire frameworks for things like the watchlist
  • JS only

Moveable Discussions
Because:

  • discussion dies with lack of participation and thus should be easier to centralize

Using:

  • Tags, like 'talkpage', 'afd forum', 'helpdeks' automatically exposes topics in multiple locations.

Scoring users
Because:

  • Expectation management on the interaction between editors, which is good for safety and stress levels
  • there is no penalty for bad behavior right now other than blocking. Since blocking is extremely rare among long time contributors, that means that bad behavior doesn't have consequences for them. This puts beginning users to serious disadvantages at times.

Using:

  • Editor karma (many possible ways to implement that)

Offline content:
Because:

  • transportation cost is low
  • good way to expand reach across the globe
Qgil awarded a token.Jan 22 2018, 10:41 AM

Many things like "structured discussions" might be less a problem of building them but more of acceptance in communities. So I wonder how we can bring this dimension in. It seems very non-dev first, but I think many technology decisions are strongly influenced e.g. by not needing to cut old ties because it will make people unhappy (for plausible reasons).

A point that we we're talking about it and probably should take into the discussion – T89970: Enable microsurveys for long-term tracking of editing experience

Quiddity updated the task description. (Show Details)Feb 5 2018, 11:52 PM
Quiddity added a subscriber: Quiddity.

For your watchlisting/cleaning/discussion interests the etherpad notes were copied to https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018/Advancing_the_Contributor_Experience

Rfarrand closed this task as Resolved.Jun 26 2018, 7:36 PM
Rfarrand claimed this task.