• Create New CRI
• Create New DTN
• Create New CRUS

Welcome to the Customer Issues project!  This is the new home for consolidated trackers that takes the place of the CRI tracker in sf-saturn, PCN, and other trackers. 

Below is the  documentation for the new process for handling customer-related outages, issues, and tasks.

For any questions or problems on the use of the DTN Tracker, contact Steven Collins.

For any questions or problems on the use of the CRI Tracker, contact CERT.

What is CollabNet’s Product Issue Council?

The "Product Issue Council" (PIC for short) is a group of cross-functional team members from CTF Engineering, CERT, Support, and Ops who meet on a weekly basis to make decisions about the disposition of support/cert/ops-driven product defects (CRIs) and other tactical customer-driven change requests (mini-CRUSs).  The idea is to give people outside of Product Management a chance to represent their constituents.

What are the PIC’s primary objectives?

·         Make decisions about CRIs and CRUSs that have been escalated for discussion

·         Accept or reject CRIs and CRUSs that have been requested for release deferral

·         Accept or reject CRIs and CRUSs being proposed as Engineering Change Orders (ECOs)

·         Accept or reject CRIs and CRUSs that have been requested for product patches

·         Decide when a patch is merited, and coordinate schedule & delivery resources

What will we actually do in our weekly meetings?

Review the list of CRI shadow artifacts from the “Ranked Customer-Reported Defects” folder which is under the “PO’s Inbox” folder in the TeamForge Product Development project, and make various decisions based on PIC objectives.  Sometimes this will result in pulling things into release, other times kicking things out.  Furthermore, the genesis and ultimate decision to proceed with release hotfixes and patches will be defined, considered, scheduled, and coordinated in this meeting.

We will also review the list of CRUS shadow artifacts from the “PO’s Inbox” folder in the TeamForge Product Development project.

The council is “exception-oriented”, meaning we will only review the artifacts that have been tagged for PIC review. 

What is the new PIC process?

For the customer-reported defects:

·         CERT creates a CRI shadow artifact (CRD) and drops it to the “Shadow Customer-Reported Defects” tracker in the TeamForge Product Development project.

·         CERT/Support/Ops drops and ranks the CRDs that they want PO to include in the active TeamForge release in the “Ranked Customer-Reported Defects” folder which is under the “PO’s Inbox” folder in the TeamForge Product Development project.  CERT/Support/Ops specify the artifacts that they want to be discussed at the PIC meeting by updating the “Tag” field with “PIC-XXX”¹.

·         Based on the ranking, PO decides which CRD(s) can be completed in the active  release iteration and drops them in that iteration folder.

·         Once a CRD is taken into the active release iteration, CERT/Support/Ops updates the original CRI artifact “Status” field to “In Next Release”.

·         Once a CRD is fixed in the active release iteration, QA completes the validation and marks it as “Closed”.  QA also updates the CRD “Fixed In Release” field with the release number. CERT/Support/Ops updates the original CRI “Status” field to “Fixed”.

·         In cases where a CRD is taken out of an active release iteration and it is not moved into the next iteration (this could happen if the effort required is too much to be accommodated in the release or it is the last iteration already), PO moves the CRD back into the “Ranked Customer-Reported Defects” folder and updates the “Tag” field with “PIC-XXX”¹ for discussion at the PIC meeting. If the group jointly decides to take the CRD out of the release, then CERT/Support/Ops updates the original CRI artifact “Status” field to “Open” and removes the “PIC-XXX”¹ marker in the “Tag” field.

For the tactical customer-driven change requests (mini- CRUSs):

·         PO creates a shadow CRUS and drops it to the “PO’s Inbox”  folder in the “TeamForge Product Development” project.

·         Once a shadow CRUS is taken into the active release iteration, PO updates the original CRUS “PM Status” field to “PRO - Productized” and the “Status” field to “In Next Release”.

·         In cases where a shadow CRUS is taken out of an active release iteration and it is not moved into the next iteration (this could happen if the effort required is too much to be accommodated in the release or it is the last iteration already), PO moves the CRUS back into the “PO’s Inbox”   folder.  PO specifies the artifacts that he/she wants to be discussed at the PIC meeting by updating the “Tag” field with “PIC-XXX”¹.  If the group jointly decides to take the shadow CRUS out of the release, then PO updates the original CRUS “PM Status” field to its original value (e.g., “ITP – In the Plan”) and “Status” field to “Open” and removes the “PIC-XXX”¹ marker in the “Tag” field.

¹PIC-XXX:  The Tag field will be changed to a pull-down menu, with the following initial values and will be updated as needed:

·         PIC-DEFER => To nominate deferring the artifact to the next release

·         PIC-INCLUDE => To nominate including the artifact to the current release

·         PIC-ESCALATE => To indicate the artifact needs to be addressed urgently