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.

Main Web>CmHome>CmCommonProperties (07 Feb 2013, SteveSpeicher)

CM Tools Common Resource Properties

See Table in Google Docs

CM Tools Common Resource Properties
- Purpose
- Change Request Property Definitions

Purpose

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

Scenarios:

fixdefect - DefectScenario
plan - CmScenariosAgilePlanningOfChangeRequests
report - CmScenariosReporting
ide - ScenariosMylyn
<add more as appropriate>

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

Sources

Tasktop/Mylyn

Rational ClearQuest

Rational Team Concert

Bugzilla

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.

Field	Type	Description
problem_number	String	Unique idenitifer. Always built-in.
problem_synopsis	String	One line "headline".
problem_description	String	Multi-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	Link	Link 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	String	Tags.
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.
<status>_date	Datetime	The date of each transition is recorded. There is no definitive "done" date, but this correspond to resolution_date or conclusion_dat.

Other sources

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

http://code.google.com/p/baetle/wiki/EvoOntBomMappings for EvoOnt? BOM
http://code.google.com/p/baetle/wiki/Bugtrackers2baetleMappings for BAETLE

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

Attachments

Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
png	Picture_3.png	manage	142.3 K	30 Sep 2009 - 14:50	MarkRinger
png	Picture_2.png	manage	135.9 K	29 Sep 2009 - 22:12	MarkRinger

Topic revision: r27 - 07 Feb 2013 - 18:42:25 - SteveSpeicher

Main

Webs
Main
Sandbox
TWiki

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