This one is dependent on #460 to be reviewed, but I thought I get this out for comments as well.
Updating the problem-specifications is going to lead to broken templates for a great many reasons, making it difficult to update, especially when it has not been updated in over 3 years.
The strategy here is to automatically regenerate the ones that can update cleanly and pass tests, and mark the ones that failed with .broken.
These broken templates will be skipped during CI, but each one will create an issue in the repository about the problem with potential pointers on how to fix it allowing more people to easily contribute patches to these templates. They would make great first-issue problems.
Currently there are 10 broken templates, some are easy fixes, others require some thinking.
This one is dependent on #460 to be reviewed, but I thought I get this out for comments as well.
Updating the problem-specifications is going to lead to broken templates for a great many reasons, making it difficult to update, especially when it has not been updated in over 3 years.
The strategy here is to automatically regenerate the ones that can update cleanly and pass tests, and mark the ones that failed with
.broken
.These broken templates will be skipped during CI, but each one will create an issue in the repository about the problem with potential pointers on how to fix it allowing more people to easily contribute patches to these templates. They would make great first-issue problems.
Currently there are 10 broken templates, some are easy fixes, others require some thinking.