Moving this here from continuous_integration.base
diff --git a/praclib/temp/practice.mgmt.change_mgmt.base/guidances/guidelines/submitting_change_requests.xmi b/praclib/temp/practice.mgmt.change_mgmt.base/guidances/guidelines/submitting_change_requests.xmi
new file mode 100644
index 0000000..e706e81
--- /dev/null
+++ b/praclib/temp/practice.mgmt.change_mgmt.base/guidances/guidelines/submitting_change_requests.xmi
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
+ xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore"
+ xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.2.0" xmlns:epf="http://www.eclipse.org/epf"
+ epf:version="1.2.0" xmi:id="-w7sImtXWkf4HDXdUWjRsUg"
+ name="new_guideline,_fnZj0NVXEdqy9sbRhejO5Q" guid="-w7sImtXWkf4HDXdUWjRsUg" authors="Chris Sibbald"
+ changeDate="2007-02-26T10:52:05.226-0800" changeDescription="Moved content from previous concept:change request to this guideline and updated in accordance with discussion from April 18, 2006 telecon."
+ version="0.2">
+ <mainDescription><h3>
+ Background
+</h3>
+<p>
+ Change requests typically have a lifecycle. They are raised,&nbsp;reviewed, accepted or rejected, implemented, verified
+ and closed. These states define the status of the change request at a particular point in time and represent critical
+ information for tracking progress. Other sets of states are possible.
+</p>
+<p>
+ During review of a change request, the goal&nbsp;is to assess the&nbsp;technical, cost, and schedule impact
+ of&nbsp;implementing the change.&nbsp; The technical impact&nbsp;assessment includes&nbsp;the determination of
+ which&nbsp;work products&nbsp;are affected and an estimate of the level of effort required to change and verify all
+ affected artifacts. This information becomes the basis of the cost and schedule impact assessments and, ultimately,
+ whether the change request will be accepted or rejected.
+</p>
+<p>
+ If accepted, the implementation and verification of the change request will be assigned to an iteration in the same
+ manner as any other work item.
+</p>
+<p>
+ The&nbsp;current process uses the <a class="elementLinkWithType"
+ href="./../../../opn.swd.prac.legacy_pm/workproducts/work_items_list_39D03CC8.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to capture, prioritize, and track the change requests
+ using the attributes defined for that artifact.
+</p>
+<h3>
+ Submitting Change Requests
+</h3>
+<p>
+ When submitting a change request provide as much information as possible to enable a speedy review and
+ disposition.&nbsp; As a minimum, all change requests should include the following information:
+</p>
+<ul>
+ <li>
+ <strong>ID</strong> - a unique identifier for the change request to simplify tracking.&nbsp; If you are using some
+ form of change tracking tool the tool will assign a unique ID.
+ </li>
+ <li>
+ <strong>Brief Description</strong>&nbsp;- a name that summarizes the change request
+ </li>
+ <li>
+ <strong>Detailed Description</strong> - A detailed description of the change request.&nbsp; For a defect, if you
+ can provide information that will help reproduce the defect please do so.&nbsp; For an enhancement request, provide
+ a rationale for the request.
+ </li>
+ <li>
+ <strong>Affected Item</strong>&nbsp;- the affected artifact and version.
+ </li>
+ <li>
+ <strong>Severity</strong> - how severe is this issue (show stopper, nice to have, etc.).
+ </li>
+ <li>
+ <strong>Priority</strong> - how important it is this request in your opinion.
+ </li>
+</ul>
+<p>
+ Depending upon the system you are using, the names of these data elements may differ.&nbsp; However, this information
+ is required, in one form or another, to permit a speedy review and disposition of the change request.
+</p><br />
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
