Version 7
Created by jbalunas on Jul 15, 2009 3:06 PM. Last modified by bleathem on Mar 6, 2012 1:40 PM.

    This guide documents the lifecycle of a jira issue for the Richfaces project.

     

    Table of Contents:

     

     

    Important links


    Lifecycle of an issue

    Overall the lifecycle of an issue that is supposed to be implemented (i.e. not rejected) is as follows:

     

    1. Someone creates an issue
    2. If it is a relevant issue a committer assigns it for a fix version
    3. A committer fixes the issue and resolves the issue
      1. Previously the committer would assign to QE
        1. This causes confusion when finding who worked on the issue
        2. QE can search for resolved (not closed issues)
    4. QA verifies resolved issues as
      1. Closed or
      2. Reopened if the issue is not fully resolved and then goto #3

    Creation

    Anyone can create an issue. For deatils on how to write an effective issue, refer to the guide: Submitting effective issue reports

     

    Note: Issue assignment should only be done by the proejct committers.

     

    Assessment

    Once an issue has been created, it sits in an unscheduled queue, until it's been reviewd by one of the project committers.

    There are a number of jira issue queries that are useful when assessing new issues:

    1. Unscheduled Unassigned RichFaces issues
      • This queue is for new issues that are awaiting assement or scheduling
    2. RichFaces Issues Awaiting Assesment
      • This queue is for issues awaiting assessment or verification from the project committers and or QE team
    3. Unscheduled waiting_on_user RichFaces issues
      • Issues where assessment progress is blocking on user feedback

     

    Scheduling

    Issues are scheduled accoring to the following numbering scheme:

    • 4.X.M# / 4.X.#
      • The issue fix is scheduled for inclusion in a specific milestone / micro release
    • 4.X-Tracking
      • The issue is "tracking" a release, this means that as progress is made on a release, issues will be pulled from this queue for inclusion in a specific milestone or minor release.
      • Issues targetting a "tracking" release that are not resolved by release time will most likely be rolled in to the "tracking" version of a subsequent release
    • 4-Future
      • Issues here fall into one of two categories
        1. The issue will be addressed in a future release, but has not yet been scheduled
        2. While the issue is sound in principle, there is no current plan to address it in the current project roadmap
          • Such issues are tracked to gaugue community interest
          • Community members are always welcome to resolve these issues and submit a pull request to the project

     

    We need to address the ambiguous nature of the 4-Future jira version, by seperating out issues.  As it stands now, it's unclear which of the two cases apllies to an issue currently scheduled for "4.Future".

     

    Assignment

    Only committers/developers should assign the issue. Do not assign the issue to anyone unless it is yourself or you know for sure he or she is supposed to work on the task. If all issues are assigned we cannot see which are unassigned and needs attention.

     

    The one who assign should also make sure to set:

    • the Fix Version(s) to indicate when it should be completed, without a Fix Version it will not show up in the Road Map nor Change log
    • the Priority should be set in context of the Fix Version, i.e. an issue can be trivial to implement but still be a Blocker if it is a must have feature or bug to have for the release.

    Discussions

    Keep the description/comments updated as work progresses.  This means comments related to reproducing, fixing or implementation requirements should be added.  That saves time for anyone who is working with this issue to understand what actually should be done and how to verify it.  This is also useful for QE to reproduce and and verify the fix.

     

    Discussions in  jira should be limited strictly to items related to the reproduction, description, and resolution of the issues.  It should not evolve into a forum like discussion of questions.  These are best moved to the forums.

    Fixing/Resolving

    Issues fixed via community contributions should be placed in the state "Pull Request Sent".  Issues currenlty in this state are listed in the following jira filter:

     

    https://issues.jboss.org/secure/IssueNavigator.jspa?mode=hide&requestId=12316821

     

     

    When an issue gets fixed the developer should make sure to:

    • Add unit tests
      • Any non-trival issue is not considered fixed and should not be committed before there are unit tests for it
    • List the JIRA URL(s) in the relevant commit(s) (e.g. https://jira.jboss.org/jira/browse/RF-42 ) together with a short comment on what was done
    • Resolve (not Close) the issue
    • Comment on what was done, i.e. sometimes "Done" is fine but if something were done differently than initially discussed in the jira or one of multiple options were implemented state which one and if some new api/feature was introduced put an explanation on how to use it.
    • If the change, fix, or feature affects documentation check the "Affects Documentation" checkbox.
    • Describe how QE should verify the issue, or feature.  This may include EXECUTE/ASSERT statements, test cases, descriptions, and/or selenium test suggestions.  Some issues may not need this, but most do.
    • Consider if issue needs explicit QE verification prior the release process  - if issue needs explicit verification, label the issue with "needs-qe" label - this issue would be verified for regressions prior the implicit QE phase - this typically includes issues when components gets new features, bug fixes are critical etc.
    • Verify the Component and Fix Version is correct, remember that if we have branched for doing a release and you fixed the issue in both branches set both related versions (i.e. 4.0.0.BETA1 and 3.3.1.CR1), if you only fixed it in one branch/trunk make sure you select the correct version.

     

     

    QE/Closing/Reopen

    QE periodically checks RichFaces - Needs QE filter for issues which needs to be investigated prior release QE phase.

    • when JIRA doesn't contains enough info about developer's concerns
      • JIRA is reopened (and assigned to resolver)
    • if issue contains enough info
      • QE implements tests for covering issue and closes closes issue as tests are integrated into suite

     

     

    During QE release phase  a committer or QE engineer verifies the issue following the description and/or EXECUTE/ASSERT instructions and if the issue is resolved QE should:

    • Verify the Component and Fix Version is correct
    • Close the issue
    • Comment with which build/setup he verified it in

     

    If the issue is not completed then:

    • Reopen the issue
    • Comment what is not working
    • If needed assign the issue back to the developer who resolved it.