Define specification sponsor and seed with spec approvers #2070
Conversation
|
cc @open-telemetry/technical-committee |
jack-berg
requested review from
alolita,
austinlparker,
danielgblanco,
dyladan,
jpkrohling,
mtwo,
svrnm,
tedsuo and
trask
as code owners
There was a problem hiding this comment.
Looks good.
Also confirming that I am still interested in continuing. (As I was part of spec-metric-approvers, and hence part of the seed list for spec sponsor)
This PR seeds the spec sponsor pool with the existing spec approvers, but this is a good opportunity to check in with the current spec approvers to make sure they're aligned with the privileges / responsibilities and are still interested / able to contribute to the project.
|
Would like to see more approvals from @open-telemetry/technical-committee who would be responsible for nominating / approving spec sponsors. Please review / comment when you can. |
|
nit:
Shouldn't each "sponsor-to-be" acknowledge that they want to be a sponsor (e.g. by asking for an approval)? |
@kumoroku @lzchen - can you let us know if you want to be included in the new specification sponsor role or not? (update: I've also just pinged them on Slack) @cijothomas @djaglowski @tedsuo @MrAlias - have approved already @Oberon00 has confirmed being moved to the new role @iNikem has confirmed being moving to emeritus @zenmoto - was moved to emeritus recently (#2117), so can probably be removed from specification sponsor list |
|
|
||
| - The person being nominated has accepted the nomination by approving the pull | ||
| request. | ||
| - All TC members have approved the pull request or a majority of TC members have |
There was a problem hiding this comment.
Do we go with super majority? i.e. 2/3? Not a blocking concern though.
There was a problem hiding this comment.
This language came from the requirements to become a maintainer:
Unless stated otherwise in a SIG charter ratified by the Technical Committee,
a new maintainer is elected by vote of the existing maintainers of the SIG.
The vote is officially started when a pull request to add a new maintainer
is opened, and ends when the pull request is merged. The pull request may be
merged when the following conditions are met:
- The person being nominated has accepted the nomination by approving the pull request
- All maintainers have approved the pull request OR a majority of maintainers
have approved the pull request and no maintainer has objected by requesting
changes on the pull request. In the case that all maintainers have not given
approval, the pull request should stay open for a minimum of 5 days before merging.
The super majority requirement is the same as the requirement to add members to TC:
A candidate can be elected to the TC by the super-majority vote (greater than two thirds) of the existing TC members.
So there's a question of whether we want spec sponsor election to be more like maintainer or more like TC. The unanimous approval or abstain requirement to become a maintainer may help ensure the maintainers work better together since members are only added who all agree or are neutral on. The 2/3 supermajority requirement allows members to be elected which some people actively disapprove of.
Hard to know which voting requirement will be more appropriate for this function. We can always start with the unanimous approve or abstain requirement and later relax to be 2/3 supermajority.
There was a problem hiding this comment.
In my opinion the function of this group is more similar to that of the technical committee than any maintainer group. Reasonable and limited disagreement is important to ensure the specification evolves carefully in the right direction and the 2/3 supermajority rule best reflects this.
There was a problem hiding this comment.
Any other opinions on this? I don't feel strongly either way.
…ommunity into rework-spec-approver
…to rework-spec-approver
|
@trask Hi, tentatively, I'm fine with being moved to the new role so you can go ahead with this PR. I will need to figure out internally if I actually have the time to do any meaningful work for the OTel spec. It's possible that I ask for being moved to emeritus later. |
I am not currently active in OpenTelemetry project. At the present time it does not make sense to include me in spec sponsors. |
Hey I am currently overloaded with other responsibilities and most likely will not have time to commit to be a sponsor but am definitely interested in the future if my situation changes! Also am willing to contribute more to specs to earn a sponsorship role in the future if need be. |
Originally proposed in open-telemetry/opentelemetry-specification#3821, this PR formalizes the notion of a specification sponsor, which the TC and GC have been discussing for some time now.
A spec sponsor is a trusted collaborator of the TC. They are trusted to be assigned the type of complex specification issues that tend to require a fair bit of experience operating in the OpenTelemetry project. They can also sponsor issues such that other collaborators can drive the work under the help / guidance of the sponsor.
This idea should be thought of as an evolution and expansion of the role of a spec approver. It adds more privileges / responsibilities to that group and takes away the signal specific status. It allows us to grow the group of people who can contribute to the spec, and signal an additional level of trust in members.
This PR seeds the spec sponsor pool with the existing spec approvers, but this is a good opportunity to check in with the current spec approvers to make sure they're aligned with the privileges / responsibilities and are still interested / able to contribute to the project.