The problem
The repository has no public roadmap. There is no place where a user can see what is being
worked on, what is planned, and what has been decided against.
Why it matters
The open issues already include several feature requests. Without a roadmap, every user who
wants a feature has to open an issue to find out whether it is already planned — and every
one of those issues has to be answered by hand.
A roadmap is also the honest place to say no: "chord export to clip is done", "MPE is
not planned", "Push 3 support depends on X". Saying no once in public is cheaper than
saying it privately five times.
Definition of done
- a short roadmap — roughly twenty lines — visible from the README, listing what is
shipped, what is next, and what is explicitly out of scope;
- it uses the issue tracker as its source of truth (link to open issues and milestones)
rather than duplicating a list that will go stale;
- the README links to it from the top section, where a new user will see it.
Keeping it short is the point: a roadmap nobody updates is worse than none.
The problem
The repository has no public roadmap. There is no place where a user can see what is being
worked on, what is planned, and what has been decided against.
Why it matters
The open issues already include several feature requests. Without a roadmap, every user who
wants a feature has to open an issue to find out whether it is already planned — and every
one of those issues has to be answered by hand.
A roadmap is also the honest place to say no: "chord export to clip is done", "MPE is
not planned", "Push 3 support depends on X". Saying no once in public is cheaper than
saying it privately five times.
Definition of done
shipped, what is next, and what is explicitly out of scope;
rather than duplicating a list that will go stale;
Keeping it short is the point: a roadmap nobody updates is worse than none.