This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

CM Tools Common Resource Properties

See Table in Google Docs


This page is being used to collect information about what are common properties of change request resources of type: defect, task and enhancement. The result of this will assist in understand what properties are used for what scenarios and ensure better alignment with current implementations in defining a common CM vocabulary.

Please contribute your property definitions directly into this page or create a new page and link it to here.

Change Request Property Definitions

For change requests of type: defect, enhancement and task


Common Properties

Core Properties

This is a consolidated list of most frequently used properties on a change request resource from analyzed sources attached and referenced.

WG actions regarding updates to this table:

  • Validate that your product is accurately represented into table, update accordingly (done)
  • Identify any additional scenarios where the properties are required (done)
  • Identify any properties that you feel should (or should not) be included into the core set

The approach to define the common core set of Change Request properties for OSLC-CM 2.0 will be:

  • Prioritization of properties based on usage in scenarios (done)
  • How many tools already support the properties (done)
  • Complexity of defining specification (Children collection of references, etc)

Once a common core set is defined:

  • Identify if there is any existing standard vocabulary (DOAP, DC, etc)
  • Define the contraints on each property (open content, string with size limit, reference, complex context, etc)
  • Need for enumeration and value mapping: Severity, Priority, etc

See Table in Google Docs

Work in progress for 2.0 CmResourceDefinitionsV2

Planning Specific

Field Type Description Scenarios
DueDate? Date   plan
Estimate String Amount of work effort to complete the request in: months, weeks, days, hours plan
TimeSpent? String Amount of work accomplished on the request so far plan
Iteration Link Assigned development line (Iteration, sprint, etc) plan
StoryPoints? String   plan
Implements Link Reference to a requirement resource that this request is implementing plan
Successor Link   plan
Predecessor LInk   plan



Rational ClearQuest

Rational Team Concert


Anatomy of a Bug

Rally Story Fields


Rally Defect Fields


Rational Change

These are some common attributes from the out-of-the-box "dev_process" process. Most customer don't use it directly, but use it as a starting place for their own process.

problem_numberString Unique idenitifer. Always built-in.

One line "headline".
problem_descriptionStringMulti-line, detailed description. Can contain HTML markup.
severity String"Showstopper", "Severe", "Medium", "Minor". Values have no intrinsic value and can be changed to anything you want.

priority String Normally1, 2, 3, 4. Can be anything.
request_type String "Enhancement, "Defect", etc
product_name String
product_version String
modify_time Datetime
create_time Datetime
crstatus String State of the CR: entered, assigned, resolved, etc. Customers can add as many states as they want.
duplicate LinkLink to another CR submitted against the same defect or enhancement.
release String
attachment Link (in theory)
These are just attached files, but aren't currently available through OSLC with Change. I wasn't clear on if they were supposed to be supported and wasn't sure of how to model them. Should the URL directly download the file? Should it download an XML/JSON "change request" with a base-64 "data" property?
resolver String Who the CR is assigned to. Always has the same value as "owner" unless resolver is not set--then owner is set to whoever created the CR even if it's not assigned yet.
assigner String Who assigned the CR.
keyword StringTags.
transition_log Read-only string
This uses a proprietary markup so it is not set directly. CR modifications are automatically logged to it. Comments can be appended to it by settting the _COMMENTS pseudo-attribute. When retrieved through other APIs, the markup is stripped and it's just returned as plain text with new lines.
The date of each transition is recorded. There is no definitive "done" date, but this correspond to resolution_date or conclusion_dat.

Oracle Team Productivity Center

See Table in Google Docs

EvoOnt? BOM

See :


See :

Other sources

Some other ontologies have been developed to represent bug reports, where some mappings were described :

These may be reviewed in order to improve the properties for OSLC-CM.

Topic attachments
I Attachment Action Size Date Who Comment
pngpng Picture_2.png manage 135.9 K 29 Sep 2009 - 22:12 MarkRinger  
pngpng Picture_3.png manage 142.3 K 30 Sep 2009 - 14:50 MarkRinger  
Topic revision: r27 - 07 Feb 2013 - 18:42:25 - SteveSpeicher
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback