The Developer Wishlist is a voluntary effort, so its success depends on promoting it to the people can make those wishes true. This might include:
- volunteer developers (many are reachable through wikitech-l; are there other channels that could be used to reach more people without being perceived as spammy?)
- WMF teams (make sure the people doing annual and quarterly planning have heard about the wishlist)
- outreach projects (see which proposals are suitable as Outreachy or GSoC projects and propose them as such; find smaller proposals which might be suitable as microtasks)
- hackathon projects (make sure the wishlist is advertized to the participants)
Outreach/hackathon/volunteer
Top 30 proposals, triaged by appropriateness for outreach/hackathon/volunteer projects
Microtasks
| # | Task | Langauges | Familiarity with | Comment |
| #9 | T123218: Remove IE8 Javascript hacks/workarounds/etc. from extensions | JS | need to grep extensions/skins/vendors and make a task list | |
| #14 | T156788: Improve support for read access restriction / access control | PHP | needs someone familiar with MW authorization to know where to look & make a list | |
Small tasks
(1-2 days for an experienced developer)
Big tasks
| # | Task | Langauges | Familiarity with | Comment |
| #2 | T90687: Define a baseline grid and support a responsive grid system | CSS | responsive design | |
| #4 | T115650: Create an authoritative and well promoted catalog of Wikimedia tools | ? | easy-ish programming task + lots of cat-herding | |
| #6 | T155567: Make OOUI easier to use for gadgets | JS | OOUI, HTMLForm | write a HTMLForm-like descriptor-array-to-form converter in JS |
| #7 | T155473: Improve documentation of OOUI | OOUI | ||
| #12 | T37497: Implement a way to bring GitHub pull requests into gerrit | ? | git, gerrit | |
| #16 | T50826: CodeEditor: Migrate from Ace to CodeMirror | PHP, JS | basic extension writing, editing internals? | |
| #25 | T156231: Customizable templates for core HTML email | PHP | maybe blocked by T128351: Notifications should be in core? | |
| #26 | T156872: Showcase how the separation of concerns should work between MediaWiki API and web | PHP | maybe already exists? | |
| #29 | T147545: Organize a Wikimedia developer contest to recognize and promote best projects | probably needs funding & staff time | ||
Consensus needed
| # | Task | Langauges | Familiarity with | Comment |
| #3 | T71445: Implement a proper code-review process for MediaWiki JS/CSS pages on Wikimedia sites | PHP? | git? | need to decide on on-wiki vs off-wiki solution |
| #11 | T155029: MediaWiki.org: Generate infoboxes from extension.json in git | PHP, Python? | need to decide where to store infobox data | |
| #17 | T156873: Choose a recommended IDE for MediaWiki and maintain a plugin for it | Java? | the chosen IDE | need to pick a target |
| #19 | T107561: MediaWiki support for Composer equivalent for JavaScript packages | JS | package managers | need to pick a tool |
| #27 | T156640: Improve LTS support of extensions | this is mostly about creating policy and getting buy-in from maintainers | ||
WMF
A random pick of tasks (not limited to the first 30) which seem to fit well into the plans of some WMF team:
| # | Task | Team | Why? |
| #1 | T45: Phabricator should suggest possible duplicates when creating a new task | RelEng | Apparently a major usability problem with our collaboration tool suite, so probably affects developer retention |
| #2 | T90687: Define a baseline grid and support a responsive grid system | Reading Web | Would help the plans to make templates mobile-friendly |
| #3 | T71445: Implement a proper code-review process for MediaWiki JS/CSS pages on Wikimedia sites | Security | XSS in gadgets is arguably the biggest security problem ATM |
| #4 | T115650: Create an authoritative and well promoted catalog of Wikimedia tools | Cloud | A catalog is needed for avoiding duplication and helps promote best practices |
| #6 | T155567: Make OOUI easier to use for gadgets | UI standardization | Helps OOUI adoption for gadgets. Users don't care which part of the UI is WMF vs. community maintained, it will still look inconsistent if it's a mix of OOUI an jQuery UI. |
| #7 | T155473: Improve documentation of OOUI | UI standardization | Helps OOUI adoption. |
| Proposals for experimenting with new approaches to documentation (#15 T126500, #23 T101659, #41 T156301) | DevRel | Documentation is something the WM/MW community has not developed good practices for, and this highly affects our ability to draw and retain developers. | |
| #29 | T147545: Organize a Wikimedia developer contest to recognize and promote best projects | DevRel | Probably proposed in the first place because DevRel was interested in doing it. |
| Welcome bot for first-time contributors (#30 T135186, #38 T73357) | DevRel | Developer retention is a major problem, and this seems like low-hanging fruit for improving it. | |
| #32 | T145669: Add support for a wmf-ci.yaml type file for wikimedia jenkins | RelEng | Making the setup of new CI endpoints easy enough that people actually bother to do it would greatly increase the robustness of our code. |