Issue Triage Process

[resplin]

This page documents the process we are using to triage issues reported in the public issue tracker at:
http://issues.alfresco.com

The process for reporting a good bug is documented on the page Reporting an Issue

These instructions are to be followed by Alfresco Engineering. We document them here so you can understand what we are doing. Please don't ruin our process!

• How Alfresco Manages Issues
• General Guidelines
• Component Lead
• ALF Triage Sessions
• Questions on Triage Process
• Assigning to MNT
• Assigning to ACE or a Delivery Team
• Useful Queries
• Patch Attached
• Query
• Community Stars
• Query
• Closing Old Issues
• Query

How Alfresco Manages Issues

General Guidelines

• Subscribers to Alfresco One Enterprise Edition are expected to raise issues through Alfresco Support in order to take advantage of the support response times. Issues raised through Alfresco Support take precedence over issues raised by the public in Alfresco's issue tracker.
• Triage processes are focused on making fast decisions so we can maintain a high throughput of issues. Instead of spending lots of time researching, reproducing, and discussing, we will quickly act on an issue by escalating it, sending it back to the reporter, or closing it. If you care about an issue that was closed or sent back to the reporter, please add the necessary information for us to reevaluate the issue.
• It is the responsibility of the reporter to provide an issue that is easy for us to reproduce starting from a standard installation of Alfresco. Our experience is that a large portion of the issues that are reported in our public issue tracker are unclear, are attributable to problems in the reporter's environment, or for other reasons cannot be shown to be an issue that requires a fix to the product. We need to be careful not to occupy the time of the engineering team with these issues. Reporters should investigate issues before reporting them. Reporters can seek assistance in creating useful issues from volunteers in the Alfresco forums, or contract with an expert for assistance.
• In order to escalate an issue, we need to reproduce it on the latest release of Alfresco. Because Alfresco One Enterprise Edition and Alfresco Community Edition are two products from the same code base, we reproduce issues on whichever environment seems most convenient when we review the issue. Issue reports should have instructions for reproducing the issue starting from a clean install and detailing any customizations and configurations necessary to see the issue.
• Old issues in the ALF project are closed when a new GA release of Alfresco Community Edition is made available. See below for more details.
• When an ALF issue is understood to require a product change, it is cloned to the relevant project where it can be assigned to a sprint backlog. The cloned issue can then be rewritten so that the implementor can easily follow the request, or it can be combined with other issues as part of a larger project. When the delivery team has completed their effort, they should return to ALF and close the original issue.

Component Lead

The first touch is the component lead. If the issue can be immediately acted on, then the component lead does so. If the component lead chooses to act on an issue, he or she should go through the same actions as the ALF Triage team would (see the next section). If the component lead sees an issue that needs additional consideration before it can be acted on, verify that 'Triage' = 'To Do' and unassign the issue so that it gets picked up in the ALF Triage.

ALF Triage Sessions

New issues created in the ALF project have a 'Triage' = 'To Do'. A few times a month, Product Management and Engineering hold a triage session for ALF issues to review them.

Filters:

• Issues created since the last session
• 'Triage' = 'To Do'
• Label = 'CommunityPainPoints'
• Patch Attached = True
• Assignee = 'POUnassigned'
• Assigned = 'resplin' or 'mbergljung'

For each issue, the ALF triage team takes an action:

Actions include:

• If the issue is immediately actionable, clone the issue to the project used by the relevant delivery team so that it can be put in a sprint backlog. Set the ACT number as 'Community' so that the source can be easily identified in reports.
• If the issue seems like a legitimate concern, but the correct delivery team is not obvious, clone the issue to ACE so that it is included in the next ACE Triage.
• If the issue is clearly a bug and needs fixing in the next service pack, assign to MNT by following the guidelines on this page.
• If the issue needs consideration from Product Management, assign to the appropriate PM to respond (this might require assigning to Richard to probe the Product Manager).
• If the issue is not a bug, or cannot be reproduced, or for other reasons is unlikely to ever be addressed, then close immediately as 'Won't Fix'. Please leave a comment about your reasoning!
• If additional information from the reporter would help, or the issue is not clear, then assign back to the reporter, mark the issue as 'Need Info', and provide a comment indicating what information you need.
• If additional information from the component lead would be helpful to make a determination or to go back to the reporter, then assign the issue to that component lead with a comment containing your request. Follow up in the next Triage session.
• If the issue needs additional consideration before it can be acted on, verify that 'Triage' = 'To Do' and unassign the issue so it is included in the next ALF Triage.

If an issue has been triaged and does not need further follow up, the 'Triage' field should be set to 'None'.

Questions on Triage Process

• When is a patch significant enough that we are required to get a contributor agreement? (question for legal)
• What is the criteria for issues that can go into MNT? (I created an initial list above that need to be reviewed)
• Components may be owned by teams or practices rather than individuals. While a single person may have an overview of a component how does a team. In particular how do I know which issues have been looked at by my colleagues—or more importantly, not looked at.
• How do we get proper Product Management review of issues that are created?

Assigning to MNT

