What about adopting the use of GitHub milestones for longer-term YASA roadmapping?

[remrama]

GitHub milestones can be used to tag certain Issues/PRs for a target release version and (optionally) date. See examples at Pandas milestones, MNE milestones, matplotlib milestones, seaborn milestones.

Currently YASA forms a checklist of version-specific TODOs in a Roadmap Issue (e.g., #132, #81). I like this approach and want to keep it. It has a major benefit over milestones: it allows discussion. You can't add comments to milestones, but I think talking about the specifics of a version release is useful. But I think the Roadmap Issue and milestones serve separately useful functions.

A benefit of milestones would be to casually add a tag that we think might be farther away, to indicate that the feature is desired but doesn't have any plans for immediate implementation. Like a few times I've thought about some new features but I don't want to spam the Issues or put pressure on the (few) developers actively working on YASA. But I think it makes more sense to post a new feature and tag it with a milestone that might be farther away. For example, right now we are working on v0.7 but I could post some features with a v0.8 milestone tag, implying that we can leave its implementation alone for a while. Or maybe we like an idea but want to wait until v1.0 for it. The milestone tags are highly flexible, we could add/remove as we go. Then when we feel like there is enough steam to work on getting a next version out, we could create another pinned "Roadmap v#" Issue and discuss the details as we've been doing.

I don't want to overcomplicate any current workflows, which seem to be already working well. But what do we think about this?

cc @raphaelvallat

[raphaelvallat]

Thanks @remrama — I did not know about GitHub milestones! I like your proposal, but I am not sure if YASA's current "rate" of feature development is fast enough to justify this. I am also worried about the potential added complexity. My recommendation would be to revisit this after the v0.7 release?

[remrama]

Yup cool that makes sense. I agree the rate is realtively slow right now, which was kind of the motivation; since there isn't a lot of time available for current developers I thought placing a farther away milestone would relieve pressure. But now I see your point that it could defeat the purpose by adding complexity with another "thing" to track.

In the meantime let's leave it aside and revisit as needed later.