[WG: Accessibility] FW: [DG: User Experience] Jira practice for Sakai 3 UX project

[Richwine, Brian L]

Hi,

Here is a message that went out on a few other lists. It is the start of a discussion on clarifying JIRA ticket practices for Sakai 3. Especially interesting, given our discussion about choosing an appropriate priority level are the definitions given for the various priorities below.

-Brian

-----Original Message-----
From: sakai-ux-bounces at collab.sakaiproject.org [mailto:sakai-ux-bounces at collab.sakaiproject.org] On Behalf Of Oszkar Nagy
Sent: Friday, April 23, 2010 7:13 AM
To: Sakai UX List; Sakai UI Dev List; Nakamura List
Subject: [DG: User Experience] Jira practice for Sakai 3 UX project

Hi,

Now that QA efforts are ramping up and the number of JIRA tickets is 
increasing I thought it would be good to set up some simple and 
effective JIRA practices to manage a future larger volume of tickets.

Here is what I propose, based on discussions with Alan and some feedback 
from Anthony. The definitive Sakai JIRA guide is here:
http://confluence.sakaiproject.org/display/MGT/Sakai+Jira+Guidelines
but I thought we should clarify some things in context of the Sakai 3 UX 
project.

Please let me know your thoughts.

What is JIRA for?
This should be evident, but just for clarity I would like to state it it 
here again.
The Sakai 3 UX JIRA space ( http://jira.sakaiproject.org/browse/SAKIII ) 
is for tracking bugs and work on all Sakai 3 front-end related things. 
The space is open and accessible for everybody, everybody can 
contribute, create and access tickets. (for assigning tickets you'll 
have to be in sakai-dev JIRA group which I believe developers from all 
participating institutions are members of) All communication and 
contribution is open and public.

Creating tickets:
I would say we should create a ticket for every real bug, implementation 
task or feature request. Incoming cleaned up wireframes and design 
screens should be attached to implementable screen tickets. However if 
setting up a JIRA ticket takes longer that to fix something 
cosmetic/minor bug, I would say we shouldn't create a ticket for it just 
for the ticket's sake, unless there is a specific need for publishing 
the issue.

Assigning fix versions:
I think it would be good for everybody to specify a fix version when a 
ticket is created, showing intent and an objective guess based on 
currently available resources. From time to time the project lead / core 
developers might move tickets around, based on available resources, 
available time and current project priorities based on design outputs. 
If a fix version can not be guessed leave it unscheduled and core 
developers or the project lead would assign a fix number ASAP, 
preferably daily. This is to ensure that we don't end up with a big lump 
of unassigned JIRAs as it happened before on other Sakai projects. If 
there is no time to fix all issues in a specific version they will 
automatically go to the next version and re-scoped.

Scoping period
After each release there should be a scoping period where the project 
lead would clean up and re-scope all tickets for the next release. This 
mostly means dealing with leftover tickets from previous release and 
distributing them according to available release and a

Priority:
In context of the Sakai 3 front-end project. I now these are subjective 
but I will attempt to add some clarifications:

Blocker
Release will not be completed until issue is resolved.
- breaks the build process
- causes the UI to not start up or function at all
- renders an area of finished functionality unusable for most users
- not completed task which is needed for the kernel to function

Critical
Issue will most likely be resolved for release.
- major browser incompatibility
- renders an isolated particular feature completely unusable
- affects kernel - front-end communication
- major accessibility issue
- major security issue

Major
Issue should be resolved for release.
- majority of bugs and tasks
- if unsure, chose this

Minor
Issue may be resolved for release.
- issues and bugs which can be fixed with entry level knowledge
- does not affect functionality in any way, presentation may be broken

Trivial
Issues that might be resolved before a release.
- cosmetic issues, which only visually affect users
- fix is evident, and stated in the JIRA comment

Assigning/Unassigning/Closing tickets:
As per normal Sakai JIRA practice, each ticket should go in unassigned. 
When a developer starts working on an issue he/she should assign the 
ticket to him or herself. When the issue is fixed AND merged into the 
master branch the developer who worked on the issue should close the 
ticket as fixed.

Linking, subtasks etc...
My view on this is that we should link issues which closely relate to 
kernel tickets, because it's easier to track if they are dependent. We 
should also subtask big tasks which we know will take several weeks. 
Apart from these I see no point in "overorganising" the tickets unless 
there is a specific need for documentation purposes.

Time tracking:
I think current resources barely allows us to maintain effective JIRA 
management and we can barely scope issues to specific releases, so IMHO 
we should not to time tracking in JIRA.


Any comments/suggestions welcome,
Oszkar






_______________________________________________
sakai-ux mailing list
sakai-ux at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"