To assign an issue to MNT for Expert Support to engage:

• Clone the issue
• Make sure the cloned issue meets the criteria in the next section
• The issue Description must be written according to the template:
  
  • Description
  • Steps to reproduce
  • Expected Behaviour
  • Observed Behaviour
  • Analysis to date
• Move the cloned and cleaned issue to MNT, assigned to 'automatically assigned', state = New
  
  • Issue Type: Service Pack Request
  • ACT Number: 'Community'
  • Affects Versions: MNT has no Community versions. 'Community 5.0' becomes '5.0' and 'Community 4.2' becomes '4.2'. Do not use '5.0.N' or '4.2.N'
  • If the Affects Version is for a version of Community Edition corresponding to an as of yet unreleased version of Enterprise Edition, the report should go to ACE instead of MNT.
  • Consider setting the 'Regression Since' field
  • The Security Level in MNT defaults to 'internal', but should probably be 'public' for an issue moved from ALF.
  • Audit the Component and Priority fields.
  • Execute the Workflow through the 'Triage' state to the 'New' state.
  • Should end up assigned to 'Sustaining Support'

Criteria for MNT:

• Affects customers using previously released versions of the software
• Does not add functionality or change the user interface
• Can be fixed without changes to the database schema or method signatures
• Will not require a reindex

Expectations:

• The Export Support team is expected to deal with 2-3 issues ACT = 'Community' issues a week. Turn around time on a fix is 1-2 quarters, but hopefully will average less than 1 quarter.

Assigning to ACE or a Delivery Team

Issues sent to ACE or to a specific delivery team are meant to be included in the next release of Alfresco. These development issues get assigned to a sprint backlog as follows.

Engineering led improvements:

• Criteria: Hygiene, Performance Improvements, Technical Ideas
• Must either be accepted by the component owner
• Or must meet the criteria to be reviewed in the ACE Triage meeting, and thereby be assigned to a backlog

Product management led improvements:

• Criteria: New features
• Assign to a specific PM to consider for inclusion in the backlog (P.O. Unassigned as a last resort)

Useful Queries

Filters created by the team:
https://issues.alfresco.com/jira/issues/?filter=18143
https://issues.alfresco.com/jira/issues/?filter=18145

Patch Attached

We added a box to flag when a patch is attached to an issue.

We try to look at issues with a patch attached first. If someone cared enough about an issue to attach a patch, it is likely either an easy fix or an important issue. Further, having a patch attached should make an issue easier to analyze and duplicate. Finally, by addressing issues with patches attached, we encourage future contributions.

If a patch is substantial, and becomes the basis for our efforts rather than just a reference point, we should get a Contribution Agreement and send it to Alfresco Legal.

Query

You can search for open issues with patches attached as follows:

Project = 'ALF' AND 'Patch Attached' IS NOT EMPTY AND resolution = Unresolved AND (status = Open OR status = Reopened) ORDER BY updatedDate DESC

Community Stars

We created a 'Community Stars' group for JIRA participants who we trust will make good reports. The initial members consist of people who:

• have previously had contributions accepted to Alfresco (http://wiki.alfresco.com/wiki/Featured_Contributions),
• presented a Tech Talk Live talk in the past two years (http://wiki.alfresco.com/wiki/Live),
• or have otherwise been recognized as being a valuable participant on a JIRA issue through usefully reproducing, testing, debugging, or contributing a patch.

Add Community Stars by creating an IT issue.

Query

To search for open issues reported by Community Stars:

Project = 'ALF' AND Creator in membersOf('Community Stars') AND resolution = Unresolved AND (status = Open OR status = Reopened) ORDER BY updatedDate DESC

To search for issues where a Community Star commented:

Project = 'ALF' AND issueFunction in commented('inGroup 'Community Stars'') AND resolution = Unresolved AND (status = Open OR status = Reopened) ORDER BY updatedDate DESC

By looking at these issues first, hopefully we spend a higher percentage of time dealing with high quality issue reports.

Closing Old Issues

Each new release of Alfresco contains many improvements to address old problems. In order to prioritize our efforts, when we release a new version of Alfresco Community Edition, we close:

• issues that are over a year old, and that have no affectsVersion declared,
• issues with affectsVersion that only contains unsupported versions of Enterprise Edition,
• issues with affectsVersion that only contains releases of Alfresco Community Edition older than the previous old version (two releases back).

Make sure to leave a comment like this:

This issue was reported against an old version of Alfresco Community Edition.Alfresco ____ was recently released, and contains many improvements that address old problems. We are closing old issues so that we can better prioritize our efforts.If you verify that the issue still exists in Alfresco ____, please reopen the issue. If you have any trouble reopening the issue, then leave a comment or email us at community@alfresco.com so that we can assist.Thank you for collaborating with us on improving Alfresco.Sincerely,_____

Query

Here is the query we use.

project in (ALF, ACE, SHA) AND Resolution = Unresolved AND Status != 'Won't Fix' AND affectedVersion in ( . . . ) AND affectedVersion not in ( . . .)

ScriptRunner versionMatch would make this much easier, but it isn't working for some reason.