Jira Tips and Tricks: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
m (WindJunkie moved page Jira Tips & Tricks to Jira Tips and Tricks: remove "&" from title for better linking)
(Reflect recent discussion and decision to shorten the wait until issues move out of NMI due to new info being made available.)
 
(9 intermediate revisions by the same user not shown)
Line 8: Line 8:
   
   
  * [https://confluence.atlassian.com/jira064/advanced-searching-720416661.html Jira's JQL documentation]
  * [https://confluence.atlassian.com/jira064/advanced-searching-720416661.html Jira's JQL documentation]
* [https://confluence.cprime.io/display/CADS/AMU+-+Using+JQL+functions AMU Utils JQL]
  * [https://sweetbananas.atlassian.net/wiki/spaces/JBP/overview JQL Booster Pack]
  * [https://sweetbananas.atlassian.net/wiki/spaces/JBP/overview JQL Booster Pack]


Line 15: Line 14:
=== Need More Info (NMI) handling ===
=== Need More Info (NMI) handling ===


Qt's bug tracker utilizes the "Need more info" (NMI) state which indicates that the current assignee of a issue or bug requires more information from the reporter. The issue remains in the state until the reporter has provided the requested information. The information can either be provided by commenting or updating the issue description. Once the info was provided, the reporter must transition the issue out of the NMI state by pressing the "Provide Missing Info" button. The overall purpose of this state is to ensure bug reports with as much information as possible and being able to identify incomplete ones.
Qt's bug tracker utilizes the "Need more info" (NMI) state which indicates that the current assignee of an issue or bug requires more information from the reporter. The issue remains in the state until the reporter has provided the requested information. The information can either be provided by commenting or updating the issue description. Once the info was provided, the reporter must transition the issue out of the NMI state by pressing the "Provide Missing Info" button. The overall purpose of this state is to ensure bug reports have as much information as possible and being able to identify incomplete ones.


Unfortunately not every reporter (especially reporter new to the Qt community one) is aware of the obligation. Therefore an automated cleanup procedure is employed to remind reporters of their obligation and (if necessary) prevent issues from being stuck in the "Need More Info" state. After two weeks of inactivity a reminder is posted to the Jira issue stating the expectations from the reporter and another two weeks of inactivity automatically close the issue (with an automated explanation).
Unfortunately not every reporter (especially a reporter new to the Qt community) is aware of the obligation. Therefore an automated cleanup procedure is employed to remind reporters of their obligation and (if necessary) prevent issues from being stuck in the "Need More Info" state. After two weeks of inactivity a reminder is posted to the Jira issue stating the expectations put towards the reporter and after another two weeks of inactivity automatically close the issue (with an automated explanation).


The following table provides a summary of the automated handling in Jira. Workflow conditions are recorded via Jira labels. At the same time manual control of the cleanup procedure by the experienced users is permitted. The table assumes that the issue at hand is in the NMI state.
The following table provides a summary of the automated handling in Jira. Workflow conditions are recorded via Jira labels. At the same time manual control of the cleanup procedure is permitted for the experienced users.
 
==== Automation rules ====
 
Upon transitioning an issue into the NMI state the initial NMI label is set by the system and activity monitoring is started. The table below shows the automation reaction once the Jira issues NMI state has been reached.


{| class="wikitable"
{| class="wikitable"
|-
|-
! Set issue label !! Expectation !! Automated handling
!Rule No
! Currently set label !! New/incoming user activity !! Automated handling reaction
|-
|1
| Any combination || A comment from the assignee is added. || The NMI label is renewed. RNMI is removed. We are waiting for more info.
|-
|2
| NMI label set|| A comment from the reporter or an unrelated user is added. || The NMI label is unset. Continues with Rule 1, 4 or 7.
|-
|3
| <<No NMI label>> ||  <<No Activity>> || Issue will be transitioned back to "Reported" state (after three days without activity). The assumption is that further information was provided but the user forgot to transition the issue.
|-
|4
|NMI label set
|<<No Activity>>
|After two weeks post reminder and set RNMI.
|-
|-
| NMI label set|| The reporter must provide additional information and should transition the issue out of NMI. Any comment from the assignee will unset the NMI label || After 2 wks of no activity, the RNMI label is set. Setting of the RNMI label will trigger the posting of a comment to the reporter.
|5
| NMI & RNMI label set || A comment from the reporter or an unrelated user is added. || NMI and RNMI labels are unset. Continues with Rule 1, 4 or 7.
|-
|-
| NMI & RNMI label set || NMI and RNMI will be unset if the reporter posts a comment. || After 2 wks of no activity, the issue is automatically closed with an appropriate message.
|6
|NMI & RNMI label set
|<<No Activity>>
|After two weeks of no user activity, the issue is automatically closed with an appropriate message.
|-
|-
| <<No NMI label>> || Any comment from the assignee renews the NMI label. || Issue will be transitioned back to "Reported" state (after 1 day without activity). The assumption is that further information was provided but the user forgot to transition the issue.
|7
| Any combination || User moves issue out of NMI state. || All labels associated with tracking are removed.
|}
|}


Line 47: Line 70:
* Edit, close, move, transition issues (if assignee)
* Edit, close, move, transition issues (if assignee)
|-
|-
| Triager || The user can reassign any issue to a different user including him/herself. This permits the user to elevate their own permissions to the set of capabilities given to the issue's assignee. ||
| Triager || The user can reassign any issue to a different user including him/herself. This permits the user to elevate their own permissions to the set of capabilities given to the issue's assignee. This right can be obtained by contacting Jira admins under jira-admin@qt-project.org. ||


* Reassign issues to other users including own account
* Reassign issues to other users including own account

Latest revision as of 10:52, 1 August 2024

This page describes automated processes and features which might be useful to understand when working with Qt's bug tracker Jira https://bugreports.qt.io

Extended Search Capabilities

Jira uses JQL to allow the user to find issues with certain criteria. Out of the box the language provides a relatively large set of operators, function and keywords. However, there are corner cases when those capabilities are not sufficient. For example, the default JQL set does not allow the search for "issues on which user xyz commented on during the last 24h" or "issues whose version field matches a regular expression". To enable some of those more obscure use cases Qt's bug tracker extend the default JQL language set using custom plugins. The list below provides a summary 

* Jira's JQL documentation
* JQL Booster Pack

The auto completion feature of Jira's JQL search field provides a limited discovery of those additional capabilities too.

Need More Info (NMI) handling

Qt's bug tracker utilizes the "Need more info" (NMI) state which indicates that the current assignee of an issue or bug requires more information from the reporter. The issue remains in the state until the reporter has provided the requested information. The information can either be provided by commenting or updating the issue description. Once the info was provided, the reporter must transition the issue out of the NMI state by pressing the "Provide Missing Info" button. The overall purpose of this state is to ensure bug reports have as much information as possible and being able to identify incomplete ones.

Unfortunately not every reporter (especially a reporter new to the Qt community) is aware of the obligation. Therefore an automated cleanup procedure is employed to remind reporters of their obligation and (if necessary) prevent issues from being stuck in the "Need More Info" state. After two weeks of inactivity a reminder is posted to the Jira issue stating the expectations put towards the reporter and after another two weeks of inactivity automatically close the issue (with an automated explanation).

The following table provides a summary of the automated handling in Jira. Workflow conditions are recorded via Jira labels. At the same time manual control of the cleanup procedure is permitted for the experienced users.

Automation rules

Upon transitioning an issue into the NMI state the initial NMI label is set by the system and activity monitoring is started. The table below shows the automation reaction once the Jira issues NMI state has been reached.

Rule No Currently set label New/incoming user activity Automated handling reaction
1 Any combination A comment from the assignee is added. The NMI label is renewed. RNMI is removed. We are waiting for more info.
2 NMI label set A comment from the reporter or an unrelated user is added. The NMI label is unset. Continues with Rule 1, 4 or 7.
3 <<No NMI label>> <<No Activity>> Issue will be transitioned back to "Reported" state (after three days without activity). The assumption is that further information was provided but the user forgot to transition the issue.
4 NMI label set <<No Activity>> After two weeks post reminder and set RNMI.
5 NMI & RNMI label set A comment from the reporter or an unrelated user is added. NMI and RNMI labels are unset. Continues with Rule 1, 4 or 7.
6 NMI & RNMI label set <<No Activity>> After two weeks of no user activity, the issue is automatically closed with an appropriate message.
7 Any combination User moves issue out of NMI state. All labels associated with tracking are removed.

Jira permissions

The Jira bug tracker utilizes three general permission levels obtained by users (apart from Jira Admin permissions). The below table summarizes the different levels and outlines their individual capabilities. The rights

Permission Level Description Capabilities
User This permission level is the default permission for every user.
  • Create issues
  • Comment on every issue.
  • Edit & close own reported issues
  • Edit, close, move, transition issues (if assignee)
Triager The user can reassign any issue to a different user including him/herself. This permits the user to elevate their own permissions to the set of capabilities given to the issue's assignee. This right can be obtained by contacting Jira admins under jira-admin@qt-project.org.
  • Reassign issues to other users including own account
Open Governance Approver The user can edit just about any issue independent of whether he/she is assignee or reporter. This level can be reached by being a contributor to the Qt project and having been granted OG Approver rights as per Open Governance (see Qt Governance Model)
  • All the above permissions w/o need to reassign to own account.

Note that some projects have individual permission sets which may differ from the above configuration.

Retrieved from "https://wiki.qt.io/index.php?title=Jira_Tips_and_Tricks&oldid=42083"