You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would also send a signal to contributors (and those who will document issues are especially important) that their issue is welcome and is being considered. You can find my own notes on the triage process used for Draupnir here.
The text was updated successfully, but these errors were encountered:
Apologies for the delayed response here. As we've discussed in the SCT Office a few times now, triaging spec issues is something we're interested in doing, but don't have a lot of capacity to work on right now.
As a Spec Core Team we're currently favouring triage for MSCs instead of spec issues, but as we develop the processes and systems it's certainly possible we'll be able to triage spec issues too. We are slowly building a solid contributor base for writing up clarifications to the spec while we work in these adjacent areas too, and appreciate that it's not an easy job to both pick issues to work on and unpick their state at the same time. Noting that it certainly feel like throwing tickets into the void, opening spec issues can help these contributors identify areas of concern to better the spec for everyone. Those issues won't be triaged, but they still provide an idea of where the current problems and fights against the spec's language reside.
Something folks can help with in the meantime is to self-triage where possible. Issues which directly affect the core protocol should be looked at more urgently, for example. This may mean working through implementation conflicts and trying to determine what the "correct" language should be, or going as far as writing a spec PR if particularly motivated. This also doesn't have to all be done by the issue author either - we have quite a few highly capable people in our community who can help drive these issues forward, and it'd be great to see them more active in the space (yourself included!).
Hopefully this provides a bit of context as to the direction and line of thinking, though I've notably excluded timelines from the response here. Truthfully, I don't know how long we'll be working in adjacent/other areas, so don't feel it's appropriate to give any sort of estimate. I do hope that we'll be back in this area soon, though.
Perhaps issues should be triaged so there's some kind of metric for urgency based on relation to how they impact implementers and consumers, and then by missing features etc. Something like https://lostgarden.com/2008/05/20/improving-bug-triage-with-user-pain/
It would also send a signal to contributors (and those who will document issues are especially important) that their issue is welcome and is being considered. You can find my own notes on the triage process used for Draupnir here.
The text was updated successfully, but these errors were encountered: