I would like to add more milestones to the compiler repo to better reflect what the maintainers consider high priority issues. We have “Approved”, but this is mainly a grab bag of things which people can implement if they want to.
-
Intend to Implement: maintainers have expressed a good faith desire to see this feature through implementation and release. This may be through implementing it themselves or through mentorship. These should have a maintainer assigned. Some examples might be package awareness, ES6 modules, constraint kinds, existentials, or data kinds. These should be the first place to go to for those looking to see what might be landing in future PureScript releases.
-
Inactive: There are many (many) tickets in the “Ideas” milestone that have not received any updates in many years. Some of them could potentially be useful, but the lack of activity shows that they are not a priority for users or maintainers. I would like to move more tickets to this milestone instead of closing them.
I’m also inclined to remove the 1.0 milestone, since we have not had a discussion about what that means or if it’s a near time or necessary goal. What are y’all’s thoughts?
7 Likes
I’ll also note, that it is not my priority to make a scheduled roadmap. We don’t have the capability to commit to a schedule, but I do want to make some of these issues that we talk about here and there more visible.
I have made the changes proposed above, and also closed out the “Discussion” milestone (moving everything to Ideas). Hopefully this will make it clearer which features are considered high priority by the maintainers.
3 Likes
Removing 1.0 as a milestone until we have managed to set out what 1.0 means makes sense to me. (I do still want to do it.)
I would agree that we should not do a scheduled roadmap, as the estimates would probably both be wrong and a source of stress for maintainers, so not really helpful to anyone. However I think a roadmap is something we ought to have - just without timelines. As I understand it, the benefit of a roadmap would be to give contributors an idea of where the compiler and language are heading, so that they can better predict whether, say, it is worth going to the effort of writing up a feature request, or what kind of PR is most likely to be accepted, or maybe even just whether our idea of where we want the language to be in the longer term matches with theirs enough to justify using it for a project they want to embark on.
2 Likes
I feel like that was my intention with “Intend to Implement”. Maybe we should just rename that to “Roadmap”?
2 Likes
I don’t know, I think “intend to implement” is clearer. I guess my position is that there should be a separate document which actually states these things explicitly rather than leaving people to figure them out by looking at the issue tracker.
3 Likes
I guess my position is that there should be a separate document which actually states these things explicitly rather than leaving people to figure them out by looking at the issue tracker.
I strongly agree. I found this thread while trying to figure out what’s on the PureScript roadmap.
2 Likes
Should there be any sequence or prioritization included in this roadmap beyond the next release milestone and Intend to Implement? For example, could ES Modules be added to a 0.15 milestone? Otherwise it’s tough to know without digging that ES Modules will likely happen before, say, Constraint Kinds.
1 Like
ES modules will likely be in 0.15.0, yes, so perhaps we should add that milestone. We’ve added a deprecation warning to 0.14.0 for primes in foreign import values, since primes are invalid in names of ES module exports, and there is an open PR for ES modules themselves. I don’t know when we might expect constraint kinds to happen.
2 Likes
I think that having a prioritization is important for a roadmap, as it helps contextualize when something is going to happen (in relation to other items on the roadmap, not in terms of a set time).