Gazelle A Process

Owned by Former user (Deleted)
Last updated: Sept 07, 2010Version comment
3 min read

This is a functional release and we have a set of processes we use to run our day to day activities. Here are some bullets~

Hotfixes and Release Dates

hotfixes released every month on the 15th Last community patch review: Feature Complete: Code Freeze: Launch:
csv-table:: Hotfixes:header: "Release", "Rev #", "Issues Resolved"
:widths: 5, 5, 20

1.2.1, 14216, "http://tinyurl.com/6o28sr" 1.2.2, 14355, "Issue #2337"

Processes

Standup Meetings

What: Daily 15 min standups Who: Core team When: 11am everyday

Standup agenda:

  1. What did you do yesterday / today
  2. What will you do today / tomorrow
  3. Any roadblocks?

Triage Process

What: Triage new bugs Who: Emily, Kay, Jeff, Adam F When: 10:30am on Wednesdays

  • New bugs are automatically in Gazelle Backlog
  • During triage:
    1. if Bug is a hotfix or Gazelle A candidate, move to Gazelle A.
    2. If Bug is unimportant, move to unscheduled.
    3. Otherwise, if it is a possibility for Gazelle A, stay in Gazelle Backlog.

Iteration Process

  1. 2 week long iterations (start Monday, end Friday)
  2. Iteration planning determines user stories + possible hotfixes + patches to review for next iteration
  3. Stories should already be estimated
  4. Developers take ownership of stories as they take them and assigns Mingle card to themselves
  5. At end of 2 week iterations, PM will showcase what can be showcased.
  6. If a P1/S1 bug comes up in the middle of iteration, PM will re-prioritize the iteration.
  7. Mingle: Since testing might not occur in same iteration, card needs to be moved to Ready for PM Review status first (use Development Complete card transition). PM will verify if the story is completed and ready for showcase at end of iteration
  8. Mingle: Once PM determines it is ready for showcase, card needs to be moved to Ready for Testing status. QA can do complete set of tests on story.

Issue Tracker Milestones

  • Gazelle A - bugs that are top priority and prioritized to be fixed / already fixed for Gazelle A.
  • Gazelle A Backlog - backlog for Gazelle A, potential bugs we might want to see fixed in Gazelle A.
  • unscheduled - not a candidate for Gazelle A, not scheduled.

Criteria for Dev Priority

  1. Investigate / Fix Hotfix issues (determined P1 by this - Customer Support)
  2. Core functionality work
  3. Accept patches from current volunteers

Patches

  1. Stays in same milestone it's in when submitted
  2. Dev continues to verify patches and then once accepted, moves the issue to Gazelle A.

Branches

  1. All code checked into main trunk.
  2. If a bug is deemed a hotfix, the code will be copied into the 1.2 branch.

Hotfix Process

  1. Hotfixes are determined using this criteria - Customer Support
  2. New task issues are created (by PM) for each bug that is deemed a hotfix immediately in the Issue Tracker with the Target Milestone set to correct release milestone (1.2.1, etc)
  3. Developer who fixed original issue will merge hotfix into 1.2 branch - and mark corresponding issue as fixed.
  4. QA will verify hotfixes in 1.2 branch.
  • This way, QA can verify bug in separate branches and update each issue in the Issue Tracker accordingly.