Bug 1032861

From an email thread in pressgang-ccms-dev, it was pointed out that Topic Lifecycles won't work as Tags as Product/Version is going to have a different lifecycle. Email thread content:

--------------------------------------------------------------------------------
From: "Lee Newson"
Sent: Monday, 18 November, 2013 1:35:03 PM
Subject: Re: Topic lifecycles and reporting

Works for me, the only thing I see as redundant (and different to the way things currently work) is the "Default Status" metadata. This shouldn't be applied as metadata and should be a global attribute like tagging, writers, conditions, etc... eg:

ID=9876
Title=Installing EAP7 in Windows

[status=DONE]
Chapter: Installing EAP7
  Downloading the installation file [1234, status=ASSIGNED]
  Installing the application [1235, status=ON_QA]
# The following topic would have a status of DONE
  Running the application [1235]

The other thing that I believe would work better is if we treated "status" in the same way as "writer", where it really is a tag in a specific category and you just specify the tags name in the content spec. That way it could easily be expanded by whoever admins the installation (or in our case anyone).

Cheers Lee

--------------------------------------------------------------------------------

From: "Lee Carlon"
Sent: Sunday, 17 November, 2013 7:46:40 PM
Subject: Re: Topic lifecycles and reporting

It works for me. I think being able to track the life-cycles of topics across multiple development streams is an important step forward for pressgang.

And while I doubt you're at the implementation stage just yet, I'm interested to hear your thoughts on how this would work. There is enough feedback on the revision numbers thread to get a sense that users aren't keen to manually edit content specs.

Cheers
Lee

--------------------------------------------------------------------------------

From: "Matt Casperson"
Sent: Sunday, 17 November, 2013 5:31:19 PM
Subject: Topic lifecycles and reporting

Tom brought up an issue a while ago with respect to using tags for lifecycle reporting on topics. When using frozen topics shared between specs, tags can not easily define the lifecycle of a topic. For example, topic 1234 could be in QE as it appears in an EAP6.1 content spec, in progress as it appears in an EAP7 content spec and done as it appear in a BRMS content spec.

Since tags are a poor fit for trying to capture the multifaceted nature of a topic's lifecycle, I'd like to propose a status option on topics in content specs as a solution for this.

So we would have something like this in the EAP7 guide:

Chapter: Installing EAP7
  Downloading the installation file [1234, status=ASSIGNED]
  Installing the application [1235, status=ON_QA]
  Running the application [1235, status=DONE]

And then this in the EAP6 guide:

Chapter: Installing EAP7
  Downloading the installation file [1234, status=DONE]
  Installing the application [1235, status=DONE]
  Running the application [1235, status=ON_QA]

These states can then be queried and uses to automatically generate reports. Any topic that does not have a state could use the default state defined at the spec level, like so:

ID=9876
Title=Installing EAP7 in Windows
Default Status=DONE

Chapter: Installing EAP7
  Downloading the installation file [1234, status=ASSIGNED]
  Installing the application [1235, status=ON_QA]
# The following topic would have a status of DONE
  Running the application [1235]

And in the absence of a "Default Status" and an explicitly defined one, a topic would have the status of UNDEFINED.

Regards

Matthew Casperson