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

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 thought https://medium.com/@sandya.sankarram/unlearning-toxic-behaviors-in-a-code-review-culture-b7c295452a3c was an interesting article kind of related to this topic

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.

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
   • relevant folks should update https://www.mediawiki.org/wiki/Upstream_projects
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)

In T183318#3920975, @brion wrote:

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.

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.

In T183318#3947123, @Jdlrobson wrote:

#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.

In T183318#3920975, @brion wrote:

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

2. 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.

3. 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 task tag. I personally believe the good first task tag cannot work when many people just throw an good first task 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.

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.