mirror of https://github.com/Seagate/cortx.git
Page:
Community Triage Process
This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
TLDR; This document describes out community triage, how it works, who does it and what to expect. Questions? patrick.hession@seagate.com
Triage members [Opensource Community]:
Each triage member should scan their areas of responsibility (you can see who is covering each repo here) on a daily basis (excluding weekends, holidays, PTO) for any newly reported issues, questions, bugs, etc reported by our external community. Note that our innersource community is part of our external community. For each item found, each triage member should follow the below process.
Process For Each Item Found:
- If the item was reported by a known member of the Seagate CORTX team, then it can be ignored. Otherwise, continue to Step 1.
- To help identify whether the person is a member of the Seagate CORTX team, the cortx_people.py script can be used.
- If the identify of the member cannot be identified, then continue to Step 1.
- If the problem has not already been resolved by someone outside the triage team.
- Acknowledge within 24 hours that we have seen the issue (excluding weekends, holidays, PTO)
- Reproduce the issue and acknowledge whether we can/cannot reproduce the issue.
- Stay on the issue until it’s closed
- If necessary, engage a member of the engineering team to help. Continue to stay on to make sure that person properly and expeditiously handles the issue. Officially, Mukul Malhotra provides L2 support for us.
- If it requires more than 4 hours of support then make sure issue is in github project-board and properly assigned and updated.
- Document it (if needed) to help the community not run into the same issue in the future
- Component gatekeepers consistently meet weekly or monthly to triage issues for their respective components
- Running a Triage Meeting
- Review Newly Created Open Issues
Best Practices
- If a small issue is reported (e.g. a typo), then here is a nice way to reply to that:
- Thanks so much for reporting that! I went ahead and fixed that in this PR (provide link). In the future, feel free to report errors as you've done here but also please feel free to go ahead and submit your own PR. We love getting community contributions and this way you'll get credit as a community contributor.
- If someone expresses difficulty with some sort of concept and we are surprised that they are experiencing that difficulty, then here is the best way to reply to that:
- This is a great opportunity for us to learn about gaps that we have in our documentation. Try not to be accidentally insulting by saying something like, "Wow, that's easy. I'm surprised you're struggling with that." Instead, just explain what they are missing factually and in a straight-forward way and ask a few questions to try to understand where they got stuck. Thank them for helping us find gaps in our documentation. Remember that everyone reporting a problem is doing us a giant favor since most people find a problem and just leave the community. Make sure to let them know that we appreciate their feedback.
- If someone complains about something, even if we disagree with them, then here is the best way to reply to that:
- Thanks for the feedback. We will keep it in mind as we move forward.
Distribution of responsibilities [Opensource]:
| Repo | Documentation |
|---|---|
| main | Rose |
| motr | Rose |
| prvsnr + management-portal + manager | Patrick |
| monitor + experiments | Patrick |
| ha + hare + utils | Patrick |