Nice! Is this effort tracked somewhere? What additional features were implemented?
It would be useful to have customizable ticket states. I had the experience that visualizing the ticket flow as much as possible is a good idea.
My main use case is the following: If someone starts working on a ticket, it should be set to in progress. This makes it easy to see whether someone started working on something. It also helps myself to limit in-progress work and focussing on finishing stuff.
Another possible use case (but I didn’t think about it too hard): Ifoutsidersreport a bug, it should be in a state which indicates that someone from the project should triage it. For features, it should be easy to see whether something is just a proposal or it was decided to implement it at some point. Similarly, for bugs should be easy to see whether it was already confirmed or not.
The existing code should be cleaned up and committed piece-by-piece.
- core IR: mainly functions
- helper functions:
- printer and parser with roundtrip tests
- builtin function libraries
Before committing any of the code, a README should be written that explains what the HODG is and why people should care.
Some people may not be familiar with Mercurial and prefer to clone the repository with Git.
Having mirrors on BitBucket, GitHub would increase visibility and make it easier for some people to contribute.