Jump to content

Wikimedia Conference 2018/Program/52

From Meta, a Wikimedia project coordination wiki

52. Technical Engagement: creating a plan to engaging and empowering our technical communities[edit]


Alex Stinson, Birgit Müller, Bryan Davis

Length (min)


Audience / Target group

Technical contributors, affiliates interested in supporting technical contributions, anyone interested in improving our technical communities

Session Format

Roundtable / audience Q&A


Discuss first steps and longer term plans for changing how we engage with our volunteer technical communities and 3rd parties who use Wikimedia APIs and software.

A brief introduction to FY18/19 plans at the Foundation and additional initiatives/efforts followed by a roundtable discussion open to input from the audience on additional areas that should be considered for a longer term plan to help people create and use software that advances the goals of the Wikimedia movement.

Desired Outcome
  • Awareness of the emerging Technical Engagement program at the Foundation among chapters and affiliates
  • Awareness of other existing initiatives led by affiliates
  • Awareness of the importance of building networks and getting synergy between all of our efforts
Next Steps and Milestones
  • Continue discussion at Wikimedia Hackathon 2018
  • Continue discussion at Wikimania 2018 (no talk currently submitted)
  • Prepare longer term plan for expanding the program and present to Foundation and community

Session notes[edit]

  • Introductions (Bryan, Alex, Birgit)
  • Bryan:
    • We want to talk about all this because it's part of the 2030 strategy: Knowledge as a Service
    • The we is not just WMF, not WMDE, not just the community - it's all of us - we're full of great technologists, about 2,000 tools on Toolforge with 1700 maintainers, etc.
    • We don't have enough folks to help in this effort - especially when we expand
  • comment: Google teams are much bigger, for example, we think there are 1700 people just working on Knowledge Graph
  • comment: we need to keep this all available to all people (not those that just make money from it)
  • Bryan: one of the tech barriers - finding out how to use the tools we have today. Some of our tools:
    • action API - adding and pulling content from wikis
    • REST based services - uses the MediaWiki API
    • WikiData Query Service (WDQS) - takes data and puts into a graphing system
    • dumps: data dumps that anyone can use
    • event streams - real time feeds of edits across the wikis (poopipeedia, poop bot, etc)
    • analytics tools - page views tools, user views
    • wiki replicas - real time copies of the databases that bots can use
    • gadgets, Toolforge, mediawiki extensions, etc
  • comment: wikiscience and social media are tools we don't yet have
  • Bryan:
    • if we can expand our tech outreach
    • increase knowledge equity (into more languages than just English, etc)
    • collective outreach efforts (movement wide)
    • add resources to our movement with grassroots solutions
  • FY18/19 plans (in the Wikimedia Foundation Technology department)
    • adding new capacities to help with these initiatives
    • adding a Developer Advocate role
      • someone with good communication skills with humans and computers
  • adding a new Technical Documentation role
    • job focus is to be sure that the documentation that we already have is *good* documentation
    • also adding in new tips, etc for how to do things
  • Alex:
    • coming here as a user that needs to use these tools, advocate for other features for additional tools and work that needs to be done
    • finding the right people to bridge technical and community folks to speak the same language
    • #1LIB1REF campaign: a conversation piece - why Wikipedia and why Wikimedia
      • citation tool [citation needed] - good for those with research skills
      • hashtag tool - showing the value of tracking of the work -- tracking the work by using hashtags
    • these tools were mostly made by community contributors to solve certain problems
      • didn't have a testing audience, although
      • pushed these tools out by social media to get more people looking, testing, and using these tools
    • support this community - but also reach out and support the folks that help to manage and disseminate these tools
    • Structured Data on Commons: this was a very specific investment for GLAMS and others - to not be too overbearing and not too complicated
      • working with end users and developers - collaborative effort
      • want to be sure we don't break any existing tools (batch upload, etc)
      • who are the tool builders, which tools are the community relying on most
      • give the other tool builders support when the new SDoC tools are released
    • we need to help the technical contributors to understand and help support the needs of the community
    • libraries and cultural organizations really want tools like this - to help them use Wikibase
    • we might need to start anticipating the needs of the external community
    • outreach and deployment is a good way to help build the technical community
  • Birgit:
    • traditional chapters organize meetups, edit-a-thons
    • we're different at WMDE - we are developers, we have it in the annual plan - to test and evaluation new tools to support and strengthen the ties with the technical community
    • IRC office hours (online and on a regular basis) for WMDE and the tech community - helping connect community with developers
      • sometimes lots of folks show up, sometimes no one does, but there is always at least one person from WMDE
    • this type of outreach works for us, since our resources are small
    • also try to give the tech community 'easy' tasks that can be done (phabricator) by volunteer developers that don't need to know the entire backend, just simple stuff
      • small tasks
    • organizing documentation sprints at gatherings like Hackathon
    • Wikibase users - finding out what they need to help and to improve the software for everyone
      • it's sometimes hard to show non-tech persons why we need a robust backend and software
      • we need more people in the network to help out - otherwise burn out and lack of folks to write code and documentation
    • Developer Summit (DevSummit) - conference, we asked — how can we:
    • outcomes:
      • fix the code documentation
      • fix the recommendation system
      • make installing processes easier
      • more is in the phab tickets
  • Bryan:
    • we have an hour for this session, we didn't want to just ramble on... :)
    • for the second half, we have a few questions that we want to ask the room and get some ideas on future work, discussions to round out our strategic plans
    • question: if you or your organization - have you ever done an intervention to help technical contributors? Yes - many hands raised
    • is there at least one example of what worked and what didn't?
      • Question/comment: organizing the hackathon that focused on MediaWiki, the challenge was that we didn't get a lot of developers that focused on open sourced software...is there a way to find more developers that are interested in open sourced software?
      • Bryan - part of the intent of having a developer advocate is to be the go-between with the community and developers, not strictly to find more developers.
      • Comment: we had a community volunteer that did a great job, so they hired them!
      • Comment: outreaching to 3rd-party community: we held a hackathon to develop documentation, hard to get it translated. the documentation is written in a very high level of technical detail - it was hard to translate into German. We need more staff to help with the documentation
  • Brainstorming activity
    • what support / resources do you need to plan technical projects or to better support technical contributors? (avoiding burn out, etc)
  • Toby:
    • What support and resources do you need to plan technical projects or to better support technical users
    • Not clear how to get technical projects into Wikimedia
    • Answer: Community wishlist proposals
    • User groups don't know where to turn to find developers
    • How to bring product managers to the wikimedia community
    • Asaf went to India to teach about Wikidata and other tools - outreach around technical projects (how do you find technical people and tell them what you want?)
  • Sati: How do you report a bug (phabricator)
    • how to find bugs or categories
    • what do you do next when you find a bug?
    • how do you craft a technical need when you're not technical?
    • having a trans-wiki tool library? (Toolhub project that James Hare is working on)
    • onboarding documentation
    • existing resources: in the instructions in a task, there's a lot of assumed knowledge, a gap in knowledge between developers and writers of bugs
    • understanding the boundaries of what is a WMF issue and what is a WMDE issue?
    • how do you navigate working with the WMF?
    • how to propose a new idea for a problem you have (a technical issue)
    • how to find collaborators with your skills
  • Maria:
    • as a developer - what is the problem I'm supposed to solve?
    • how do i make this agile?
    • mediawiki is old - core tech is old
    • language - nothing shared, or an understanding on how to navigate
  • Daniel:
    • communication problem between developers and community
    • writing actionable user stories so that devs can put into tasks
    • better structure in findable documentation
    • environments for developing and testing code
    • timely code reviews (nearly impossible for community members)


Transwiki catalogue of technical tools Gap between Wikimedia community and technical experts Need for product managers as a bridge between users and developers Getting code reviews
Boundary between WMF projects and volunteer projects Link between Phabricator/MediaWiki and Wikipedia Official tech help switchboard Writing actionable user stories and tasks "x-y problem"
Onboarding, documentation A good interface improves contributions to projects How to bring product managers to the Wikimedia community? Need collaborators for developing Lua modules to import Wikidata into Wikipedia
Unclear as to how to integrate technical projects with Wikimedia User groups don't know where to go to find developers Mediawiki is old software (core is old) Communication standards, shared languages to talk about tech
Environment for developing and testing (local and public) Projects can be divided into chunks (agile process) Understand what is the problem to be solved? How to propose a new idea or problem
Better structured / findable documentation How to talk to developers if you're not a developer Navigating WMF if you need SMT Terminology, language, miscommunication (a problem on both tech and non-tech sides)
There is a lot of assumed knowledge in task instructions that need to be reverse engineered High barrier to entry to Phabricator (how to report bugs) The communities don't always know what our own needs are and who can fulfill them, where can we report bugs Community wishlist proposals put forward and selected around December
Wikimedia community needs to physically go to communities to teach technical topics like Wikidata and to get technical support