Labels/Triage for OpenSearch Core Repo #11617
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,49 @@ | ||||||
| # Triage in OpenSearch Core | ||||||
| ## What Do We Do With These Labels Anyway? | ||||||
|
There was a problem hiding this comment. The tone is a little casual to my taste, consider changing this title There was a problem hiding this comment. Sure. Whatever, man. ;)
Suggested change
There was a problem hiding this comment. We actually do have a style guide for the whole project in this regard: https://github.com/opensearch-project/documentation-website/blob/main/STYLE_GUIDE.md#tone |
||||||
|
|
||||||
| Across all repositories in opensearch-project, we have a process called “triage.” The goal of this process is to make sure repository owners and maintainers check new issues to understand them. First - we learn if the issue is security related (e.g. CVE), second - we understand if we have enough information to act on the issue, third - we re-label or respond on the issue. During triage we do not work on these issues, but instead just try to get the issue to a next step. Because the OpenSearch core repository (https://github.com/opensearch-project/OpenSearch) has so many different functions with different sets of contributors working on these functions, repo owners decided to treat these functions like separate repositories when triaging to get through the backlog faster and have more focus. There are a few maintainers that do triage in public (see https://meetup.com/OpenSearch to join) and there will be more coming. | ||||||
|
There was a problem hiding this comment. Triage is described in the project wide guidance [1], what do you think about referencing that guidance and call out how this project is deviates? |
||||||
|
|
||||||
| Here is an example of the workflow for a new issue in the core repo. | ||||||
|
There was a problem hiding this comment. I think there should be a body of maintainers/contributors that agreeing to work in this way, not a generic example. Note; I'm not part of any such team for core, so I triage on my own whims and timescales, otherwise I'd volunteer. There was a problem hiding this comment. Open to whatever the maintainers/other contributors want to do here. I haven't seen any other objections to date so this example remains. Can you suggest something more concrete? Not sure I understand what you mean. Thanks for taking on this review! There was a problem hiding this comment. Any luck finding a first follower(s) on this topic? I am concerned about documenting a process in a document that no one follows. There was a problem hiding this comment. I agree. I'll post this to the Slack #maintainers channel and ask for folks to review this PR. There was a problem hiding this comment. Personally, I side with @peternied here - we should leave the process(es) and workflow(s) up to repository maintainers to decide. The pace of changes varies greatly between repositories. There was a problem hiding this comment.
That is very fair, we don't have triage meetings for core specifically but we should I think There was a problem hiding this comment. Thanks @reta. Are we back to the idea of a core public triage meeting, then? It may make sense to develop the process from there and maintainers can document the process used and decide on useful labels with the community there. @peternied, @reta, I can help set something like that up with you (I'm not a core maintainer so I would be open to facilitating and recommending, but the maintainers should determine the process). There was a problem hiding this comment. @macohen You're trying to document the process that is currently being done, right? Much of this happens internally within Amazon teams, but some of it happens in open community meetings, but to date the actually process isn't documented anywhere in the open. Is that right? There was a problem hiding this comment.
I would love to see that happening (it is going well for security / ml-commons / search relevance) but I do not see (personally, as of today) how we could make it work: there are many components (or subsystems) in there, search relevance is an example of cutting a small piece of the core and looking into it, but there are many others pieces. Having one meeting to go over the OpenSearch core is an option (we need at least few leads to be present there) - it may be efficient use of maintaners' time but not users times. Having N meetings (one per component or subsystem) is another option that has own pros and cons. Depending on the way we would like to approach the problem, the triaging rules may differ. There was a problem hiding this comment.
Right. I don't know what the process is across all repos and I think the process has recently become more confusing and unclear so I'm attempting a declarative document that says what should be. If it's the wrong declaration, then let's change the document, but let's document the right thing. And let's keep this specific to OpenSearch repo since that's where the complexity is. I would also say that we need to make this process public and I am even more certain that the maintainers should own it. |
||||||
|
|
||||||
| 1. Every issue is created with an untriaged label by default. | ||||||
| 2. No less than once per week, untriaged issues should be reviewed: | ||||||
| 1. Read through the issue to understand the request. | ||||||
| 1. If the issue does not meet the template requirements, ask the requester for missing details and keep the untriaged label until all the details have been disclosed . | ||||||
|
There was a problem hiding this comment. I think its important that 'untriaged' label don't linger, with this repro's high volume of incoming issues, I might recommend stronger guidance to close with a message such as "Thanks for filing - after reviewing this issue there are details missing that are needed to accept this issue and have closed this issue. Please update the issue to the missing all details and re-open so we know to look at it again." In the security repo we handle this by having a separate 'triaged' flag that is only added during the triage meeting. Therefore anyone can quickly look at untriaged issues, remove the untriaged, and only during the open meeting are they accepted. YMMV There was a problem hiding this comment. That seems like a fine line between building the community and continuing to have the problems we have, but I'm open to it. Would definitely like to hear from other maintainers on this one, but I can make the update.
Suggested change
|
||||||
| 2. Move to 3 if you have all the details on the associated issue. | ||||||
| 3. If the issue does not impact the OpenSearch core repository, then transfer the issue to the appropriate team using the Transfer issue button on the lower right hand corner. If you don’t have the access to transfer, then you can add comment by mentioning [@opensearch-project/admin](https://github.com/orgs/opensearch-project/teams/admin) to do the transfer for you. If not, move to step 4. | ||||||
|
There was a problem hiding this comment. Is the @opensearch-project/triage team able to handle these requests? There was a problem hiding this comment. I don't think someone in the triage team can handle #3 unless they have maintainer status in both repos. Otherwise, I'd say they can. Are you suggesting that they do handle them? There are 120 people in that team today and I don't think all of them have eyes on this repo. Maybe maintainers or appointed label owners (could be one or more than one) who are contributors (not necessarily maintainers) to core could do this work. |
||||||
| 4. Assign the labels as per the details of the ticket | ||||||
| 1. Overall request type - bug. enhancement, feature. | ||||||
| 2. Additional context like good first issue, wontfix, question, discuss, rfc ...etc. ([General guidelines for github triaging](https://github.com/opensearch-project/.github/blob/main/RESPONSIBILITIES.md#triage-open-issues)) | ||||||
| 3. Make sure to enrich the issue with more details by adding your thoughts, add more context to the issue, or ask the author for more clarification if needed ...etc. | ||||||
| 4. Remove the untriaged label | ||||||
| 5. Add the component level labels based on TABLE 1 | ||||||
| 5. At any point a maintainer or issue owner can add or remove a label which will help clarify the work that needs to be done. This RFC will also become a markdown file in the OpenSearch repo and we will add a link to the issue templates in the repo so issue creators can reference this process to help it go smoother. | ||||||
|
There was a problem hiding this comment.
Should this be removed? There was a problem hiding this comment. YES! Thanks. Will do. |
||||||
|
|
||||||
|
|
||||||
| TABLE 1 | ||||||
|
There was a problem hiding this comment. Lots of items manually included on this table, do we need this table? What would you think about pointing folks to the labels in the project or the template so we don't have to keep this up to date? There was a problem hiding this comment. I'm not sure these labels stand alone in definition. They may need renaming or a reference. I agree that automation and simplicity would be better. If there was a way to have a description as metadata for a label then I think that could work better than a separate read me. Or if the labels were more self-describing. |
||||||
|
|
||||||
| |Component/Area |Sub-Area |Github Label |Desc | | ||||||
| |--- |--- |--- |--- | | ||||||
| |Search |Resiliency\Scale |Search:Resiliency |keep search working in spite of failures that may occur | | ||||||
| |Search |Query Performance |Search:Performance |maintain and improve read query performance | | ||||||
| |Search |Query Capabilities |Search:Query Capabilities |add new capabilities for querying | | ||||||
| |Search |Query Insights |Search:Query Insights |capabilities to understand what's happening under the covers in a query | | ||||||
| |Search |Aggregations |Search:Aggregations |aggregations/facets | | ||||||
| |Search |Remote Search |Search:Remote Search |using remote storage for search applications | | ||||||
| |Search |Search Relevance |Search:Relevance |query tuning to improve results (tools, query language, features) | | ||||||
| |Search |Searchable Snapshots |Search:Searchable Snapshots | | | ||||||
| |Search |Others\Unknowns |Search |catch-all for unclear issues (could break these down, assign multiple labels, add other labels) | | ||||||
| |Indexing |Replication |Indexing:Replication |moving data throughout the cluster at index time | | ||||||
| |Indexing |Performance\Throughput |Indexing:Performance |things that make indexing perform better | | ||||||
| |Indexing |Others\Unknowns |Indexing |catch-all for unclear issues (could break these down, assign multiple labels, add other labels) | | ||||||
| |Storage |Storage:Snapshots |Storage:Snapshots | | | ||||||
| |Storage |Storage:Performance |Storage:Performance | | | ||||||
| |Storage |Storage:Durability |Storage:Durability | | | ||||||
| |Storage |Remote Storage |Storage:Remote | | | ||||||
| |Storage |Others\Unknowns |Storage |catch-all for unclear issues (could break these down, assign multiple labels, add other labels) | | ||||||
| |Cluster Manager |Cluster Manager |Cluster Manager | | | ||||||
| |Extensions |Extensions |Extensions | | | ||||||
| |Release & Build |Build and Libraries |Build Libraries & Interfaces |Make sure the build tasks are useful and own the whole gradle plugin so that packaging and distribution are easy. | | ||||||
| |Release & Build |Upgrades | |For example Lucence Upgrades | | ||||||
| |Release & Build |Core Plugins |Plugins |Plugins within [Plugins](https://github.com/opensearch-project/OpenSearch/tree/main/plugins) like: language analyzers or within [modules](https://github.com/opensearch-project/OpenSearch/tree/main/modules) | | ||||||
| |Release & Build |Plugins Framework |Plugins |Solves the plugin infrastructure with core. | | ||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd highly recommend looking at the security team's triage guidance [1], while the format is based off communicating how the triage meeting operates the FAQ format might be useful to highlight edge cases.