Description
Hey! 👋
I would like to talk about the maintenance and the future of the project here.
I thank @mstruebing, for trusting me as a maintainer of editorconfig-checker. I try to be involved where I can help (mostly really https://github.com/editorconfig-checker/editorconfig-checker.javascript), but can't help when it's not my area of "expertise".
Thankfully, mistakes are cheap, and can often be quickly fixed/reverted. Recently a PR, I approved and merged (sorry 😓), introduced an unexpected behavior for some users: #350, and have been reverted and released quickly.
Honestly, editorconfig-checker is a really stable software to me. Even if it has a fairly amount of GitHub issues open (49 issues open as 31/08/2024) for completely valid use cases of features and bugs, it works in most scenarios, it doesn't really need much active development with daily bug fixes or features from a maintainer (if no one wants to do the work). That's the magic of open source, where the community can participate, and maintain the project alive.
But at the same time, it still needs maintainers (with Go skills) to review PRs from the community at least. And make releases. Also there have been discussions about wrappers here: #362 (comment) (which I hope we can discuss in a separate issue before doing any actions, because I'd rather have the wrappers part of the core org as it is today).
Also, @mstruebing commented about how the release process is "a mess" and should be automated/easier, here: #353 (comment)
To me, the next steps for the projects, to maintain it alive are:
- Find maintainers willing to review PRs and issues
- Have a clear documentation for releases (+ easier/automation while maintaining security), when do we make releases, semver explanation to what we consider BREAKING CHANGES (as explained here: Check if multiple newlines are at EOF #350 (comment)), how to make releases, etc.
- Maybe for easier onboarding of new maintainers, and to talk about the maintenance of the project, we should find a easier way to discuss about it, maybe GitHub discussions is suited for that or Discord? (I don't feel like creating a "meta" issue like this one, each time for talking about the project in general, but at the same time, it should be better to do the discussions in public, so Discord might not be the right choice).
- Some PRs are awaiting reviews and we might release v3.1.0 containing: feat: add zip version when compressing all binaries (#321) #362, feat: consolidate adjacent error messages #360, feat: editorconfig-checker-disable-next-line #363
Concerning me, I will be happily opening PRs for creating Markdown docs inside this repo to talk about the release process, help to onboard new maintainers, and participate in discussions and issues. But I fear, that I don't have enough knowledge of this repo, for making a easier release process here, or to review implementation details of PRs in the Go programming language.