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

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:

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
  • Identify any additional scenarios where the properties are required
  • 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
  • How many tools already support the properties
  • 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

  CM 1.0 Mylyn RTC Scrum ClearQuest Change Rally Bugzilla  
Field Element Task Defect Task Story ALMRequest Defect(ent) ChangeRequest Story Defect Bug Type Scenarios Description
ID dc:identifier ID ID ID ID id id problem_number ObjectID? ObjectID? ID String   A unique identifier
Name   Task Key       id id problem_number Name, FormattedID? Name, FormattedID?   String (short) ide User facing identifer that can change during the lifetime of the task
Summary dc:title Summary Summary Summary Summary Headline Headline problem_synopsis     Summary String (short) all One line description
Description dc:description Description Description Description Description Description Description problem_description Description Description Description String (long) all Multiline description (could contain rich text markup)
CreationDate?   Creation Date Creation Date Creation Date Creation Date Submit_Date Submit_Date create_time CreationDate? CreationDate? Reported Date report When created
DoneDate?   Completion Date Resolution Date Resolution Date Resolution Date (from history) (from history)     ClosedDate?   Date report, plan, ide When completed
ModificationDate? dc:modified Modification Date Modified Date Modified Date Modified Date (from history) (from history) modify_time LastUpdateDate? LastUpdateDate? Modified Date report, ide Last modification date
Type dc:type Task Kind Defect Task Story record_type/Type* record_type request_type Story Defect   String all Defect, enhancement, task, ...
Project   Product Project Project Project Project Project product_name Project Project Product Link ide, report, fixdefect, plan A top level container for this change request
Component   Component Category Category Category Category Category   Package Package Component Link ide, report, fixdefect, plan A finer grain containment for this change request
Keywords dc:subject Keywords Tags Tags Tags Keywords Keywords keyword Tags Tags Keywords String ide, report Tags
Status   Status Status Status Status State State crstatus ScheduleState? State Status String all Current state of the change request usually within a multi-state workflow
Resolution   Resolution Resolution Resolution Resolution   Resolution     Resolution Resolution String all Further refinement of status: invalid, won't fix, fixed, etc
Owner   Owner Owner Owner Owner Owner Owner   Owner Owner Assigned To Link all Who is responsible for ensuring that this change request is done
Creator dc:creator Reporter Creator Creator Creator   Submitter     SubmittedBy? Reporter Link report Who created this change request
Priority   Priority Priority Priority   Priority Priority priority   Priority Priority String ide, plan, report Used to plan work
Severity   Severity Severity     Severity Severity severity   Severity Severity String report, fixdefect The impact of this from the point of view of the reporter
Comments   Comments Discussion Discussion Discussion Comments Notes   Discussion Discussion Comments LinkCollection? ide, fixdefect Notes
Attachments   Attachments Attachments Attachments Attachments Attachments Attachments attachment Attachments Attachments Attachments LinkCollection? ide, fixdefect  
Subscribers   CC Subscribers Subscribers Subscribers NotifyList?         CC LinkCollection? all List of Users/emails wishing to be notified of changes to this request
Parent     Parent Parent Parent       Parent   Blocks Link plan  
Children     Children Children Children Tasks     Children, Tasks Tasks Depends On LinkCollection? plan  
Related     Related Related Related RequestsRelated?           LinkCollection? ide, fixdefect A relationship between change requests with loose semantics
Duplicates     Duplicate Of Duplicate Of Duplicate Of Duplicated_by Duplicated_by duplicate   Duplicates   LinkCollection? ide, fixdefect Duplicate change requests of this one
Blocks     Blocked By Blocked By Blocked By       Blocked Blocked Blocks LinkCollection? ide, fixdefect Dependency relationship where this change request must be completed before listed can proceed
TestCases?                 TestCases?     LinkCollection? fixdefect Reference to affected (blocked?) test cases
BuildsFixedIn?                   FixedInBuild?   LinkCollection? fixdefect Reference to build resources where this cr has been fixed
BuildsFoundIn?                   FoundInBuild?   LinkCollection? fixdefect Reference to build resources from where this change originated
ChangeSets?     ChangeSets? ChangeSets? ChangeSets? (ucm package) (ucm package)         LinkCollection? fixdefect Reference to SCM change sets
Operations   Operations Operations Operations Operations actions(computed) actions(computed)         String all List of operations (possibly state transitions) that can be performed on this change request
ChangeLog?     History History History history history transition_log RevisionHistory? RevisionHistory?   LinkCollection? all A log of all changes
Not Mapped     FoundIn? , CompletingUser? , Modifier, DueDate? , PlannedFor? , Approvals, Estimate, TimeSpent? , StoryPoints? (same as previous) (same as previous) Iteration, Phase RequirementsList? , Symptoms product_version, release, _date, assigner, resolver

AcceptedDate, ChangeAuthor? , Iteration,
PlanEstimate, Predecessors, Rank, Release, ScheduleState? , Successors, TaskActualTotal? , TaskEstimateTotal? , TaskRemaingTotal? , Tasks?, Workspace
Subscription
Notes

AcceptedDate? , AffectsDoc? , Environment, Iteration, PlanEstimate? , Rank, Release, ReleaseNote? , Requirement, ScheduleState? , TargetDate? , TestCaseResult? , VerifiedInBuild? , Workspace
Subscription
Notes
  n/a n/a Properties that were not mapped

Possibly consider:

  • Properties for specific users who performed operations: LastModifiedBy? , ResolvedBy? , ClosedBy? , etc
  • Information specific to where change is targeted: Product, Release
  • Better information on when state transitions occurred and by who
  • Platform specific information: OS, Browser, etc

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

Picture_2.png

Rally Defect Fields

Picture_3.png

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.

FieldTypeDescriptionScenarios
problem_numberString Unique idenitifer. Always built-in.

problem_synopsisString
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.
<status>_dateDatetime
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 :

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  

This topic: Main > WebHome > CmHome > CmCommonProperties
Topic revision: r23 - 23 Oct 2009 - 13:17:16 - OlivierBerger
 
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