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
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.
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 DEFAULT_STATUS = ASSIGNED 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.
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.
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.