[documentation] template for new component issue #7058
Conversation
|
Do we need this? Is there any evidence that users often create issues of this kind? Check existing issues perhaps to show that this is a top request type? |
This was proposed in the SIG meeting on Jan 5 to reduce friction for reviewers and contributors. The thinking here is that this would replace the need to have a first PR when adding a component. Instead the issue containing the same level of information as that initial PR would suffice. It's related to open-telemetry/opentelemetry-collector#4630 |
|
I just updated #6926 with a comment based on my recollection of what we agreed during the latest SIG call: #6926 (comment) The major difference is that it just mentioned the issue that has to be created, what the initial PR should contain, and the step about the -releases repo. I think we might then need two templates, one for the initial issue and one for the PR. |
|
Removed the checklist, which can be added as a PR checklist. Updated the template with some links to example content and updated the contributing document to point to creating a new issue. @bogdandrutu @jpkrohling @mx-psi @tigrannajaryan PTAL |
CONTRIBUTING.md
Outdated
| * Who's the sponsor for your component. A sponsor is an approver who will be in charge of being the official reviewer of the code. For vendor-specific components, it's good to have a volunteer sponsor. If you can't find one, we'll assign one in a round-robin fashion. For non-vendor specific components, having a sponsor means that your use case has been validated. | ||
| * Some information about your component, such as the reasoning behind it, use-cases, telemetry data types supported, and anything else you think it's relevant for us to make a decision about accepting the component | ||
| * The configuration options your component will accept. This will help us understand what it does and have an idea of how the implementation might look like |
There was a problem hiding this comment.
For some reason this shows as a preformatted block in Github preview, which makes it difficult to read due to long lines.
There was a problem hiding this comment.
Fixed, i fixed the formatting earlier but hadn't saved it before submitting the change.
CONTRIBUTING.md
Outdated
| @@ -6,6 +6,13 @@ before you begin your work. | |||
|
|
|||
| ## Adding New Components | |||
|
|
|||
| Before any code is written, open an issue providing the following information: | |||
|
|
|||
| * Who's the sponsor for your component. A sponsor is an approver who will be in charge of being the official reviewer of the code. For vendor-specific components, it's good to have a volunteer sponsor. If you can't find one, we'll assign one in a round-robin fashion. For non-vendor specific components, having a sponsor means that your use case has been validated. | |||
There was a problem hiding this comment.
Is the sponsor only responsible for the review or also for subsequent maintenance?
There was a problem hiding this comment.
Thanks for the callout, i've added a note about the sponsor becoming a code owner as well.
Adding a template to use as an experiment in this repository. The workflow is expecting users to open a new component issue when proposing an issue, to reduce unnecessary work both for contributors and maintainers.
codeboten
force-pushed
the
codeboten/add-new-component-template
branch
from
ec3dea4
to
0fba202
Compare
CONTRIBUTING.md
Outdated
| **Before** any code is written, [open an issue](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/new?assignees=&labels=new+component&template=new_component.md&title=New%20component) providing the following information: | ||
|
|
||
| * Who's the sponsor for your component. A sponsor is an approver who will be in charge of being the official reviewer of the code and become a code owner for the component. For vendor-specific components, it's good to have a volunteer sponsor. If you can't find one, we'll assign one in a round-robin fashion. For non-vendor specific components, having a sponsor means that your use case has been validated. | ||
| * Some information about your component, such as the reasoning behind it, use-cases, telemetry data types supported, and anything else you think it's relevant for us to make a decision about accepting the component |
There was a problem hiding this comment.
for us to make a decision about accepting the component
Once the issue is opened, what is the process for making a decision? How is the decision indicated?
There was a problem hiding this comment.
What are your thoughts? The best I can think of is approvers/maintainers commenting on the issue that a decision has been made to approve/reject a proposal.
There was a problem hiding this comment.
Labels? "Proposed Component", "Approved Component", and after X weeks close the issue as no decision made => no interest in supporting this?
There was a problem hiding this comment.
Labels? "Proposed Component", "Approved Component", and after X weeks close the issue as no decision made => no interest in supporting this?
I like this. The "Sponsor Needed" label can be applied until a decision is made.
Co-authored-by: Daniel Jaglowski <jaglows3@gmail.com>
Adding a template to use as an experiment in this repository. The workflow is expecting users to open a new component issue when proposing an issue, to reduce unnecessary work both for contributors and maintainers.
Once the template is approved, it can be copied over to the core repository and linked from the docs as well.