Page MenuHomePhabricator

Wikimedia Developer Summit 2018 Topic: Growing the MediaWiki Technical Community
Closed, ResolvedPublic

Description

Presentation: https://commons.wikimedia.org/wiki/File:Growing_the_MediaWiki_Technical_Community_Dev_Summit_2018_session_slides.pdf

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

  • Session description:
    • Discuss how to grow the MediaWiki community through:
      • Better processes and project management practices, integrating all developers and allowing them to work more efficiently
      • Building partnerships with other Open Source communities on shared interests (e.g. translation, audio, video)
      • Reducing technical debt
  • Session Goals:
    • Prioritized list of recommendations for action items, overview on main challenges, risks, chances in the 3 focus areas
    • Plan for follow-ups
      • People who are interested to work on specific recommendations in the 3 focus areas sign up during the session
  • Structure of the session (rough draft)
    • Intro by topic leaders: Status quo (what are we already doing, main challenges, best practices ...), overview on main questions and focus areas for this session
    • Focus areas (wrap up at the end of each area, and agree follow-ups before moving on)
      • Focus topic I: Making all developers (including third-party and volunteer) a key and efficient part of our software engineering
      • Focus topic II: Build up partnerships with other communities, other open source projects in areas that are important for us today and tomorrow
      • Focus topic III: Technical debt/fragility
    • Future directions (mention other areas that were not part of session)

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

Topic leaders: @Bmueller & @Mattflaschen-WMF.

Session notes:

Please see also the notes of the related sessions:


Post-event Summary:

Action items:

  • ...

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 20 2017, 12:08 AM
Rfarrand renamed this task from Wikimedia Developer Summit 218 Topic: Growing the MediaWiki Technical Community to Wikimedia Developer Summit 2018 Topic: Growing the MediaWiki Technical Community.Dec 20 2017, 12:10 AM
bd808 added a subscriber: bd808.Dec 20 2017, 12:29 AM
Anomie added a subscriber: Anomie.Dec 20 2017, 2:17 PM
debt edited subscribers, added: debt; removed: hey_ok_deb.Dec 20 2017, 5:09 PM
Quiddity updated the task description. (Show Details)Dec 22 2017, 11:05 PM
Quiddity added a subscriber: Quiddity.
Quiddity updated the task description. (Show Details)Dec 23 2017, 12:45 AM
Bmueller updated the task description. (Show Details)Jan 2 2018, 11:55 AM
Qgil moved this task from To triage to Team radar on the Developer-Advocacy board.
Bmueller updated the task description. (Show Details)Jan 8 2018, 4:00 PM
Tpt added a subscriber: Tpt.Jan 8 2018, 5:57 PM
Quiddity updated the task description. (Show Details)Jan 9 2018, 9:25 PM
brion added a subscriber: brion.Jan 9 2018, 9:30 PM
Bmueller updated the task description. (Show Details)Jan 13 2018, 9:20 AM
Bmueller updated the task description. (Show Details)Jan 13 2018, 11:33 AM
Bmueller updated the task description. (Show Details)Jan 13 2018, 12:00 PM
Bmueller updated the task description. (Show Details)Jan 13 2018, 3:55 PM
Bmueller updated the task description. (Show Details)Jan 16 2018, 8:09 PM
Bmueller updated the task description. (Show Details)Jan 16 2018, 8:12 PM
Bmueller updated the task description. (Show Details)Jan 16 2018, 8:14 PM
Bmueller updated the task description. (Show Details)Jan 16 2018, 10:02 PM
Qgil added a subscriber: Qgil.Jan 17 2018, 10:26 AM
EBjune added a subscriber: EBjune.Jan 17 2018, 6:11 PM
Quiddity updated the task description. (Show Details)Jan 17 2018, 10:32 PM
Bmueller updated the task description. (Show Details)Jan 17 2018, 10:40 PM

See my comment at T183319#3908502 , also relevant to "Building partnerships with other Open Source communities on shared interests (e.g. translation, audio, video)".

Bmueller updated the task description. (Show Details)Jan 18 2018, 6:47 PM
Bmueller updated the task description. (Show Details)Jan 19 2018, 1:43 AM
Qgil added a comment.Jan 19 2018, 11:22 AM

Sadly I will miss this session. Some thoughts, in case you find them useful.

When we discuss strategically about growing our technical community, I believe an important point to agree upon is what developer target groups we are talking about, and which priority we should put on each.

