From Etherpad http://middleware-docs.etherpad.corp.redhat.com/CCMSMetadata Metadata Discussion Outcome ============================ Thanks for the discussion, everyone. See the Saved Revisions for the discussion record. The following is the outcome, representing the only metadata that the CCMS will track for now. Additional arbitrary metadata can always be specified on a per-topic basis, using the Properties tab in the UI or setting them via the API. Products, Versions - track products and versions a topic is used in by tracking which content specs it is used in. Content specs can have an assigned product or products (with conditionals). This is part of the required front-matter for books already. Writer - not necessary. Track the writer who made a revision. Expose a list of writers involved in the topic by looking at the revision history (possibly bounded by dates, so you could see "Writers who touched this topic in the last 6 months") Component - Pull the list from the product's bugzilla components, or a union of component lists if the topic is used in multiple products' content specs. Choose the ONE best component for the topic. This is useful for searching and metrics. Type - concept, task, or reference. This can be set in the content spec itself before importing, so only topics which are added afterward would need to be explicitly tagged. This is useful for searching and metrics. Lifecycle: Content spec: Development - this spec's content is in active development ON_QA - this spec's content is in active review (QE or peer) Verified - this spec's content is ready to be published and/or pushed for translation Published - this spec has been frozen at specific topic revisions and published Archived - this book's product version is no longer supported or it is archived for other reasons. It is not editable or publishable. Topic: Development - this topic is in active development ON_QA - this topic is ready for review Verified - this topic has been peer-reviewed. Additional fields PRODUCT and VERSION. This can have multiple entries.
Changed to "Core", rather than "Web-UI".
The Death Star editor currently tracks the writer who makes revisions when committing topics to PressGang, using the correct field in the database. It does this because *identification* is a separate concern from authentication. Users identify themselves to the editor when making a commit with a revision message, and their username is used to retrieve their userid from PressGang. The userid is stored in a browser cookie, and used during further updates to topics. The code isn't particularly elegant, but it works: https://github.com/jwulf/node-deathstar/blob/master/public/assets/js/deathstar-topiceditor.js#L134 The commits with userids can then be used to automatically extract a Revision History update for a book, by querying all the topics in the book for their major commit log messages in the time since the last Revision History entry. See here for some code for that: https://github.com/jwulf/node-deathstar/blob/master/public/assets/js/deathstar-pressgang-rest-utils.js#L303
Can the date be stored as a timestamp and converted for display purposes? Is there a problem with using UTC as the reference for what actually displays in the revision history?
Continuing the Revision History discussion in Bug #861277 since it has nothing (or very little) to do with this RFE.
Talking to Misty on IRC today, she also brought up that we should have a release tagging/workflow for Content Specifications, so that when you freeze a content spec you have to specify what release the frozen content spec represents. She also mentioned that these fields should possibly be fetched from external sources to have less errors (ie Bugzilla, JIRA, etc...)
(In reply to Misty Stanley-Jones from comment #0) So I'm trying to work out what is, and isn't implemented in this ticket, because I think it impacts on https://bugzilla.redhat.com/show_bug.cgi?id=1025595 All I want is to clean up the Topic Types category and make this available under each Product entity, rather than the current situation where this tag info is buried under a very crowded menu system. > > Products, Versions - track products and versions a topic is used in by > tracking which content specs it is used in. Content specs can have an > assigned product or products (with conditionals). This is part of the > required front-matter for books already. Tracking products and versions is now handled at the content spec level. There is a drop-down box that shows you where the topic is used. > > Writer - not necessary. Track the writer who made a revision. Expose a list > of writers involved in the topic by looking at the revision history > (possibly bounded by dates, so you could see "Writers who touched this topic > in the last 6 months") Revision History is no longer part of this RFE. > > Component - Pull the list from the product's bugzilla components, or a union > of component lists if the topic is used in multiple products' content specs. > Choose the ONE best component for the topic. This is useful for searching > and metrics. > > Type - concept, task, or reference. This can be set in the content spec > itself before importing, so only topics which are added afterward would need > to be explicitly tagged. This is useful for searching and metrics. This aspect was determined to be implemented. > > Lifecycle: > Content spec: > Development - this spec's content is in active development > ON_QA - this spec's content is in active review (QE or peer) > Verified - this spec's content is ready to be published and/or > pushed for translation > Published - this spec has been frozen at specific topic revisions > and published > Archived - this book's product version is no longer supported or it > is archived for other reasons. It is not editable or publishable. > > Topic: > Development - this topic is in active development > ON_QA - this topic is ready for review > Verified - this topic has been peer-reviewed. Additional fields > PRODUCT and VERSION. This can have multiple entries. These are ready to be implemented, but would need to be manually assigned per product. These Lifecycle tags should be made available to all Product entities in CCMS by default, and appended to new projects when they are created by Admins.