Bug 1032861 - RFE: Topic Lifecycles per Content Spec
RFE: Topic Lifecycles per Content Spec
Status: NEW
Product: PressGang CCMS
Classification: Community
Component: CCMS-Core (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: pressgang-ccms-dev
Depends On:
  Show dependency treegraph
Reported: 2013-11-20 22:49 EST by Lee Newson
Modified: 2014-08-04 18:29 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Lee Newson 2013-11-20 22:49:32 EST
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:

Title=Installing EAP7 in Windows

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.



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:

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.


Matthew Casperson
Comment 1 Matthew Casperson 2013-12-10 16:45:36 EST
After talking to Lee Carlon, we should start with a small set of lifecycle stages modelled on Bugzilla. These should be:

NEW - Topic has been created but no writing done yet
ASSIGNED - Topic is being worked on
ON_QA - Topic is being reviewed
CLOSED - Topic is done

More lifecycle stages can be added if needed, but building from a small set of statuses is going to be more consistent that reducing a large set.

In addition, we need to support the ability to set a timeframe on when these lifecycle states are expected to change. This will provide a way to track progress.

I'd propose the following syntax

Chapter: Installing EAP7 [status=ASSIGNED, statusend=12 Dec 2013]
# Gets the status and statusend of the parent
  Downloading the installation file [1234]
  Installing the application [1235, status=ON_QA, statusend=13 Jan 2014]

This will most likely lead to a lot of redundant statusend attributes for status like ON_QA, but we can provide a way in the UI to updates these dates in bulk.

With the current status and the date that the status is expected to change, we can then provide automated reporting through the chart image generation.
Comment 2 Lee Newson 2014-01-13 00:40:49 EST
I'm concerned that adding that much information is going to make the content spec too messy.

As alternative I propose that we store that information along side a content spec (so a new tab in the UI and a separate file using csprocessor). That way the logic is cleanly separated (since structure has nothing to do with planning) and would keep both components fairly clean.

Example file contents:

cat timeline.txt

DEFAULT_DUE_DATE = 12 Dec 2013

TOPIC                                     STATUS           DUE DATE
10 - Test Topic                           ASSIGNED         12 Dec 2013
1234 - Downloading the installation file  ASSIGNED         12 Dec 2013
1235 - Installing the application         ON_QA            13 Jan 2014

The downside to this is we'd need to write a parser (or find a format that a parser exists for), however in my opinion this would be the better option.
Comment 3 Matthew Casperson 2014-05-03 17:40:56 EDT
My experience is that maintaining this information in a second file or screen would significantly reduce the number of people who will use the feature. I'd really like to avoid "yet another screen" or "yet another format" that people have to look at and learn.

Having said that, on second though it is reasonably clear that micromanagement at a topic level is also most likely not going to work. I don't actually think anyone is going to map lifecycles of individual topics beyond a simple current status. So the idea of a statusend attribute should be dropped for now.

I'd even go so far as to say that the idea of manually assigned status is not ideal. We should change this to assign status to topics based on their state.

NEW: topic has no text
ASSIGNED: topic has text
ON_QA: topic has open bugs assigned against it
CLOSED: topic has a fixed revision

By "assign status" I really mean having reports that show the overall status of a spec based on the state of its topics.
Comment 4 Matthew Casperson 2014-05-03 17:43:53 EDT
Actually this should be changed to:

NEW: topic has no text, or has no revisions newer than the first revision of the spec it is included in.

ASSIGNED: topic has a revision newer than the first revision of the spec it is included in.

This would account for people creating new specs for new versions of a product and including a lot of existing content.

Note You need to log in before you can comment on or make changes to this bug.