But the state I last touched it in, is that there are only 12 PRs left to review in levels 1 to 3. To remind you what those were:
Doc Fixes
Performance Improvements
Runtime Bug Fixes
Once the remaining 12 have been investigated, I feel that things will be in a state that is worth making a build of. Even though this set of bug fixes deals with relatively minor issues, and that it only deals with a subset of the issues that are open against the core packages, I think it would be worth turning it into a release, because this effort has another problem to overcome…
Part of the reason its not very motivating to work on these bug fixes are that we do not have a way to easily distribute the results to users of Elm. That is to say that you cannot simply elm install elm/core and get an elm-janitor bug fixed version installed. It is not worth doing the bug fixes unless we first close-the-loop, with a mechanism to make the fixes easily available.
So my thinking is, get it as quickly as possible to the point where there is *something* to release, so that the focus can shift to the release problem.
As usual, PR reviews will take place with the opportunity to publicly comment on the Incremental Elm Discourse server in the #elm-janitor channel, which will also serve as a public audit log of the conversation, to which any and all are invited to participate.
@jxxcarlson Asked me on Slack, about what are the ways to contribute to this and how it works. My reply is below:
"The way it works is that I collected PRs into a spreadsheet and categorized them. Then within the forks inside elm-janitor/*, I create a branch for each one to review the PR. Mostly they come in cleanly, but occasionally some rebasing required. Generally if its tricky to extract a clean patch, I just comment on the PR and ask the original author to make a clean patch. Then on the #elm-janitor channel on Incremental Elm Discord, I will post a link to the PR to see if anyone has any opinions about it. Is it a good patch? Will it break stuff? etc. Once it is satisfactory, I mark it as such on the spreadsheet. At some point all the satisfactory patches would then get merged into a stack, tagged and made available as a new version with fixes.
I tried hard to document the whole process with a view to anyone being able to get involved with any aspect of it.
Currently only me committing to elm-janitor, but its set up as a GitHub org so that others can potentially join too."
And as for ways that you could contribute if you wanted to, I think these are the best ways in order of value right now:
Submit a PR against an Elm core/* package that fixes something you want fixed.
Raise an issue against an Elm core/* package that fixes something you want fixed.
Write a test for an Issue or PR. There is actually quite a bit of testing stuff already set up on these packages, so often you can hook a test into an existing test set up, and also learn how to write tests against core packages.
Bring to my attention PRs or Issues that should be added to the spreadsheet.
It could be fun to pick an issue that does not have a PR and fix it together.