Tizen 3.0 Feature Tracking

From Tizen Wiki
Jump to: navigation, search

Purpose of this document

This document describes the Tizen 3.0 Feature Tracking process.

Background

  • Tizen 3.0 consists of a common base and profile specific additions (IVI, Mobile and other forthcoming profiles). For more details about the common base, please check Common wiki
  • Tizen 3.0 TC JIRA project is created for all Tizen 3.0 bug and feature tracking. This will help work with one data base going forward. Profile bugs are also tracked in this project with specific components. Take Tizen IVI as an example, bugs and features for all IVI specific components are tracked in "Automotive/xxx" JIRA components.

Feature Configuration of TC project

Fields

JIRA Field Usage
Attachment Attachment to help describe the issue or share information with others.
Assignee The engineer who is working on fixing the issue.
Component/s The domain where the feature belongs.
Description Details of this bug, including reproduce steps, expected result, actual result and rough analysis from reporter usually.
Feature PM The developer manager who owns this feature.
Feature Classification Which category this feature belongs to.
Fix Version In which version, this feature is expected to be supported. After the feature is integrated, the field need to be updated according to the version it integrated to.
Labels User can add labels to do advantage filtering and bug management. No permission control for this field.
Platform/s Hardware platforms for this project. Use to tell which platform was used to verify this feature.
Priority Hint how urgency the feature should be supported. Valid values are: P1, P2, P3, P4, and Undecided. This is a controlled field, only people in "PM Group" can set this field, but it's visible to all once it's set.
Profile/s Which profile this feature belongs to. The valid values are: Common, IVI, Smartphone and Emulator.
QA contact QA owner who should follow up with developer and verify this feature finally.
Reporter who file this ticket.
Security Level Who can see this issue. Valid values are: Locked, Declassified and None.
Source Hint where the requirement come from.
Summary Concise description of this bug, the title of this bug.
Target Date The target date to support this feature.

Note: Bold means mandatory fields, the bug reporter is expected to provide necessary information for a bug.

Controlled Field and transition

  • Priority: Only people in "PM group" can set this field, but it's visible to all once it's set.
  • Scoping <-> Approved, Scoping <-> Rejected, Approve <-> Rejected: Only people in "PM group" can do such status transition, which decide if accept this feature or not.

Workflow

TC feature workflow.png 400

Main stream

  • Scoping -> Approved: Reviewed by planner and PM, reached agreement that this feature should be supported as project requirement.
    • Both Fix Version and Target Date should be provided.
    • Assign this feature to Feature PM/component leader . Feature PM should assign the feature to proper developer and set target date as a commitment.
  • Scoping -> Rejected: Rejected by planner or PM from project requirement point of view.
  • Approved -> Resolved: Code is merged in Git and passed developer's unit test. "gbs submit" is triggered.
  • Resolved -> Closed: QA verified the feature and close it.

Implicit path

  • Approved -> Scoping: Feature PM feels this feature is invalid or unclear and needs further clarification. The dialogue takes place in JIRA and the status will later be revisited by PM and planner once the matter has been settled. Note that such transition is also implied if the FixVersion is Future (which is a catch-all bucket with no definite timeframe attached to it).
  • Resolved -> Approved: QA reopen this feature according to failed test result.
  • Approved -> Rejected: PM or planner think it's an invalid feature after second thoughts.

Feature verification process

Feature for Common only

  • Common Planner/PM: Ensure the profile is "Common", "Fix Version" is set correctly, set the feature status as "Approved".
  • Developer manager (aka, Feature PM): Add "Target date" for the Approved feature, which is a kind of commitment from developer team.
  • Developer: Set the feature status to be "Resolved" after the patch is integrated in common.
  • Common Tester: Verify the feature, either "Close" it or reopen it to "Approved" status based on test result.

Feature for Profile only (e.g. IVI)

  • Common Planner/PM: Submit the feature in profile specific component, e.g. for IVI, it's "Automotive". Ensure the profile is "IVI", "Fix Version" is set correctly, and the feature status as "Approved".
  • Developer manager (aka, Feature PM): Add "Target date" for the Approved feature, which is a kind of commitment from developer team.
  • Developer: Set the feature status to be "Resolved" after the patch is integrated in IVI.
  • Profile QA: Verify the feature with profile image, either "Close" it or reopen it to "Approved" status.

Common feature applies to Profile (e.g. IVI)

  • Profile Planner/PM: Set the profile as "Common, IVI", "Fix Version" is set correctly, set the feature status as "Approved".
  • Developer manager (aka, Feature PM): Add "Target date" for the Approved feature, which is a kind of commitment from developer team.
  • Developer: Set the feature status to be "Resolved" after the patch is integrated in common.
  • Profile Release Engineer (RE): Integrate the common patch to profile image based on regular sync.
  • Profile QA: Verify the feature with profile image, either "Close" it or reopen it to "Approved" status.