The Sustained Engineering Team (SET) is responsible for improving and maintaining quality.
SET is a rotating team that is comprised of engineers from the different feature teams. The rotation is on a two week cycle. Who is currently on SET can be seen in the header of the ~Sustained Engineering channel.
Feature teams will commit a total of 4 engineers plus a lead to SET for each rotation. While on SET, that engineer should attend their feature team’s sprint planning but should not be assigned any work from their feature team. For the two weeks that engineer should primarily be working on issues for SET. If SET has no tickets to work on, then the engineer may pick up some work for their feature team.
SET has a lead engineer from one of the feature teams who leads the team for the duration of the rotation. This person should be identified as the SET Lead for each rotation in the channel header. The support team can contact this person when they are unsure who else to escalate to.
Engineers on SET are also on an on-call rotation as defined by the process here.
SET works in a continuous style using this Kanban JIRA board. Tickets in the TO DO column should be organized from highest priority to lowest priority, based on the Priority of Work section. The SET lead should make sure that the tickets are priority ordered but team members can move tickets around to meet the correct priorities as necessary.
Team members on SET should pull tickets off the top of TO DO queue, work on them to completion and then pull another one off the TO DO queue.
SET meets twice per week, after the Tuesday and Thursday triage meetings. During these meetings SET members should provide status updates and talk about any blockers that have been encountered.
After the Tuesday meeting, the SET lead should post a team status update in the ~Sustained Engineering channel using the following template:
#set-update #set-update-YYYY-MM-DD Bugs resolved in the last 7 days: <X> (<X> reported by customers) Bug fix PRs submitted in the last 7 days: <X> (<X> reported by customer) In progress fixes: * <list of tickets that are currently being worked on> Next in the queue: * <list of 3-5 tickets next in the queue> Total bugs in backlog: <X> Notes: * <any notes or qualifiers for the week>
See https://community.mattermost.com/core/pl/8wryjyfpnjguundipu9nebiuda for an example.
You can get the bugs resolved in the last 7 days from here: https://mattermost.atlassian.net/issues/?filter=15097
And the customer bugs resolved in the last 7 days: https://mattermost.atlassian.net/issues/?filter=15098
To see bugs submitted, look at the Submitted column of the Kanban board.
Below is how SET prioritizes what is worked on.
SET attends all triage meetings. During triage, SET should:
During non-release weeks, triage is held twice a week. Near the end of the release cycle, triage is held daily.
Part of SET’s responsibility is to interface with the customer support team. SET’s primary goal in respect to support is to triage escalated support issues, work on any high priority customer bugs requiring code change, as well as provide training and knowledge share with the customer support team.
For details on the Customer/Pre-Sales Support Escalation Process, please refer to this document.
SET members should use the following responses when receiving issue escalations from the customer or pre-sales support teams:
Hi [insert reporter name], thanks for the report. After looking into it a bit this is working as designed and any changes in behavior would be a new feature. Is this something we get a lot of requests from different customers for? If so, I’d suggest talking to [insert PM name] to see if it makes sense to put on the product roadmap. If you think this observation is incorrect, could you give us the following so we can look into it further: 1. Information about the customer’s environment (MM version, DB type/version, cloud provider, etc.) 2. Logs around the time of the issue 3. Reproduction steps 4. What you have tried to resolve the issue 5. [insert other needs as necessary]
Hi [insert reporter name], thanks for the report. This looks like a configuration issue that shouldn’t require any code change to resolve. Have you seen the docs for this [insert link]? If so, can you point to where the docs are deficient and we can work to get those updated. In the meantime, here’s some things I’d suggest trying: [insert list of troubleshooting steps]
Hi [insert reporter name], thanks for the report. This seems to be a configuration that we don’t support. I’d recommend steering the customer to use the supported configuration as documented here [insert link]. If you’re seeing lots of requests for this configuration, I’d suggest talking to [insert PM name] to see if we should add support for it.
Hi [insert reporter name], to help best could we get some more information? Particularly looking for the following: 1. Information about the customer’s environment (MM version, DB type/version, cloud provider, etc.) 2. Logs around the time of the issue 3. Reproduction steps 4. What you have tried to resolve the issue 5. [insert other needs as necessary]
Hi [insert reporter name], thanks for the report. This looks like a bug, I’ve created [insert ticket link] to track and have put it into the queue to be worked on. Just a reminder that unless this is a hotfix worthy issue the fix won’t make it into the product until the next release. We’ll try to find a workaround that can be applied without code change but that isn’t always possible.