-
Notifications
You must be signed in to change notification settings - Fork 61
Oncall Developers and Responsibilities
To ensure user issues are addressed in a timely manner, K's main developers offer an on-call service, where all of them currently get their fair share of user support and interaction.
At any time, one of the main K developers is on call. The responsibility of the on-call developer is to monitor the K's various user interaction channels and respond quickly to any and all user questions and issues.
When a user sends a message on one of the channels, if you are the on-call developer, make sure to:
- React quickly. If you already know how to respond to the question or fix the issue quickly, simply do that. Otherwise, let the user know that we have acknowledged the problem and that we are looking into it. Ideally, you should reply in some way to any issue within an hour or two - worst case, within 12 hours.
- Follow through. If the problem is more involved, and after you notify the user that we are looking into it, either solve the problem or talk to someone in the team who knows more. If the problem cannot be resolved on the spot, add an issue (if one is not already there) tagged "question" to the github repository. Regardless of the outcome, keep the user informed of our progress and decisions (including, if necessary, by letting them know that we cannot fix the problem at this time but we have added the github issue to track it).
The current user interaction channels are:
- k-user mailing list (you could also monitor k-list)
- github repository (both issues and pull requests) -- make sure you activate all notifications for the weeks you are on call
- gitter chat (https://gitter.im/kframework/k) -- be online as much as possible (gitter also has mobile apps) and make sure to activate notifications
At the end of your on-call period, please email the next person on-call to remind them that they are next, and inform them of any pending issues or user interactions.
Each of us can pick the weeks we are on call. We need to make sure all weeks are covered.
week | on call |
---|---|
March 7 | Daejun Park |
March 14 | Cosmin Radoi |
March 21 | Shijiao Yuwen |
March 28 | Cosmin Radoi |
April 4 | Daejun Park |
April 11 | Andrei Stefanescu |
April 18 | Cosmin Radoi |
April 25 | Daejun Park |
May 2 | Shijiao Yuwen |
May 9 | Cosmin Radoi |
May 16 | Cosmin Radoi |
May 23 | Cosmin Radoi |
May 30 | Daejun Park |
June 6 | Daejun Park |
June 13 | Daejun Park |
June 20 | Cosmin Radoi |
June 27 | Daejun Park |
July 4 | Andrei Stefanescu |
July 11 | Cosmin Radoi |
July 18 | Daejun Park |
July 25 | Andrei Stefanescu |
August 1 | Cosmin Radoi |
August 8 | Daejun Park |
August 15 | Daejun Park |
August 22 | Daejun Park |
August 29 | Daejun Park |
September 5 | Andrei Stefanescu |
September 12 | Cosmin Radoi |
September 19 | |
September 26 | |
October 3 | |
October 10 | |
October 17 | |
October 24 | |
October 31 | |
November 7 | |
November 14 | |
November 21 | |
November 28 | |
December 5 | |
December 12 | |
December 19 | |
December 26 |
Below are the K developers who rotate the on-call responsibilities:
- Lucas Pena
- Shijiao Yuwen
- Daejun Park
- Cosmin Radoi
- Andrei Stefanescu
Even if you are not in the list above, you are still very welcome to contribute to K by doing on-call service. Pick an empty slot in the schedule, and let us know.
Issues tagged with "question" are questions from our users, and thus require special handling. You should always make sure that unless everything is ready for active work on the task, that you have asked any questions necessary and are waiting for a response. If you need more information before you can resolve the issue, but they have not responded in over a week, feel free to close the issue with a message telling them to reopen it if they can provide the information you need. If they have responded to all the questions you need to ask, then you should work on the task according to its priority. When it is resolved, you should close the issue and ask them to reopen it if there is still some issue.
Based on what the issue is about, you may not be immediately familiar with the part of the codebase in question. If this is the case, talk to someone else in the team (e.g., Cosmin) about how they think you should proceed. The issue is still your responsibility (it's an opportunity to learn more of the codebase), but you are free to get help in understanding the code and what is needed to be done.