Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Triage spec issues #1785

Open
Gnuxie opened this issue Apr 12, 2024 · 1 comment
Open

Triage spec issues #1785

Gnuxie opened this issue Apr 12, 2024 · 1 comment
Labels
improvement An idea/future MSC for the spec

Comments

@Gnuxie
Copy link
Contributor

Gnuxie commented Apr 12, 2024

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.

@Gnuxie Gnuxie added the improvement An idea/future MSC for the spec label Apr 12, 2024
@turt2live
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement An idea/future MSC for the spec
Projects
None yet
Development

No branches or pull requests

2 participants