META: Copied from SOP - FogBugz Support - that page should be updated/removed.  

PURPOSE

This Standard Operating Procedure (SOP) explains how the CETwill work with cases opened in FogBugz from email to the techsupport@cochrane.org address.

CONVENTIONS

  • Servers, Drives, Folders, Files, Menus and Commands names are in bold (e.g.: folder Backup)

  • Programs names are in italics (e.g.: BigSpeed Zipper)


SCOPE

All IKMD Team is involved with this SOP, as all have access to FogBugz.

PROCEDURE

Background and objectives

The following principles apply for out support communications:

  • VALUE - people always get something out of contacting us. Value can be a solution of their problem; or it can be information that helps them move forward in solving their problems; or if the problem cannot be solved, at least an expression of sympathy for their trouble. Always include at least one type of value in a response.      

  • TIMELINESS - we respond within 24 hours. During office hours, within 3 (TO BE DISCUSSED!)  This is not just for initial submission, but also for later correspondences. If a lengthy ask is part of helping the user,  we will schedule it and let them know when it will be carried out.  

  • CLARITY - we use simple clear language, always labeling software features 100% accurately

  • COURTESY - we are friendly, even when telling users they have made a mistake. The customer  is NOT always right, but we are always nice about it. But we do  not overdo courtesy at the expense of clarity and timeliness

  •   

Triage and support levels

Tier I (or Level 1, abbreviated as T1 or L1) is the initial support level responsible for basic customer issues. The first job of a Tier I specialist is to:

  • gather the customer’s information
  • determine the customer’s issue by analyzing the symptoms and figuring out the underlying problem
  • When analyzing the symptoms, it is important for the technician to identify what the customer is trying to accomplish so that time is not wasted on "attempting to solve a symptom instead of a problem."

This level should gather as much information as possible from the end user. The information could be computer system name, screen name or report name, error or warning message displayed on the screen, any logs files, screen shots, any data used by the end user or any sequence of steps used by the end user, etc. This information needs to be recorded into the issue tracking or issue logging system. This information is useful to analyze the symptoms to define the problem or issue.


product /category1stline2nd line3rd linenotes
Archie
ME Support Team

Javier Mayoral

Rasmus Moustgaard

Move to project: "ME Support"
Cochrane Account (login issues)
Daniel Pradacochraneaccount@cochrane.org
Cochrane Library (errors in published reviews or access)
cs-cochrane@wiley.comDavid Hives (Wiley)
Monaz Mehta (CEU)

Cochrane Library (comments on published reviews)
Refer user to http://www.cochranelibrary.com/help/submitting-comments-on-cochrane-reviews.html

Email (CET)
Daniel PradaDavid Lefebvre
Membership
Nancy OwensChris Champion
Methods

Dario Sambunjak

Kerry Dwan


RevMan 5

Dario Sambunjak

Rasmus Moustgaard
RevMan sales
Roger TrittonCharlotte Pestridge
Training (general)
Dario Sambunjak

Training (Cochrane Interactive Learning)
interactivelearning@cochrane.orgDario Sambunjak (content)
Richard Hollis (sales)

Websites
Paolo Rosati

Martin Janczyk
Daan Wilner

Move to project: "WT Misc"
Unclear/general
Dario Sambunjak?



Arrival of a new case

New cases to IKMD Team FogBugz could come from:

  1. Archie Report a Problem form on IKMD website (tech.cochrane.org)

  2. Archie Suggestion can be sumitted via ideas.cochrane.org

  3. RevMan Report a Problem form on IKMD website  (tech.cochrane.org)

  4. RevMan Suggestion can be sumitted via ideas.cochrane.org

  5. Mails directly to techsupport@cochrane.org

  6. FogBugz cases transferred from Web Team or ME Support

  7. Cases directly created by IKMD Team members.

Cases from 1 to 5 are automatically added to the Inbox project in FogBugz and assigned to the primary contact.

Cases from 6 and 7 are manually assigned to the relevant project (Archie or RevMan) and contact by the person creating or transferring the case.

Processing and assignment of Cases assigned to Inbox Project

Common Steps

  1. New case is submitted and arrives to Inbox assigned to the primary contact.

  2. Primary contact read the case

  3. Check if case is related with IKMD Team

    1. Related case

 Archie/RevMan Report a Problem

Archie/RevMan Suggestion

Mail directly to techsupport@cochrane.org

  1. Case to ME Support or Web Team sent by mistake

  • Assign case to relevant member and project: ME Support or Web Team (*)

  1. Unrelated case

  • Reply to sender using a template informing to whom he/she should contact.

  • Close case

* If primary contact do not have rights to move cases between projects, assign it to a FogBugz administrator to move the case.

Archie/RevMan Report a Problem

  1. Check in FogBugz for a similar case

    • Case similar solved

      • Send solution to sender

      • Add Case Number related with this case

      • Resolve case as Responded

      • Close case

    • Case similar not solved

      • Send info to sender that this case was previously reported and when new information will arrive we will contact them.

      • Add Case Number related with this case

      • If related case is assigned to Archie/RevMan Project and Area, assign this one also

      • If related case is assigned to a person, assign this one also

    • No case similar

Archie/RevMan Suggestion

