Open jack-berg opened 10 months ago
One other aspect that I think is missing is the expiration / timeout of issues. If we have no expiration, then issues with deciding:community-feedback
might sit around forever, creating the same backlog that we're trying to avoid. Ditto for accepted:needs-sponsor
. I would suggest:
accepted:needs-sponsor
for at most 3 months, after which it automatically reverts to deciding:community-feedback
deciding:community-feedback
for at most 3 months, after which it is automatically closed (or marked stale and then closed later).If there are more "waiting" states they should all have predefined timeout periods and a downgrade path.
I agree with that. The counter I've heard in the past is that closing issues just hides issues. But having an intractable number of open issues doesn't provide any additional visibility over closing them. I would advocate for adopting a culture where we close issues which are stale and are comfortable re-opening them when they are relevant again.
Overall good, only a minor non-blocking comment:
PRs submitted to address the issue prior to a sponsor volunteering should be rejected.
I've seen this a lot for small corrections and clarifications, and probably we should me more lenient at first? Holding them from merging or blocking while issue & triaging take shape, etc.
I think it's a great approach and very clear workflow. Minor question, I assume a single approver can mark an issue as triage:rejected:declined
and close it, as they understand it doesn't align with the project goals/strategy. If this decision is appealed by the author and re-opened, do we expect a different approver to pick it up, or at least get involved? Trying to avoid personal back and forth between two individuals.
I really liked the proposal, and whatever we come up here, will probably make sense to also use in the semconv repo. I feel a lot of people that contribute to the spec are also contributing to semconv so it would be nice that the user experience across repos is the same.
The collector also has some nice process: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CONTRIBUTING.md#triage-process
We've been doing the new spec issue management process for a few months now; How's it going? Are we good to call this complete?
As of the writing of this (1/10/24), this repository has 646 open issues. The process of submitting an issue, triaging, and making a contribution to resolve leaves a lot to be desired for both authors of issues and TC members who are responsible for maintaining the spec.
I've done some analysis on the process we use today and want to propose a series of changes to rework it.
Problems
area:*
labels seems to capture cross cutting concerns (i.e. api, sdk) wherespec:*
seems to identify the pillar, but these are incomplete and inconsistent.release:*
labels which don't seem to make sense anymore.semconv:*
labels which don't make sense anymore.Proposal
triage:rejected:*
labels defined below.area:*
- Describes the cross-cutting concern(s) of the spec involved in the issue. E.g. api, sdk, exporter, data model, configuration, etc.spec:*
- Describes the vertical(s) of the spec involved in the issue. E.g. trace, metrics, logs, protocol, propagation, etc.triage:accepted:*
ortriage:rejected:*
ortriage:deciding:community-feedback
- See process below for more info.triage:deciding:new-issue
.area:*
andspec:*
labels.triage:rejected:insufficient-info
.triage:rejected:duplicate
.triage:rejected:out-of-scope
.triage:rejected:scope-too-large
, and direct the user to create an otep.triage:rejected:declined
.triage:deciding:community-feedback
.trage:accepted:needs-sponsor
(see details below).triage:accepted:ready
. The may be good first issue candidates.triage:accepted:needs-sponsor
.triage:accepted:ready-with-sponsor
and assign the sponsor to the issue.triage:accepted:needs-sponsor
and remove the assigned sponsor.triage:deciding:community-feedback
(see details above) and remove the assigned sponsor.triage:deciding:community-feedback
need more information about the severity and design proposals to fix. Issues labeledtriage:accepted:needs-sponsor
have an accepted design proposal, but lack required sponsorship. Users are encouraged to comment with their use cases, vote with 👍, and contribute design proposals. Users are encouraged to share issues to solicit feedback from a wider audience.triage:deciding:community-feedback
andtriage:accepted:needs-sponsor
to help inform priority. Spec issue sponsors are encouraged to sponsor issues that the community feedback mechanism indicates have high priority.Outcomes
I hope that by adopting this proposal, we can: