Version 4
Created by jbalunas on Jul 14, 2009 9:18 AM. Last modified by jbalunas on Jan 6, 2010 11:36 AM.

     

    The RichFaces project uses two different jira projects.  The RF project is a typical JBoss project jira used for tracking bugs, feature requests, and changes for the RichFaces releases.  The RFPL project is for planning activities and tasks that are not directly related to changes in a release.

     

    The goal is to have the RF project represent only what has been fixed, added to, or changed in a release, and not be cluttered with macro jiras that cover project plans, or micro jiras that break down a single task into many minor, trivial items.

    RichFaces Project [RF]

    As stated above the RichFaces jira project is our standard jira project for tracking changes in a release.  Community users, developers, QA, and docs should all be creating, updating, and closing issues in this project following the guidelines here : RichFaces Jira Issue Lifecycle

    RichFaces Planning Project [RFPL]

    The RichFaces project has decided to use jira to track and manage general project related tasks and activities.  These activities may ultimately result in RF jiras, or may be linked to existing RF jiras when more planning details for the task are needed.

     

    Note: The RFPL is a new idea, and this policy may be adjusted from time to time to accommodate realities.

    RFPL Jira Types

    There is really two uses for RFPL

    • Macro - tracking project, site, hudson, or release spanning goals and tasks
      • May turn into or link to RF jiras if direct changes to a release result
    • Micro  - breaking down large features & issues into many smaller subtasks
      • Must always to be linked to a matching RF jira
    Macro Type Jiras

    There are many example of jiras that fit this category.  They can include:

    • Project site update plans
    • Wiki updates, and improvements
    • Hudson environment changes
    • Tasks that could span releases
    • Tasks that could span accross the component set
    • QE/Doc planning
    • Some R&D items
    • SVN organization
    • etc...
    How to handle tasks that span releases, and/or components

    This is an example of a task that potentially spans releases and spans components.  This description can be used as a guide on how to handle these issues in the future.

     

    Take for example a jira like "Optimize Component CSS".  RichFaces has over a hundred components and this jira could apply to all of them.  It could also span releases.  We also need to track what components are optimized, and which ones are not for each release.  So where should "Optimize Components CSS" jira go and where should the individual component jira's go?  In this situation "Optimize Components CSS" should be in RFPL, while the individual component jiras should be in RF as they represent actual updates resolved in a specific release.  The component RF jira's must be linked to the RFPL jira.  Also when committing source code the RF jira # should referenced in the SVN commit msg.

    Micro Type Jiras

    This is really best demonstrated by using an example:

     

    There may be a RF jira "Create new example demonstrating a4j:queue".  This is a single update to the RichFaces release, but in order to complete the developer may want to add details tasks breaking down each item into details.  Instead of bloating the RF project with 50+ micro tasks the developer can link to a new RFPL that can then contain all of those subtasks.  When the RFPL tasks is complete you can mark the RF issue complete.

    RFPL Components & Versions

    • Components will represent team, or high level areas and should not break down into details component sets like the RF project. 
    • Versions and releases will match the versions of the RF project, but also include site, wiki, and future.
      • Question: Month based versions?