Wikimedia Conference 2018/Program/52
52. Technical Engagement: creating a plan to engaging and empowering our technical communities
[edit]How to move forward
[edit]- What was this session about?
The session aimed at raising awareness among affiliates of the emerging Technical Engagement program with discussion on what communities already did to support technical contributors.
- What are the next steps to be taken?
Discussion to be continued at Wikimedia Hackathon 2018.
- Photos
- Slides
- Speaker(s)
Alex Stinson, Birgit Müller, Bryan Davis
- Length (min)
60
- Audience / Target group
Technical contributors, affiliates interested in supporting technical contributions, anyone interested in improving our technical communities
- Session Format
Roundtable / audience Q&A
- Description
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:
- help 3rd party developers (phab:T183312)
- building open sourced software (phab:T183319)
- how can we build the technical community without having to know everything (phab:T183318)
- 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)
Materials
[edit]- Notes: https://etherpad.wikimedia.org/p/WMCON2018-technical-engagement-plan
- Slides
- Post-it notes by folks that attended the session:
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 |