AW: Managing issues

Spontaneously, I have already spotted 2, 3 issues in the proposed list that I would like to see in 4.0 (even if they fall in the NotEssential category), so the interesting question could be who will decide which issues should be subject to deferral. In principle, all issues could be closed and reopened once someone writes a proposal…

As 142 is just a number, my preference would be to keep NiceToHave features open and to decide later whether to prioritize their adoption or drop them. Next, if we introduce a new label, we could drop ProposeForV4.0, because I assume it would apply to all remaining issues.

Concluding, I fully agree that pull requests and tests are essential for finalizing the requested features.

________________________________
Von: Norm Tovey-Walsh
Gesendet: Mittwoch, 15. Mai 2024 11:00
Bis: Michael Kay
Cc: public-xslt-40@w3.org
Betreff: Re: Managing issues

Michael Kay <mike@saxonica.com> writes:
> I'd like to propose that we introduce a new status "Deferred" (or perhaps "Long Grass") for issues where we think it's a nice idea, but we believe that a 4.0 specification would be viable without it. Basically, anyone is welcome to raise a concrete proposal to implement the feature (preferably with tests!) but unless they do so, we'll ignore the issue.

In the context of setting an agenda for the face-to-face, I plan to ask if the group thinks we’re ready to turn the corner from “let’s keep designing” to “let’s start trying to finish”.

(In practice, I expect the answer is “no, not yet, couldn’t we just…first?” And that’s probably fine. Asking the question is just the first step in trying to get consensus to begin looking towards the finish line.)

Finding a way to move some of the ~142 open issues “off the table” is a good idea.

> They will appear on the GitHub list as closed issues rather than open issues.

That implies not *just* tagging them, but also closing them. I think that’s a good idea too, but I won’t be surprised if there’s some pushback.

I think if we aren’t going to do them now, closing them is the right answer. (Alternatively, we could create a “qtspecs-vnext” repository and move them there, but in my experience that actually makes them *harder* to find, so I prefer tagging and closing them.)

It’s worth remembering that it’s easy to find the closed, tagged issues, so nothing is being lost. And if you write a PR for a deferred issue, it’s easy to reopen the issue.

> I would stress that moving an issue into this category doesn't mean we have decided not to do it. It means that we have decided we don't absolutely need to do it, and we intend to take no further action unless someone picks up the work and volunteers a concrete proposal.

:thumbsup:

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica