User:MarkTraceur/Firefighting Squad

Note: this is a unilateral wishlist item from User:MarkTraceur, not affiliated in any way with the Wikimedia Foundation or even really likely to happen in the near future. Mark just wanted to muse about something and thought this would be a good place to do it.

The firefighting squad is a proposed unofficial team of Wikimedia Foundation engineers and volunteer programmers who spend a substantial portion (or the entirety) of their time doing one-time necessary work in extensions and projects related to MediaWiki.

Rationale

There are a lot of gaps in the things that the Foundation engineering department covers. Most of the time those things are harmless, as they wind up being things nobody uses, things that aren't critical to the mission, or things that aren't immediately relevant at the time. Some of that probably has to do with the narrowing focus documents.

But why should narrowing focus mean that we shouldn't cover those things? Yes, we'd prefer for the Foundation to focus on its high-priority goals, but there are a lot of extensions, secondary tools, and bots out there that the Foundation may or may not maintain officially that lack dedicated maintainers.

It would be great to have a team that can be contacted to jump into a project and fix an immediate problem, or just generally clean up, or do review sprints. Basically I'm suggesting that there be a collection of people who dedicate themselves to hacking on immediate problems together, all over the Wikimedia technology projects.

Guidelines

There are a few hard-and-fast rules that I would apply to this team.

1. This is not primarily a Foundation project. The narrowing focus document would almost certainly preclude this from being an official team, but even if it didn't, it would be bad for people to think the monolithic Foundation was trying to build a team that would meddle in everyone's business (mostly because the Foundation isn't monolithic). I want volunteers and employees alike to come together and decide to do this work, together, regardless of whether there's a team in the Engineering department dedicated to doing it with them.

2. Everyone is willing to learn. If someone came into this team thinking that they'd help with one or two things, but absolutely wouldn't be able to help with a Python project (for example), the team wouldn't be as effective. This team would be one of generalists, where everyone helps out with the tasks when they're able, and when someone comes up against something they've never tried before it would be much more effective for them to learn, so they can help a little bit this time and even more next time, as opposed to just giving up.

   However, nobody is required to work on any particular project. While the team would be working on a small number of projects at a time, and it would be good to have some amount of unity and willingness to experiment, if you're too busy to learn Haskell in a particular week I'm pretty sure we'd understand. This isn't an official team, nobody's job is riding on the work we do, so don't worry if you have to take a week off for exams or if you decide that working on your latest pet project is a better use of your time.

3. We only work on projects that aren't formally covered by someone else. If a Foundation employee is actively working on a project, or if a team is already assigned to, and relatively active on, a project, we have to be willing to step off and let them handle it. Assuming good faith is a part of who we are, so let's do what we can to keep it alive.

   However, we will work on active projects in areas that need attention, if it won't disrupt anything. We need to at least consider whether our proposed work would interfere with their normal workflow, but if it doesn't, it would be acceptable to work on a project that needs attention anyway.

4. There will be an upper limit on the size of a team working on any particular project. The people interested in doing this sort of work can grow to infinity, but having too many people working on something at once could be difficult. Approximately five to ten people should be adequate.

Generally interesting concepts

• Review backlogs. When a project has been without any serious review in a while, there's a fire that needs to be put out.
• Unfixed bug backlogs. If a project has critical or annoying bugs that haven't been fixed in a long time, that's something that should change.
• Nasty technical debt. Code crufty after fifteen people with different interpretations of CC and/or the code structure have blown through it? No documentation? Need unit testing? Let's fix that.
• Annoying interface problems. If user-facing feature requests go unresolved for a long time, but the users are all clamoring for a feature, maybe we should give it to them.
• Orphaned projects. You found a cool tool that's been abandoned for a long time that you want to deploy, but it's only compatible with MediaWiki 1.9? Let's fix that.
• Gadgets that could use some love. Gadgets get worked on, but they may or may not get attention from "real" developers very often. Maybe spend some time cleaning them up.
• Doing cool stuff with Lua. The new modules as a replacement for templates are a great plan, but they're so much more powerful than templates. Replacing nasty templates is one possibility, but maybe we could come up with some cooler uses too.

Proposed Targets

Please add things here if you think they would make a good target for this sort of group

• Review backlog for Extension:UploadWizard. This extension suffers from a dearth of good reviewers, and the review backlog is pretty nasty. Hack on review and iteration for a week, and it should be pretty much clear.
• Refactoring Extension:UploadWizard to be a little more understandable. UploadWizard has a lot of complex hierarchies and interactions going on in its code, so it would be good to clear some of that up. A few weeks of heads-down refactoring and cleaning up would be great.
• Ajaxify Extension:OpenStackManager even further. This extension has a lot of actions that take some amount of time on the backend, and it would be great for more of them to use Ajax instead of the normal request/load-page/go-back workflow. This consists of writing API modules to cover existing actions and adding calls to the API in various places, but since the framework for Ajaxification is pretty well laid out, it shouldn't take much time, just a lot of grunt work.
• Make the Orgchart project into an extension. This project is old, it comes from User:MarkTraceur's time as a contractor, and it was implemented before he had a great idea of what makes sense for extensions. Now he thinks about going back and making it work with MediaWiki.
• Make Extension:EducationProgram a little nicer for educators. EducationProgram is a pretty nice extension, but as Ragesoss points out, it uses a lot of hacky template transclusions to accomplish its goals. Maybe we can use JavaScript and/or Extension:GuidedTour to make it a little nicer to create a course.
• Work on some gadgets that need love. Gadgets on the projects can enter cycles of disrepair, so it would be good to pitch in to their maintenance.

Interested parties

Add yourself below and watch this page.

• MarkTraceur (talk) 16:46, 4 June 2013 (UTC)
• Yuvipanda (talk) 14:02, 5 June 2013 (UTC)
• Terrrydactyl (talk) 17:40, 5 June 2013 (UTC)
• — The Earwig (talk) 22:48, 5 June 2013 (UTC)
• – GorillaWarfare (talk) 23:09, 5 June 2013 (UTC)
• Ori.livneh (talk) 20:02, 6 June 2013 (UTC)
• Legoktm (talk) 16:33, 12 June 2013 (UTC)