[Deploying Sakai] Ask the community: Your institution and Sakai bug reports
sfoster9 at uwo.ca
Fri Jan 30 10:51:15 PST 2015
Thanks for your response, Trisha. We have similar thoughts and
processes, but we were just wondering about how much time we should
devote to bug reports and if these actions were common in the community.
eLearning Technology Support and Application Development
Information Technology Services
London, Ontario, Canada
On 15-01-30 1:32 PM, Gordon, Patricia S. (Trisha) (psg3a) wrote:
> Great questions! I¹ve embedded responses to your questions below that we
> employ at the University of Virginia.
> Trisha Gordon
> Director, UVaCollab Applications & Support
> University of Virginia
> On 1/30/15, 12:45 PM, "Shawn Foster" <sfoster9 at uwo.ca> wrote:
>> Some questions about Sakai bug reports:
>> 1. Does your instance of Sakai generate bug reports? YES
>> 2. How does your institution deal with bug reports generated from Sakai?
> What we do depends on the type of bug report. Here are a few of the
> scenarios we address:
> * We follow-up with the user for any bug report with a *comment*
> (³comment" will appear in the subject line as well as in the body of the
> ** We contact the user whether or not they have entered text into the
> comment because we know these types of bug reports indicate that an error
> was displayed to the user.
> ** We identify the site and the tool involved in our response to the user
> (based on the Requested URL found in the bug report).
> ** Sometimes we can determine the nature of the problem by the stack
> trace/tool and sometimes not. When we¹re not sure, we ask the user to
> provide details about the action that seemed to trigger the error to help
> us troublehsoot. If the bug is known but relatively benign (such as
> evidence that the user clicked the Back button on the browser and
> encountered a NPE), we provide a standard response to help the user avoid
> that problem in the future.
> * A sudden large influx of bug reports with the same identifier string in
> the Subject line gets our attention pretty quickly.
> ** Initially, we look for commonalities in the bug reports and our
> response depends on what is at issue: e.g., is it from only one or sub-set
> of our front-end servers? (we pull the server(s) out of rotation asap).
> ** Sometimes it might be determined to be an incident (and a response team
> gets busy to manage and resolve it) and other times it might be a single
> frustrated user repeatedly clicking a button.
> ** Bottom line: These types of bug reports require a closer a look as
> quickly as possible.
> ** Part of our procedure will be to look for a report of the error on the
> Sakai community jira or mailing lists and apply a patch if one is
> available. Otherwise, we will send out email to the community mailing
> list(s) and/or our contracted vendor for additional guidance/help. If our
> developers are able to find and fix a problem in the code, we¹ll apply the
> fix locally and contribute the patch back to the community Jira.
> * We've learned which bug reports can be ignored, which will be most of
>> 3. Does someone at your institution read/monitor the bug report email?
> We do. See Q2
>> 4. Do you follow up with your users who leave comments?
> See Q2.
>> 5. Do you follow up with your users who don't leave comments but who
>> cause a bug report?
> Usually not.
>> Thanks for your opinions and anecdotes,
>> Shawn Foster
>> eLearning Technology Support and Application Development
>> Information Technology Services
>> Western University
>> London, Ontario, Canada
>> production mailing list
>> production at collab.sakaiproject.org
>> TO UNSUBSCRIBE: send email to
>> production-unsubscribe at collab.sakaiproject.org with a subject of
More information about the production