Wikimedia Conference 2018/Program/52

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

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 and testing and using these tools
    • support this community - but also reach out and support the folks that help to manage and dissmeninate 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
    • out reach 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
      • its 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:
      • help 3rd party developers
      • building open sourced software
      • how can we build the technical community without having to know everything
    • outcomes:
      • fix the code documentation
      • fix the recommendation system
      • make installing processes easier
      • more is in the phab ticket
  • 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 didnt'?
      • 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 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 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 - 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 tech about Wikidata - 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)