Jira management
Atlassian JIRA (v4.4.3#663-r165197)
1. System
General configuration-Click Edit configuration… we can modify default language(EN is recommended)
2. Issues
2.1 Issues created Automatically Assign to Project Lead or Component Lead
-Component Lead has higher level than Project Lead(that is, if component is unassigned and default assignee is Project Lead for project, then issues will not be assinged to Project Lead automatically)
-The default assignee should has assignable permission(see permission scheme)
So below configurations are fine:
---System->General Configuration: Allow unassigned issues should be OFF (it is off by default)
---Specify a project lead, and default assignee is project lead
---Specify a component lead, and default assignee is component lead or project lead(Note: Specify default assignee as Unassigned is not recommended, if we set a component as Unassigned and select a component when creating a issue, then the issue will not be assinged to default assignee.)
---The project lead or compomnet lead should has assignable permission(permission scheme)
If we miss any of them, the error will pops up like: The default assignee does NOT have ASSIGNABLE permission OR Unassigned issues are turned off
2.2 Workflows-Workflow schemes
A workflow need to assign to a workflow scheme.
We need to create a customized workflow and a customized workflow scheme to satisfy the requirement of automatic assigning the issue to reporter after resolving
Add a post function 'assign to reporter' in transition'resolve issue'
----Assigning issue to reporter automatically is not fine, because for most time, all people can file issues(bug, new feature, improvment...) in Jira, so all the bugs resolved should be assigned to QA lead instead of reporter automatically.
So the workflow need to be re-designed.
We need to install a plugin to implement the workflow: JIRA Misc Workflow Extensions
- Administration>Plugins>Install> or Download it from https://plugins.atlassian.com
- Go to workflow, and steps>Transition(Resolve Issue)>Post function: Assign the issue to the default user from the QA Lead role (we need to add a role including only one person for current project(QA Lead))
3. Users
• Users, groups, project roles, permissions
○ Create users
○ Create groups(assign users to relevant groups) It is much better not to use default groups. We create a jira-qas group.
○ Create project roles(Here we create a QA role)
○ New permission scheme, and assign permissions to users/groups/roles
• Three default groups(jira-administrators, jira-developers, jira-users)
• Three default project roles(Administrators, Developers, Users).
• Permission has 2 types: Global permission and Project permission
• Global permission is independent with Project permission.
• It is much better to leave Global permission as it is.
• It is much better to create a new customized permission scheme instead of using default permission scheme.
• How to new a customized permission scheme:
• Make a copy of default permission, and make some changes according to requirement.
• (e.x. I create a new permission scheme, and just modify the 'Issue Permissions'.
As a QA:
○ Edit Issues
○ Assign Issues
○ Resolve Issues(because QA need to reopen a bug)
○ Close Issues
○ Link Issues
)
4. Projects
• Create a new project
• Default groups and roles will be connected automatically. Surely, we can modify it.
• Modify people in the project
• Modify permission scheme using new customized permission scheme
• Modify workflow scheme using new customized permission scheme(Backup is recommended if the project has data before changing)
5. A user must be in jira-users group even if he is in jira-developers(except the user is in jira-administrators), then the user can login jira
6. Dashboard
We can Configure system dashboards, and add some useful gadget:
Road Map: display incoming release
Issue Statistics: display all project statistics, assingee statistics,reporter statistics,priority statistics, .....(Note, for project statistics, the filter should be shared to all users, or there will be an error for the user without access to the filter)
Created vs Resolved Chart: We can include unresolved chart
Issues in progress: status = 'In Progress' AND resolution is EMPTY AND assignee = currentUser() ORDER BY priority DESC, created ASC
Assigned to me(suitable to devs): assignee = currentUser() AND resolution = unresolved ORDER BY priority DESC, created ASC
Favorite Filters:Here we can create our favorite filters like below
Assigned to me(QAs): assignee = currentUser() AND status = Resolved ORDER BY priority DESC, created ASC
This can be only shared to jira-qas group.
Admin gadget: Just for users in jira-administrators
7. Notifications
We should associate Notification Scheme to Project after we configure Mail servers. If not, the notification will not be sent out automatically to appropriate people of particular events in your project. We don't need to create another scheme, just use the default one.
PS: We can also add new notification scheme through a copy of default.
8. Mail Servers
System-Mail...-Mail servers(smtp)
9. Versions
This is associated with a project. This associates with affect version/fix version. Test/File an issue/Resolve an issue are all based on the version(a stable and testable version). Version control is important.
10. Priority
THe issues' priority is important, it stands for its importance. We often resolve the issue firstly whose priority is high(blocker, critical, major, minor, trivial)
Blocker: Blocks development and/or testing work, production could not run.
For this priority, we need time limit to resolve it, even if we have no solution, the dev still has to give a feedback.
Critical: Crashes, loss of data, severe memory leak.
For this priority, we need time limit to resolve it, even if we have no solution, the dev still has to give a feedback.
Major: Major loss of function.
Minor: Minor loss of function, or other problem where easy workaround is present.
Trivial: Cosmetic problem like misspelt words or misaligned text.
