What is the policy on tracks marked as “unmaintained” on GitHub? I know that CFML isn’t a particularly busy/popular track, but I have had some good experiences with this language and would be sorry to see the track die of neglect.
I think (without total confidence!) that I have some of the right background to help with this, and could probably learn more as needed. Not to dive in and write an analyzer or representer from scratch, but at least to fix some broken links in the documentation, add more exercises, clean up problems with local testing, review PRs, etc. What is needed for a low-traffic track like this one?
And for anyone tempted to suggest that MIPS Assembler would be a higher priority: no, I certainly don’t have those skills!
P.S. I realize that there is a wider issue around maintenance, and when/how to end the current freeze on community contributions. I don’t need an immediate answer.
Unmaintained tracks won’t die. They’re basically just, well, stale. And for many tracks, that’s perfectly fine as the language itself is very stable (infrequently updated).
As for CFML in particular, were you planning on contributing things to that track?
Dealing with a general air of neglect seems potentially useful? As low-hanging fruit, I’ve fixed broken links to the most useful documentation in PR #179. It auto-closed but can be reopened by somebody, sometime. Having broken links in the “how to get started” pages is particularly unwelcoming to new users.
There are problems with the test runner that merit discussion. I’ll start a new thread specifically on that issue, as it may not be simple.
And @ErikSchierboom, I’m fine with the fact that this clearly can’t be in your top 500 priorities just now. I’m mainly trying to put down placeholders for things that will need fixing later, if/when everybody has chance to breathe.
@colinleach I’m happy to be tagged in some PRs, as long as you’re okay with me not responding to them immediately. Cleaning up the track would be lovely!
1 Like