Very roughly, we have these groups:

  • 1. Developers contributing to Wikimedia projects in the Wikimedia stack (MediaWiki core, components providing an API, extensions defining the core user experience)
  • 2. Developers creating software on top of the Wikimedia stack with the Wikimedia movement in mind (more extensions, apps, tools, bots, gadgets, templates).
  • 3. Third party developers using Wikimedia APIs for their own purposes.
  • 4. Third party developers creating software on top of MediaWiki for their own purposes.
  • 5. Developers contributing to upstream open source projects used in Wikimedia.

Different types of developers require / respond to very different types of motivations, outreach, onboarding, retention... Usually we focus on 1 and 2 because this is "us" and the people who we interact with more frequently. However, is this the right approach? Also looking at the 2030 strategy?

I'm not challenging the current approach or saying that it is wrong. I just think that it is worth checking current assumptions. For instance, when I see so much emphasis on becoming a Knowledge platform and offering Knowledge as a Service (T183315), I wonder what this will mean in terms of developer outreach priorities and investment. Do we expect the users of that platform / those services to be developers? Are we expecting them to come and help themselves, or should we plan for developer outreach and developer support resources in the 3 category? Also, should we have a more defined plan dealing with 4 and 5 while we build and maintain this platform / services?

I think there's definitely some overlap with the outside-WikimedIa MediaWiki users, many of whom rn some sorts of knowledge bases or internal or external documentation, or folk research on cultural things that aren't Wikimedia centric in how they're treated.

But I also think it's super important to cross pollinate these communities. Tools for onwiki gadgets and templates should be shareable to outside world, and vice versa.

And within Wikimedia world, supporting people with jobs and grants as well as tools is important. Not just for the core platform and maintenance, but for the things people build with it. Free open source isn't just about being free of cost, but about respecting the work others do. Anyway, things to consider in community building and movement planning.

Bmueller updated the task description. (Show Details)Jan 22 2018, 7:05 AM
Qgil awarded a token.Jan 22 2018, 10:14 AM
Qgil updated the task description. (Show Details)Jan 22 2018, 10:19 AM
Bmueller updated the task description. (Show Details)Jan 22 2018, 8:27 PM
Mattflaschen-WMF updated the task description. (Show Details)
brion added a comment.Jan 23 2018, 9:55 PM

Participants -- we need owners for the proposed action items!

  1. reform how we do +2 rights (making it easier to get review done for small exts, etc)
    • <- owner?
  2. fix documentation (better tutorials and entry points for newbies)
    • <- owner?
  3. refactor our recommendation system (better tools than just "easy" tag on tasks)
    • <- owner?
  4. improving install process for devs (installer, vagrant, other?)
    • <- owner?
  5. Make our continuous integration output easier to read/understand (linting and unit testing output)
    • owner: RelEng team
  6. Combine contacts from WMF/WMDE etc
  7. Formal processes for inter-org communications to not be dependent on individual contacts
    • <- owner?

Full session notes at https://etherpad.wikimedia.org/p/devsummit18-growingmediawikitechnicalcommunity

@brion I would volunteer to track the progress with regard to the install process (4)

  1. refactor our recommendation system (better tools than just "easy" tag on tasks)

I'd like to kick this off and start talking to people (engineers, teams).
We will check the notes and add summary and action items (and potential owners) to the task description soon.

I started looking at https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker today again since I got a new computer and wanted to set up a new development environment. The page has many options, but it's not clear how to set up a development environment. Maybe a best practice example in a [digtial ocean tutorial style | https://www.digitalocean.com/community/tutorials] would be helpful. I think a tutorial should cover how to set up a local development environment and how to upload tests to a remote server, i.e. wmflabs.

Bmueller updated the task description. (Show Details)Feb 3 2018, 1:01 AM

How did this go?

I didn't attend but I'm interested in what was discussed.

I see a few key problems in this area:

  1. We are isolated by the technologies we use e.g. Gerrit over Github
  2. Our technology is not attractive.
  3. It takes too much effort to setup a MediaWiki instance that is off-putting unless you have motivation (e.g. you need open source contributions on your resume)
  4. Too much choice

To expand on these a little:
#1
Our insistence on Gerrit hurts us. It's hard to quantify this, but there are many more people on Github than Gerrit. We leave little opportunity for drive-by contributions as we require a developer to prove they want to work with us. One concrete idea - could we allow sign in to gerrit via github/oauth?

#2
while I think our backend stack has matured wondrously, I think our frontend stack is lacking. With many people dropping out of our community, domain knowledge in very MediaWiki-specific code e.g. ResourceLoader is becoming rarer and I know I personally am feeling a pressure with many bits of code that nobody else knows (e.g. MobileFrontend).

