The maintainers of the OpenSearch Repo seek to promote an inclusive and engaged community of contributors. In order to facilitate this, weekly triage meetings are open-to-all and attendance is encouraged for anyone who hopes to contribute, discuss an issue, or learn more about the project. There are several weekly triage meetings scoped to the following component areas: Search, Storage, and Cluster Manager. To learn more about contributing to the OpenSearch Repo visit the Contributing documentation.
Attendance is not required for your issue to be triaged or addressed. If not accepted the issue will be updated with a comment for next steps. All new issues are triaged weekly.
You can track if your issue was triaged by watching your GitHub notifications for updates.
Each meeting we seek to address all new issues. However, should we run out of time before your issue is discussed, you are always welcome to attend the next meeting or to follow up on the issue post itself.
Check the OpenSearch Meetup Group for the latest schedule and details for joining each meeting. Each component area has its own meetup series: Search, Storage, Cluster Manager, and Indexing.
After joining the virtual meeting, you can enable your video / voice to join the discussion. If you do not have a webcam or microphone available, you can still join in via the text chat.
If you have an issue you'd like to bring forth please prepare a link to the issue so it can be presented and viewed by everyone in the meeting.
Meeting structure may vary slightly, but the general structure is as follows:
- Initial Gathering: Feel free to turn on your video and engage in informal conversation. Shortly, a volunteer triage facilitator will begin the meeting and share their screen.
- Record Attendees: The facilitator will request attendees to share their GitHub profile links. These links will be collected and assembled into a tag to annotate comments during the meeting.
- Announcements: Any announcements will be made at the beginning of the meeting.
- Review of New Issues: We start by reviewing all untriaged issues. Each meeting has a label-based search to find relevant issues:
- Attendee Requests: An opportunity for any meeting member to request consideration of an issue or pull request.
- Open Discussion: Attendees can bring up any topics not already covered by filed issues or pull requests.
- Review of Old Untriaged Issues: Look at all untriaged issues older than 14 days to prevent issues from falling through the cracks.
The facilitator is crucial in driving the meeting, ensuring a smooth flow of issues into OpenSearch for future contributions. They maintain the meeting's agenda, solicit input from attendees, and record outcomes using the triage tag as items are discussed.
No prior contributions are required. All interested individuals are welcome and encouraged to attend. Triage meetings offer a fantastic opportunity for new contributors to understand the project and explore various contribution avenues.
You can always open an issue including one that you think may be a duplicate. If you believe your issue is similar but distinct from an existing one, you are encouraged to file it and explain the differences during the triage meeting.
If you have an existing issue you would like to discuss, you can always comment on the issue itself. Alternatively, you are welcome to come to the triage meeting to discuss.
While we are always happy to help the community, the best resource for implementation questions is the OpenSearch forum.
There you can find answers to many common questions as well as speak with implementation experts.
Yes, there are several labels that are used to identify the 'state' of issues filed in OpenSearch .
| Label | When Applied | Meaning |
|---|---|---|
Untriaged |
When issues are created or re-opened. | Issues labeled as 'Untriaged' require the attention of the repository maintainers and may need to be prioritized for quicker resolution. It's crucial to keep the count of 'Untriaged' labels low to ensure all potential security issues are addressed in a timely manner. See SECURITY.md for more details on handling these issues. |
Help Wanted |
Anytime. | Issues marked as 'Help Wanted' signal that they are actionable and not the current focus of the project maintainers. Community contributions are especially encouraged for these issues. |
Good First Issue |
Anytime. | Issues labeled as 'Good First Issue' are small in scope and can be resolved with a single pull request. These are recommended starting points for newcomers looking to make their first contributions. |
| Outcome | Label | Description | Canned Response |
|---|---|---|---|
| Accepted | -untriaged |
The issue has the details needed to be directed towards area owners. | "Thanks for filing this issue, please feel free to submit a pull request." |
| Rejected | N/A | The issue will be closed with a reason for why it was rejected. Reasons might include lack of details, or being outside the scope of the project. | "Thanks for creating this issue; however, it isn't being accepted due to {REASON}. Please feel free to open a new issue after addressing the reason." |
| Area Triage | +{AREALABEL} |
OpenSearch has many different areas. If it's unclear whether an issue should be accepted, it will be labeled with the area and an owner will be @mentioned for follow-up. | "Thanks for creating this issue; the triage meeting was unsure if this issue should be accepted, @{PERSON} or someone from the area please review and then accept or reject this issue?" |
| Transfer | N/A | If the issue applies to another repository within the OpenSearch Project, it will be transferred accordingly. | "@opensearch-project/triage, can you please transfer this issue to project {REPOSITORY}." Or, if someone at the meeting has permissions, they can start the transfer. |
Due to the sensitive nature of security vulnerabilities, please report all potential vulnerabilities directly by following the steps outlined on the SECURITY.md document.
During the triage meeting, facilitators should use the tag [Triage - attendees 1 2] to indicate a collective decision. This ensures contributors know the decision came from the meeting rather than an individual and identifies participants for any follow-up queries.
This tag should not be used outside triage meetings.