User:Novem Linguae/Essays/Gadget learning curve

Interested in writing patches for or becoming more involved with enwiki gadgets? Here's some of my observations about the process.

Difficulty levels

Bug fixing is easy. Reproduce it, add your debugger statement, then step debug until you figure out what's going on. Then submit a one-line or couple line patch.
Small features are medium. You might have to write your own API call, or figure out some of that gadget's utility functions.
Big features are hard. You'll definitely have to master that gadget's utility functions and way of doing things.

Skills and permissions needed

Writing patches

coding
- Front-end languages
  - JavaScript
  - HTML
  - CSS
- jQuery
- MediaWiki Action API & Special:ApiSandbox
- MediaWiki utility functions - mw.config.get, mw.util, mw.Title, etc.
- that gadget's custom utility functions and way of doing things (e.g. Twinkle's Morebits)
other
- ability to follow README.md directions to get a localhost environment working
- Git - committing, pushing, pulling, merge conflicts
- GitHub - forking a repo, syncing your repo with master, opening a pull request, rebasing

Becoming a maintainer

merging pull requests
- collaborator access to GitHub
- making sure controversial patches have consensus by double checking on talk page
deploying
- interface administrator access on enwiki
- debugging and running custom deploy scripts (1, 2), often in non-MediaWiki languages (Perl, Python)
- writing work instructions on how to deploy (1, 2)
- be available for a couple days after deploying in case a hotfix is needed
bug wrangling (making sure everything gets into the issue tracker)
- translating talk page requests into GitHub Issue tickets
- tagging frequently requested tickets with "frequently requested"
- tagging easy tickets with "easy"

Things to watch out for

Old gadgets are often written in JavaScript version ES5, which is the version from 2009–2014. This style has zero classes, tons of old jQuery (things like $.Deferred, $.each), and tons of promises. MediaWiki only recently started allowing gadgets written in ES6, and the years of disallowing ES6 have contributed a lot to technical debt.
Gadgets usually have few or no automated tests, making refactoring dangerous.
Program code is just fragile in general. Even with manual testing, touching anything is likely to create bugs.
No maintainer means you may work on a repo and not get code reviews and patches merged for weeks, months, years, or ever. You may have to become a maintainer and self-merge your patches.

One strategy

One strategy that's working for me (when I have the free time) is I'll pick a repo, then spend about 2–3 weeks working on it. I'll knock out these 3 things, then move on to the next repo:

writing patches for all tickets with the "easy" tag
writing patches for all tickets with the "frequently requested" tag
clearing the pull request queue by providing reviews for other people's patches (usually just making the changes for them then merging, because it'd be ridiculous to expect someone to come back and modify their patch after waiting for months or years)

Conclusion

That's a lot of different skills to master. It's no wonder there aren't more volunteer devs. And it's no wonder that even popular gadgets often become unmaintained. It took me years to cross off all the items on this list.