To me, it's a problem of scale. There's lots to do, but not so many people to do it. A lot of the developers or would be developers I talk to to try and bring into our movement are completely put off by our frontend stack. Although many of these developers love Wikipedia and what it does, most of these developers are quite rightly motivated more by learning new technologies as this helps their future employment prospects.

Thousands (millions?) of people know how to build things in React.js for example, but very few know OOjs UI. The lack of webpack/gulp and a module loading system surprise them.

I think we can look to Automattic and Wordpres's Calypso as an example of a project working with a similar aged codebase to ours. A lot of this blog post explaining the move resonates with me and our movement. "One of the hardest things to do in technology is disrupt yourself."; "The WordPress codebase is actually incredible in many ways — the result of many thousands of people collaborating over 13 years — but some of WordPress’ greatest strengths were also holding it back." To be clear, I'm not saying we should embrace React.js but I believe we need to think carefully about the tech stack we're using and how that fits in with the communities we isolate (either intentionally or inadvertently).

#3
Most open source projects I contribute to are easy to setup. They usually involve running npm start. If they weren't that easy or I didn't care that much I probably wouldn't contribute. I encourage people to think about the other projects they have written patches for and why they did that and what their experience was like. How is ours different? Ideas that come to mind of ways to help this: what would a MediaWiki without MySQL and an install process look like (a la Calypso could we have an interface that interacted with a production wiki via api)? What would a command line install look like? This desire is what motivated me to allow Mobilefrontend to work[[ https://lists.wikimedia.org/pipermail/wikitech-l/2018-February/089483.html | with production content ]].

#4
Frankly it's overwhelming looking at how to become a mediawiki hacker. Our world is so big it's hard to know where to start. I think this is a problem with most open source projects, where people want to help but don't know where to begin. Rather than dump lots of information on that page, what if we presented it differently e.g. I want to code! I want to get involved with testing! There's not a single link to "existing projects" - should we point people at specific projects such as mobile web/mobile apps. This is where hackathons come in handy and I wonder if we could leverage social media/Reddit AMA a little more to cut through the noise.

I think these 4 things would help grow our community. Our product is awesome and interesting and our community is smaller than it should be.

Aklapper added a comment.EditedFeb 5 2018, 7:44 PM

#1
Our insistence on Gerrit hurts us. It's hard to quantify this, but there are many more people on Github than Gerrit. We leave little opportunity for drive-by contributions as we require a developer to prove they want to work with us. One concrete idea - could we allow sign in to gerrit via github/oauth?

Also see T147864 about Gerrit and OAuth.

For previous "authenticate via X to use Y" opinions / discussions, see T184987, T184986, T169007, T200, T16.

Participants -- we need owners for the proposed action items!

  1. reform how we do +2 rights (making it easier to get review done for small exts, etc)

Also see https://www.mediawiki.org/w/index.php?title=User:AKlapper_(WMF)/Code_Review&oldid=2708265#Lack_of_enough_skillful,_available,_confident_reviewers_and_mergers

  1. fix documentation (better tutorials and entry points for newbies)

I have been working on this for a while now in T169599. I am not a tech writer though, so help is welcome.

For the records: Cleaned up page scopes (such as making How to become a Mediawiki hacker MediaWiki-only/-specific) and improved page structure. Emphasized New Developers by replacing less suitable links (e.g. on How to contribute). New Developers and Annoying little bugs received layout improvements to also work well on small screens.

  1. refactor our recommendation system (better tools than just "easy" tag on tasks)

Same as last year's DevSummit I guess - that was T149564.

Note that we now have https://www.mediawiki.org/wiki/New_Developers in place.

T146960 is specifically about making better recommendations when it comes to the good first bug tag. I personally believe the good first bug tag cannot work when many people just throw an good first bug tag on tasks while ignoring the requirements defined in the description at https://phabricator.wikimedia.org/tag/easy/ .

Another idea was T131706 (mentored tasks). Which I do not recommend if the focus is on getting long-term contributors because of T78639#1932603.

Quiddity updated the task description. (Show Details)Feb 5 2018, 11:53 PM
Quiddity updated the task description. (Show Details)

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

@Bmueller Thank you for organizing your session at the 2018 Dev Summit. Please make sure to document your outcomes, next steps and link to any tasks that were created as outcomes of this session. Otherwise please resolve this and corresponding Phabricator tasks when there is nothing left to do in those tasks.

Cirdan added a subscriber: Cirdan.Jun 4 2018, 7:59 PM
Rfarrand closed this task as Resolved.Jun 26 2018, 7:36 PM
Rfarrand claimed this task.