Call for new maintainer(s)

[deepsweet]

Hi.

My name is Kir, I'm the original author (2012-2016) of SVGO. Current maintainer @GreLI seems to be quite away from GitHub recently and I think it's time to call for new people interested in the project.

With 10M of weekly downloads from NPM I'm not exactly sure how to choose someone and grant access, it sounds like a great responsibility. I'd probably start with reviewing some PRs from a candidate and then maybe a video call. Just want to make sure it's in good hands.

Anyone?

[paulocoghi]

@strarsis is a strong candidate :)

[strarsis]

Yes, I would like to improve svgo as I use it mysql myself quite a lot.

[TrySound]

Hi @deepsweet! I would like to help with refreshing the package and fixing some issues. I already submitted a few pull requests. #1293 #1292 #1291 #1290

[paulocoghi]

@strarsis I just don't understand the mysql term on your phrase. 😄 I'm a little confused xD

[sk-]

In the short term I think something along the following lines should be done, so that users know that the project is indeed not dead and is going to be actively maintained.

• Communicate the plan
• Closing old issues and PRs. I'd close everything older than 2 years. For the rest I'd manually go through it triaging it.
• Create templates for creating issues. For bug reports, require debug information, like version number, options, etc. For questions, redirect users to StackOverflow. For feature requests, ask them to review the new rules requirements (see below) document.
• Review "recent" bug fixes PR pending review, there are a couple of these authored by some of the people who have shown interest on taking over. This could be a good first filter to granting access to interested developers.
• Define some guidelines on what kind of new rules will be accepted, something akin to what ESlint has for their rules. See https://eslint.org/docs/developer-guide/contributing/new-rules#core-rule-guidelines

For the medium term:

• Modernize codebase (Remove support for EOL node versions, maybe migrate to typescript which can be incremental, etc)
• Improve test suite. I worked on downloading a large SVG dataset from Wikicommons, running svgo with defaults options and comparing the rendering of input and output svgs. With that technique I manage to find a bunch of errors.
• Improve documentation

Longer term:

• Audit existing rules. Each rule has its own maintenance cost and probably not all of them are as useful or play nice with the overall project structure.

[lazee]

@deepsweet Thank you for this initiative and for your magnificent work with svgo.

I understand your need to find a trustworthy and good maintainer for this project. Whether that is @strarsis, @TrySound, @sk- (or anybody else) is yet to be seen. Personally, I don't have the time, but I will help with PRs where I can as soon as I know there is a fair chance that it will end up in the codebase.

I agree with all that @sk wrote. I would like to add that it should be kept backward compatible (as there are so many packages that depends on it) and...it would be so cool if the codebase could be split up so that we, somewhere down the road can have Deno support as well ;)

[TrySound]

Hi guys. I'm maintainer now. Feel free to ping me in issues or pull requests.

[strarsis]

@TrySound: Merging these PRs would be nice:

• Add workaround/fix for node v6 selector exception handling #1208 (fix tests)
• refactor svg2js to use txml #1301 (replace unmaintained sax parser with txml parser)
• Add multipass tests #1177 (add missing tests for multipass option)
• Add mergeStyles plugin #1278 (mergeStyles plugin)
• Add dereferenceUses plugin #1279 (dereferenceUses plugin)

[yisibl]

TrySound is an excellent maintainer!