If you receive Archie/RevMan suggestion, you should redirect the person who submitted the suggestion to ideas.cochrane.org and close the case. For more information on how to use ideas.cochrane.org see SOP - ideas.cochrane.org

Mail directly to techsupport@cochrane.org

  1. Check which type of case is

    1. Problem

    2. Suggestion

New Bug

  1. Check if all relevant info has been submitted

    • In other case request for further info: screenshots, description, steps to replicate bug...

  2. Edit case info

    • Give relevant title

    • Give description

    • Add steps to replicate the bug

    • Add possible solutions (workaround)

    • Identify Project and Area

    • Set Milestone to next Archie/RevMan Release

    • Change Category to Bug

    • Give Priority

    • Add tags

  3. Reply to sender that case is in process and assigned to the relevant person

  4. Assign case to the relevant developer to work with the Bug. In case of doubt, assign to IKMD Team to discuss in next Team Meeting.

New Enquire

  1. Check if all relevant info has been submitted

  • In other case request for further info: screenshots, description, user cases...

  1. Depending on the case:

    1. Contact Person can resolve the case in short time (less than 24 hours)

      • Solve case

      • Reply with answer to sender

      • Set case as Resolved

      • Close case

    2. Contact Person can not resolve the case in short time (more than 24 hours)

      • Reply to sender that case is in process

      • Try to solve in the next days

      • Once case is solved:

        • Reply with answer to sender

        • Set case as Resolved

        • Close case

    3. Contact Person can not resolve the case

Undecided

  1. Request further information to sender: screenshots, description, user cases, steps to replicate the problem...

  2. When info is cleared follow to:

Processing and assignment of Cases of not Default Contact

When a person in FogBugz is assigned to a case should follow:

  1. Read all case info carefully

  2. Check if all relevant info has been submitted

    • In other case request for further info: screenshots, description, user cases...

  3. If a release is expected to be in the next 2 weeks, and this is a new case that require development, it should be reassigned to the next release.

  4. Check if you are able to solve the case

  • If not, assign case to the relevant developer to solve it. In case of doubt, assign to IKMD Team to discuss in next Team Meeting. If you are able, add any possible solutions to the problem.

  • If able and requires development:

    • Check that are filled properly all fields:

      • Project

      • Area

      • Milestone

      • Priority

      • Category

      • Estimated hours (optional: for developers)

      • Tags

    • Once solved, check if info needs to send back info to sender and resolve the case.

  • If able and do not require development:

    • Reassign the case to Default Contact with the steps to solve the problem (hints, workaround or any other suggestions).

    • Default Contact reply to sender with solution

    • Default Contact Resolve Case

Close a case

When a case is resolved could be assigned to:

  • Default contact

  • Person who created the case if it is a FogBugz user

  • Person who is in charge of testing (for Bugs and Features fixed or implemented)

  • Person who is in charge of writing documentation (for new Features)

Steps to follow by the person to close the case:

Do not require testing/documentation

  1. Check that the Resolved status match with the messages in the case (f.ex. is case is Resolved (Responded), check that there have been contact with a possible solution to the sender).

  2. Contact sender if required with resolution info of the case

  3. Check if there are related cases that should be also closed or responded.

  4. Check if relevant tags are added/removed.

  5. Close the case

Require testing

  1. When start to test add Kanban tag: Ready for Test; Assign to: Tester to decided

  2. After test:

    • Test failed:

      • Change Kanban tag to: Implementation/In progress

      • Assign case to developer to fix problem relating to the relevant info

    • Test is completed:

      • Change Kanban tag to: Done

      • Contact sender if required with resolution info of the case

  • Check if there are related cases that should be also closed or responded.

  • Check if relevant tags are added/removed.

  • Documentation required

    • Add tag ToBeDocumented

    • Assign case to person in charge of documentation

  • Documentation not required

    • Close the case

Require documentation

  1. When start to document add tag CurrentlyDocumenting

  2. Remove tag ToBeDocumented

  3. After documentation completed

    • Remove tag CurrentlyDocumenting

    • Close case

Unrelated Cases

IKMD Team gives technical support to members of the Cochrane Collaboration. External users are not supported.

Examples from Authors

  • Problem with Check In/Check out reviews due to version number - Contact first Entity Manager Editor

  • Statistical questions - Contact first Entity Manager Editor

APPENDIX

Templates

ACTION Crossref with https://helpdesk.cochrane.org/default.asp?pg=pgSnippets

Unrelated case

Dear XXX,

Thank you for your email, but I am afraid that IKMD Team is not the relevant entity to solve this problem. Please contact XXX, who will be able to answer your question.

Similar case not yet solved

Dear XXX,

Thank you for the information. This bug was previously reported and we are working on it to try solve it. As soon as new information will arrive we will contact you. Please keep us updated if further info arise.

Case in process

Dear XXX,

Thank you for the information. We are working in the solution of your case, and as soon as will have new information we will contact you. Please keep us updated if further info arise.

Case in process and reassigned

Dear XXX,

Thank you for the information. I have assign the case to one of our developers and as soon as we will have new information we will contact you. Please keep us updated if further info arise.

Tags

List of relevant tags to add to cases:

  • ToBeDocumented

  • CurrentlyDocumenting

  • ToBeTested

  • CurrentlyTesting

  • onDevelopment

  • ...

Save