Skip to content
This repository has been archived by the owner on Feb 1, 2020. It is now read-only.

Oncall Developers and Responsibilities

Jump to bottom
Cosmin Radoi edited this page Feb 11, 2016 · 37 revisions

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.

Oncall Developers

Below are the K developers who rotate the oncall responsibilities:

  1. Dwight Guth (RV; lead engineer developer)
  2. Brandon Moore (UIUC)
  3. Daejun Park (UIUC)
  4. Edgar Pek (UIUC)
  5. Lucas Pena (UIUC)
  6. Cosmin Radoi (UIUC)
  7. Manasvi Saxena (RV)
  8. Andrei Stefanescu (UIUC)
  9. Shijiao Yuwen (UIUC)

Each developer above is oncall for one week, starting with Saturday and ending with Friday. When one is done with his or her week, they should modify the line below to list the next developer, and should also send a message to the k-list stating who is the next oncall person, together with a link to this wiki page, as a reminder for the responsibilities:

Currently Oncall (2016/2/6 - 2016/2/12): Cosmin Radoi

Responsibilities

The primary responsibility of the oncall is to respond to user questions and to resolve issues which there is otherwise no clear developer responsible for the issue. This is represented primarily in two forms: the first is to answer questions that arise on the k-user list, and the second is to resolve issues assigned to k-oncall on github.

As part of this, Dwight will assign new incoming issues to k-oncall as needed, and tag them as appropriate. All issues assigned to k-oncall are the responsibility of the oncall user unless Dwight and Grigore can be persuaded they are better handled by someone else. However, some issues are considered higher priority than others, and as such should be resolved first. Essentially, the prioritization of tasks is as follows:

  1. Answer questions on k-user, and resolve issues tagged with only "question".
  2. Resolve issues tagged with "question" and "bug".
  3. Resolve issues tagged with "bug".
  4. Resolve issues tagged with "enhancement" and "question"
  5. Resolve issues tagged with "enhancement".

Tasks 4 and 5 should probably not be attempted at this point. We may instead choose to eventually set up a prioritization of enhancements based on bimonthly review of the issue backlog. However, tasks 1-3 are your responsibility as oncall. You should anticipate that this may take up a significant portion of your time for the week in question, at least until our issue backlog has become smaller.

Resolving Issues

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.

Issues not tagged with "question" are ones we created ourselves and thus require only to resolve the task as stated in the issue. That said, 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 Dwight or 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. Note that some issues, ones dealing with the specific parts of the code which are being modified by the KORE refactoring, may not be worth fixing, unless they are trivial to fix or deal with a part of the code that is not affected by the refactoring. However, such issues should remain open until it can be verified that they are no longer an issue in the new pipeline, and, depending on whether or not the pipeline is ready to be modified for the relevant section, may be your responsibility to fix in the new pipeline.

Clone this wiki locally