[chore] Add "Code Owners" field to new component template #23780
Conversation
| - label: If this is a vendor-specific component, I am proposing to contribute this as a representative of the vendor. | ||
| - label: This is a vendor-specific component. | ||
| - label: (If a vendor-specific component) I am proposing to contribute and maintain this as a representative of the vendor. | ||
| - label: (If a vendor-specific component) I am a member of the OpenTelemetry project. |
There was a problem hiding this comment.
I'm in favor of moving this check out of the vendor-specific component section and into a general section of the template. I like the idea of asking up front if the contributor is a member or not, regardless of whether they are sponsoring a vendor-specific component.
There was a problem hiding this comment.
I am of two minds on this one. The question to me is whether or not we should assume that the proposer of the component is the contributor of it. In practice, I think this is the case the vast majority of the time, but I think there might be some value in welcoming proposals from end users, non-code contributors, etc, which could then be picked up by a contributor.
For vendor-specific components, we've made this quite explicit so I don't think it's a problem.
There was a problem hiding this comment.
That is fair, we should allow components to be proposed by anyone and anyone can volunteer to carry that work forward. In that case I like the idea of whoever requests to be a code owner to already be a member for the reasons listed in my other comment.
There was a problem hiding this comment.
Is this checkbox needed at all? GitHub can already tell us whether they are a member of the otel project
There was a problem hiding this comment.
I wonder if being a member of the OTel community to be a code owner should be explained somewhere in a separate section in this template, to help newcomers understand why it's important to their contribution.
There was a problem hiding this comment.
Is this checkbox needed at all? GitHub can already tell us whether they are a member of the otel project
The case for it would be so that the proposer understands the requirements.
There was a problem hiding this comment.
How about "I have identified one or more people who are members or aspiring members of the OpenTelemetry project who can volunteer to serve as codeowners, and am listing them in this proposal for confirmation."
There was a problem hiding this comment.
How about "I have identified one or more people who are members or aspiring members of the OpenTelemetry project who can volunteer to serve as codeowners, and am listing them in this proposal for confirmation."
This sounds good. I suppose a required text field is appropriate then.
There was a problem hiding this comment.
I've reworked the PR to just add a new "Code Owners" section alongside the "Sponsor" section.
| - label: If this is a vendor-specific component, I am proposing to contribute this as a representative of the vendor. | ||
| - label: This is a vendor-specific component. | ||
| - label: (If a vendor-specific component) I am proposing to contribute and maintain this as a representative of the vendor. | ||
| - label: (If a vendor-specific component) I am a member of the OpenTelemetry project. |
There was a problem hiding this comment.
One downside of requiring membership before proposing a component is that the proposer can no longer use the contributions from creating the component as the means to membership. This provided a clear path toward membership.
A benefit of this change, though, is that is should give us more confidence going into the proposal that the user is going to maintain the component. Personally, I think Contrib is large enough at this point that more rigorous rules and expectations are necessary to ensure we can grow any further.
| @@ -26,8 +26,9 @@ body: | |||
| label: Is this a vendor-specific component? | |||
There was a problem hiding this comment.
I wonder if there's a way to clarify this requirement. We've seen a few times now where this question isn't clear to new contributors.
There was a problem hiding this comment.
The description currently says, A vendor-specific component directly interfaces with a vendor-specific API and is expected to be maintained by a representative of the same vendor. To me this is pretty clear, but If anyone suggests clearer language I'm happy to incorporate it into this PR.
There was a problem hiding this comment.
A separate PR seems best, just because you are trying to land something already.
| - label: If this is a vendor-specific component, I am proposing to contribute this as a representative of the vendor. | ||
| - label: This is a vendor-specific component. | ||
| - label: (If a vendor-specific component) I am proposing to contribute and maintain this as a representative of the vendor. | ||
| - label: (If a vendor-specific component) I am a member of the OpenTelemetry project. |
There was a problem hiding this comment.
Is this checkbox needed at all? GitHub can already tell us whether they are a member of the otel project
djaglowski
force-pushed
the
vendor-member
branch
from
faecad8 to
6680f5b
Compare
djaglowski
changed the title
djaglowski
force-pushed
the
vendor-member
branch
from
6680f5b to
ea341a0
Compare
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
#20868 represents a push to ensure that all component code owners are members of the OpenTelemetry organization.
This has direct implications for our notion of "vendor-specific components", which are those that interact specifically with a particular vendor, and are contributed and maintained by a representative of a vendor. We require that the vendor representative must maintain the component, which essentially means they must be a code owner. Therefore, I am proposing that the representative must be a member of the org before the component may be accepted.