Keep log of project breaking proposals after closing them #10086
Replies: 2 comments 6 replies
-
To make a good start for this, can you please link some of these? I don't recall any being closed by maintainers like that Proposals shouldn't be, and in my experience aren't being, closed just because the proposed change breaks compatibility, they should (and are) marked as breaking compatibility and are marked for 5.0 That's assuming they are viable and good proposals otherwise |
Beta Was this translation helpful? Give feedback.
-
But regardless the solution isn't IMO to track these supposed cases, but to use the 5.0 milestone and not closing them, which is as far as I know policy and how it's generally done However if there's some other reason a proposal is closed, or if the original author closes it themselves, there's no reason to track them If you find some examples of this happening then please link them and they should probably be considered differently, but I haven't found any like that |
Beta Was this translation helpful? Give feedback.
-
A few times now i've seen user proposals closed with:
"Closing, as changing this now would break compatibility with existing projects", and the proposal is closed.
Closing these proposals means they will not be available at the big "window of opportunity" pre-5.0 round table meeting when it happens.
Leaving them open means they bloat the proposal stack.
PROPOSAL: There needs to be some log of these big suggestions that "break existing projects" so they can be given a chance to come through, be discussed at the big meeting when it happens, and not lost in the void.
Beta Was this translation helpful? Give feedback.
All reactions