Wikimedia Developer Support

Looking for a mentor for technical debt cleanup patches

I reckon there are many parts of the mediawiki UI that have been developed years ago and changed little since then. The currently supported browsers offer more optimal solutions in terms of clarity, CPU usage, code length. Recently I’ve done a significant cleanup in the MultimediaViewer project (patchset) that replaces most of the javascript-based positioning with static css among other improvements.

I’ve also done some layout fixes and updates to Vector and Timeless skins in an experimental userstyle, that I’m planning to propose piece-by-piece as progressive improvements to these skins.

I’m looking for some mentorship that introduces me to how to break up such improvement and turn them into patches, how to find reviewers. I have a hard time finding help and engagement from mediawiki developers, therefore I’d like to try this path to getting things done. I appreciate any form of support.

I intend to do more similar cleanups and improvements in the future, to repay some of the technical debt and improve the user experience of the wikis.

1 Like

@Tgr as a developer of MMV could you suggest someone, or give an introduction?

Thanks for trying to improve MediaWiki, @Aron_Manning!

The way to find help depends on the extension. MMV is unmaintained so that will be tough. I think @thiemowmde and Krinkle touch it the most these days. Vector and Timeless have active owners (the Web team and Isarra, respectively) so for those it should be relatively easy to get reviews or feedback; OTOH there might be a stronger product vision that you have to make sure your ideas align to.

In general, it’s always easier to get review on small patches than on large refactorings. Relying too much on JS instead of native browser behavior was a frequent criticism of MMV so a rewrite in that direction is nice in theory, but it would require a lot of testing and sounds like something that might not be easy to break into small patches…

There is an ongoing effort for having a more formal and reliable process for reviewing volunteer patches, but it has not been created yet.

Thank you for the response!

Not easy, but not impossible. In fact, I’ve squashed the commits from my development branch to satisfy the gerrit process. I would prefer to make a well-organized pull request with small commits as customary on GitHub, however the gerrit process is quite the opposite and I still wonder how people manage to get substantial work done with it. Assuming they do… If not, that would explain the technological lag.

Anyway, that’s not going to discourage me, so I wonder how breaking it into smaller patches would be done per gerrit practices. I figured if I make 20 separate patches on gerrit (arbitrary numbers), that would need 20 reviews and result in 20 merge conflicts, even if I manage to pass the tests with each… maybe you have a better suggestion than that.

For clarity: it’s not a rewrite, only a refactoring. The code structure did not change, the dom only at a few leaves.

You can submit a set of small patches on gerrit. They will be reviewed separately, but it’s the same amount of review (less in the long term, since not everything has to be re-reviewed after changes).

Technically how to do that? As separate changes - one commit each -, or one change with a chain of incremental patches, or one change, one patch set with multiple commits?

When you run git-review (or do the git push if you use gerrit manually), it will send all the pending patches in your current branch to gerrit. That’s the easiest way, and also the most useful if your patches are not independent from each other.

1 Like