The tracking issue format is inspired by Rust's project management. Unfortunately, I was unable to find an explicit clarification on why they have not adopted the relatively new GitHub Milestones or GitHub Projects formats yet.
IMHO, project management tools beyond (tracking) issues and PRs are overkill and a waste of time in nearly every single-developer side project. However, Stylix is slowly attracting more contributors, and the number of feature, bug, refactor, and performance requests increases likewise. Despite the project having "only" 79 open issues (at the time of writing), it would take an enormous amount of time (in FOSS context) to figure out what overall direction the project is taking due to conflicting or very similar requests. This makes it harder to understand and discuss the overall optimal direction of the project.
I suggest adopting GitHub Projects or GitHub Milestones for Stylix, despite having no practical experience with them yet.
Considering Stylix's primarily rolling release development model, I cannot think of any good examples for using GitHub Milestones, other than major (breaking) changes that end-users and developers may want to look forward to; although it would in most cases merely duplicate the GitHub Projects and waste additional effort in project management. As pointed out earlier, it might be beneficial to replace every currently existing tracking issue with an individual GitHub Project.
The tracking issue format is inspired by Rust's project management. Unfortunately, I was unable to find an explicit clarification on why they have not adopted the relatively new GitHub Milestones or GitHub Projects formats yet.
IMHO, project management tools beyond (tracking) issues and PRs are overkill and a waste of time in nearly every single-developer side project. However, Stylix is slowly attracting more contributors, and the number of feature, bug, refactor, and performance requests increases likewise. Despite the project having "only" 79 open issues (at the time of writing), it would take an enormous amount of time (in FOSS context) to figure out what overall direction the project is taking due to conflicting or very similar requests. This makes it harder to understand and discuss the overall optimal direction of the project.
I suggest adopting GitHub Projects or GitHub Milestones for Stylix, despite having no practical experience with them yet.
A somewhat elaborate comparison of GitHub Milestones and GitHub Projects can be found at: https://stackoverflow.com/questions/39591795.
Considering Stylix's primarily rolling release development model, I cannot think of any good examples for using GitHub Milestones, other than major (breaking) changes that end-users and developers may want to look forward to; although it would in most cases merely duplicate the GitHub Projects and waste additional effort in project management. As pointed out earlier, it might be beneficial to replace every currently existing tracking issue with an individual GitHub Project.