Github Helpdesk Working Document

From WormBaseWiki
Jump to navigationJump to search

What this document should be used for.

  • Define the responsibilities of the staff member on helpdesk
  • Define how user responses can be professional/avoid unprofessional multiple responses etc.
  • People should add their experiences and any tricks they learn about how to bring together the and WebForm Help submissions so that future helpdeskers can work with the current system in an efficient manner.

The Help Desk officer is responsible for:

  • Ensuring that emails to wormbase-help are responded to in a timely manner
  • Preparing the agenda for the conference call
  • Acting as moderator during the call.

User requests should be:

  • Replied to within 48 hours of a business day by a staff member with expertise in that area.
  • It's ok to leave the response until the appropriate curators are available to respond.
  • if not, the Help Desk officer should:
    • Create a github ticket and reply to the user. (The url to the ticket can be provided as it's an open resource)

Help Email Archive

--Possibly not needed in this section?--

To view the Help Desk Archives click here (requires login and password): Help Desk Archives


Issues should now be submitted to the Issue Tracker on GitHub (

A guide on using github.

Github Helpdesk Working Document


When handing duties to the next officer, a summary of unanswered issues should be passed on in an email.

Interacting with github

Basically we need to get some kind of protocol in place to remove the current confusion ppl have with this system as we have it.

a) If a user emails

The HelpDesk officer should either:

Create a github ticket directly in github


Helpdesk can forge a help request through the website (if you are not logged in you can enter the user's email) so that a github ticket is generated and the user gets an email to track the issue.

This reduces staff to a single point of user help requests and allows users to follow the course of issue resolution (they can see all the comments).

  • good for staff in general.
  • Not so good for helpdesk.

The helpdesk person should either assign the ticket to a curator if it is clear cut


assign the consortium partner manager:

OICR - Todd

Hinxton - Kev

Caltech - Nomination please

or failing that them self so that they can keep track of things that aren't answered.

b) How to reply to the user and update the github ticket

  • Take the unique github email address assigned to the ticket
  • Reply to the original user submission cc'ing the github unique ID.


cc: (not necessary if everyone reading help@wormbase subscribes to github)

Body: Thanks for your email, you can find the data on our ftp site

On 12/12/2012 06:02, John Smith wrote:
> blah blah blub
  • Any comment that is not of interest to the user can simply be sent to the github email address (or entered at github web, of course).
  • Anyone who speaks the last words on the issue (such as in the example above) should close the issue (at github web).
  • Helpdesk should make sure all issues are tracked on github (including those immediately resolved so we have the records in github), assign them when possible, merge or close when appropriate.

c) How to get the unique email address for manually entered tickets

Staff with high level preferences get notification of all new by default they get a unique address for all tickets.

(need to check this fact)