<?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.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-5q95l0ip0Powz0ViHXLxEA" name="new_guideline,_EXvLwD3NEd-realK_We5vA" guid="-5q95l0ip0Powz0ViHXLxEA" changeDate="2011-10-13T15:49:45.250-0700" version="7.5.0">
  <mainDescription>&lt;h3>&#xD;
    Defining Plug-ins&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    &amp;nbsp;The following are some general guidelines when defining &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/method_plugin_190B9F5E.html&quot;&#xD;
    guid=&quot;_D4TLgMaGEduMlb2cQZNTYw&quot;>method plug-in&lt;/a>s:&#xD;
&lt;/p>&#xD;
&lt;ul class=&quot;noindent&quot;>&#xD;
    &lt;li>&#xD;
        Name and briefly describe the plug-in.&amp;nbsp;&lt;br />&#xD;
        &amp;nbsp;&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Capture the source of the information for the plug-in.&amp;nbsp;This information is important if you ever need to&#xD;
        provide source information for the plug-in for documenting ownership rights.&lt;br />&#xD;
        &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Maintain accurate change histories, as well as making sure your trademarks and copyrights are accurate.&amp;nbsp;&lt;br />&#xD;
        &amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Identify any plug-ins that the plug-in must reference (in other words, the plug-ins the new plug-in depends&#xD;
        on).&lt;br />&#xD;
        &amp;nbsp;&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;p>&#xD;
            Define content packages to contain the method elements.&amp;nbsp;Alternatively, those packages can be created on&#xD;
            demand, as method elements are defined in the plug-in.&#xD;
        &lt;/p>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p style=&quot;LIST-STYLE-TYPE: none&quot;>&#xD;
    Consider the following when deciding whether or not to create a new plug-in:&#xD;
&lt;/p>&#xD;
&lt;ul class=&quot;noindent&quot;>&#xD;
    &lt;li>&#xD;
        Don't modify content in plug-ins that are locked or owned by other parties. Instead, create a new plug-in that&#xD;
        extends or replaces the base content. Standard plug-ins provided as part of a standard library should be locked to&#xD;
        avoid inadvertent changes. Lock any third-party plug-ins after importing them.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Each plug-in has a physical file that contains information about all of the other content elements in the plug-in.&#xD;
        Therefore, if several individuals are working on content for the same plug-in, that file will need to be carefully&#xD;
        controlled. In such cases, you may want to consider dividing the method content that will be added to the base&#xD;
        method content into more than one plug-in to avoid contention over the plug-in file.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Before defining new plug-ins, be sure to review the structure and content of existing method plug-ins.&amp;nbsp;This is&#xD;
        especially important in those cases where you are customizing or building on an existing method.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Defining plug-ins in&amp;nbsp;UMF&amp;nbsp;&amp;nbsp;&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    When defining plug-ins that are to exist within the Unified Method Framework (UMF), the practice framework plug-in&#xD;
    types need to be considered. These types affect what elements can be placed in what plug-in.&amp;nbsp; For example, base&#xD;
    definitions for practice-specific method elements are defined in Practice Base (or Extend) plug-ins, and base&#xD;
    definitions for non-practice-specific method elements are defined in Core Base (or Extend) plug-ins. However,&#xD;
    assignments that are delayed are defined in Assign plug-ins.&amp;nbsp;&amp;nbsp;&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In addition, all UMF plug-ins must have a specified copyright (see the topic Copyrights in the UMF below), as well as&#xD;
    release information.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Defining Plug-ins using Templates&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Method content&amp;nbsp;descriptions can be written using templates.&amp;nbsp; The resulting documents can then be used to&#xD;
    collaboratively complete the content.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This method of method element authoring is appropriate when:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        A method authoring tool is not being used.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        There is a need for support for markup and reviews of the content being developed that is not provided in the&#xD;
        method authoring tool being used.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        There is a reason not to have each author use the authoring tool directly for authoring the content (for example,&#xD;
        the desire to not have to train all the SMEs to use the tool before they can provide content).&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    To use templates:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Create a template that represents the information you want to capture for each type of method element.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Make the templates available to the content authors (e.g., via a customized Method Authoring Method).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Complete and review the content for each content element to be authored in this fashion.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Once the content has been reviewed and approved, migrate the content into the the method authoring tool.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Once the content in the template has been reviewed and is fairly stable, if a method authoring tool is being used, the&#xD;
    content can be migrated to the tool.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Packaging Method Elements&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Method packages represent a set of selectable method content elements that provide the user with flexibility in&#xD;
    choosing what portions of the method he wants to publish. Method elements in one package can reference elements in&#xD;
    another package.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Method packages should be used to represent logical units for useful configurations – sets of elements that should&#xD;
    either be included together in a configuration or excluded from a configuration. The user can choose which packages to&#xD;
    include in the published site by making selections in the configuration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Consider packaging very carefully to provide flexibility in what is published. For example, you could put all of the&#xD;
    tool mentors for a specific tool into a single content package.&amp;nbsp; This makes it very easy for someone to deselect&#xD;
    the tool mentors from publication.&lt;br />&#xD;
    &lt;br />&#xD;
    Packages should be defined so that selecting all packages does not result in overlapping or conflicting content. If&#xD;
    alternatives are needed, separate plug-ins should be defined, not just separate packages.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Method packages can also be used to collect obvious categories of content to make it easy to find things, as opposed to&#xD;
    just seeing a long list of elements.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The following sections provide guidelines on the use of the two types of packages: method content packages and process&#xD;
    packages.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Method content packages&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    There are several organizational strategies that can be applied to refine the method content packaging structure.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
    Option 1: Organizing the content packages along the major areas of concern of the plug-in.&#xD;
&lt;/h5>&#xD;
&lt;p>&#xD;
    When organizing the method content packages of the plug-in along the plug-in's major areas of concern, group all method&#xD;
    content that supports a specific area of concern together in the same (or sub-) content packages.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The pros of organizing the content packages along the plug-in's major areas of concern are as follows:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        It is easy for users configuring the method to select only those areas of concern that they are interested in.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The method package structure truly reflects the architecture of the plug-in itself, where each content package is&#xD;
        cohesive, but loosely coupled with other packages.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A plug-in's content package structure should not be dependent on the base library package structure, which may&#xD;
        change at any time.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The cons of organizing the content packages along the plug-in's major areas of concern are as follows:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        When the plug-in's package structure is not aligned the base library's package structure, it is harder to see what&#xD;
        plug-in content packages should be selected when specific base content packages are selected. When the packages are&#xD;
        aligned, it is easy to see where the plug-in content fits into the base content.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h5>&#xD;
    Option 2: Echo the packaging used in the base plug-in.&#xD;
&lt;/h5>&#xD;
&lt;p>&#xD;
    In this approach, align the content package with the base plug-ins content packages. Define a content package structure&#xD;
    that looks just like the base plug-in's and place the method content elements in the most appropriate package.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If content is contributed to only one or two packages of the base plug-in, rather than to most packages, echo only that&#xD;
    portion of the base plug-in structure that is needed. For instance, if the base package \Design\Visual Modeling is the&#xD;
    only package modified, echo only the base plug-in packaging structure of \Visual Modeling and its eventual&#xD;
    sub-packages.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The pros of aligning the plug-in package structure with the base content's are as follows:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        When the packages are aligned, it is easy to see where the plug-in contents fit into the base plug-in.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It also preserves the package selection choices provided by the base plug-in for publication.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The cons of aligning the plug-in package structure with the base plug-in's are as follows:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The plug-in structure does not reflect its architecture, but instead reflects the base plug-in's architecture,&#xD;
        which can change at any time.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Method elements that support specific aspects of the plug-in are not packaged together, so it is not easy to select&#xD;
    relevant subsets of content to be included in a configuration.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Process packages&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Process packages organize processes so they can be managed and located easily. The Configuration View is often used&#xD;
    when defining new processes because drag and drop is enabled from this view into the process editors. In this view,&#xD;
    plug-in divisions are not shown, so it can sometimes be helpful to define process packages in plug-ins as the process&#xD;
    packaging hierarchy for each plug-in is preserved.&amp;nbsp;For example, you may want to put all processes in a plug-in in&#xD;
    a process package that is named&amp;nbsp;to represent the plug-in.&amp;nbsp; If a plug-in has many processes, you may want to&#xD;
    define subpackages.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In most cases,&amp;nbsp;process packages are used for capability patterns only (the number of delivery processes is usually&#xD;
    so small,&amp;nbsp;packages are not&amp;nbsp; needed).&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Defining Method Configurations&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    This guideline describes how to define &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/method_configuration_C2B8FA8A.html&quot;&#xD;
    guid=&quot;__V7pAMaEEduMlb2cQZNTYw&quot;>method configuration&lt;/a>s.&amp;nbsp; Method configurations&amp;nbsp;may be defined for multiple&#xD;
    reasons.&amp;nbsp;Some of the most common reasons are to support the &lt;em>construction of processes&lt;/em> (process&#xD;
    construction configurations) and to support the &lt;em>publishing of the method&lt;/em> (publishable method configurations).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Defining a configuration involves identifying the configuration, naming&amp;nbsp;it and briefly describing it. It is also&#xD;
    important to maintain accurate change histories, as well as make sure your trademarks and copyrights are accurate.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Defining process construction configurations&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Every process must have a default configuration.&amp;nbsp;Thus, some configurations may be defined just to serve as the&#xD;
    default configuration for a process, as opposed to being published.&amp;nbsp;Process construction configurations include&#xD;
    just those plug-ins that contain elements that are needed to construct the process and no more. They do not have&#xD;
    associated navigation views (they are not intended to be published).&amp;nbsp;When naming and describing construction&#xD;
    configurations, it is recommended that you include the name of the plug-in containing the processes the configuration&#xD;
    is the default for in the name of the configuration.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Defining publishable configurations&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Defining publishable configurations is where you think about how you might like to see the elements get&#xD;
    published.&amp;nbsp;Which plug-ins should be published together? How many different web sites do you need?&amp;nbsp; A&#xD;
    publishable configuration should be defined for each target audience/variant of the method. For example, if you need a&#xD;
    version of the method that focuses on small projects, provide a small projects configuration. If you need a version of&#xD;
    the method for more large, complex and formal projects, provide a configuration with more content appropriate to that&#xD;
    context. When defining configurations that are intended to be published, try to minimize the size and maximize&#xD;
    effectiveness of the published method. Defining configurations is a key part of method authoring. However, selecting&#xD;
    the correct set of elements to be included in a configuration can be a difficult and time consuming activity. A few&#xD;
    well chosen and high quality elements are worth far more to the end user than a plethora of elements that really don't&#xD;
    address the problem at hand. Publishable configurations identify navigation views that are to be published.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When defining a publishable configuration, in the Main description describe the target audience for the configuration&#xD;
    and any other relevant details about it. This information is not published; it is intended primarily for the users of&#xD;
    method content to decide if they want to use this configuration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    As with all configurations, an important part of defining a publishable configuration is selecting the plug-ins and/or&#xD;
    packages that are to be published, as well as specifying those elements that should not be published.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In addition, the navigation views that are to be published for the configuration should be specified, as well as any&#xD;
    publish options.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Defining Practice Configurations&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Practice Configurations are an important artifact in a Practice Framework&amp;nbsp;as they assemble a specific set of &lt;a&#xD;
    class=&quot;elementLink&quot; href=&quot;./../../../core.default.uma_concept.base/guidances/concepts/practice_F5C8EAAB.html&quot;&#xD;
    guid=&quot;_qhCTAFRREd2CWscN8Mx6rg&quot;>Practice&lt;/a>s into something a practitioner can use.&amp;nbsp;When defining the practice&#xD;
    configuration, you must adhere to the architecture of the framework in which the configuration is to exist.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Thus, when trying to decide what practice configurations to produce, it is important to take the time to understand the&#xD;
    nature of the business problem the practice configuration is intended to solve (the configuration's purpose) and who&#xD;
    will be the primary consumers of the configuration (the configuration's intended audience). Understand what the scope&#xD;
    of the problem is and the approach to solving it. This understanding forms the basic information that will guide many&#xD;
    decisions that will affect the ultimate usefulness of the process configuration. It will also guide you in choosing an&#xD;
    applicable name for the practice configuration.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    At this point, its even a good idea to identify practices that will be included in the practice configuration, as well&#xD;
    as any cross-practice processes that may be included and what practices they will be assembled from.&amp;nbsp;These are not&#xD;
    defined in detail at this stage, but identifying them can help clarify the scope of the practice configuration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In summary, the following are some key pieces of information that you should capture for a practice configuration and&#xD;
    some examples for that information:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Name: MAM for Organization X&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Purpose: Describe the best practices for authoring practice frameworks at Organization X.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Scope: All MAM practice framework practices plus Organization X customizations.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Intended Audience: Process Engineers at Organization X&lt;br />&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Practice configurations are physically represented by publishable configurations. Thus, defining a practice&#xD;
    configuration involves identifying, naming and briefly describing that publishable configuration, and including the&#xD;
    above information in the definition of the publishable configuration.&amp;nbsp;For more information on publishable&#xD;
    configurations, see [Concept: Practice Library Configuration Types].&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Note: A practice configuration can be defined by mimicking an existing practice configuration. In that case, you can&#xD;
    define the new practice configuration by copying components of the original practice configuration, including the&#xD;
    existing practice configuration's method configuration and practice configuration-specific Publish plug-in.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Defining Practice Configuration Welcome Page&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Every Practice Configuration&amp;nbsp;should have a Welcome page that&amp;nbsp;clearly states the purpose, scope and intended&#xD;
    audience for the configuration.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is also a good idea to describe, at a high-level, how the practices included in the configuration fit together&#xD;
    (remember, a practice configuration is more than just a collection of practices).&amp;nbsp;This high-level description may&#xD;
    be in any format, whether that be textual (like a roadmap) or graphical (like an activity diagram, flow chart,&#xD;
    capability pattern, etc.).&amp;nbsp;Treat this overview as though it were the introduction to a book (where the practice&#xD;
    configuration is the book).&amp;nbsp; It should give the reader the lay of the land without going into too much detail.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In addition, if the practice configuration includes multiple navigation views, each addressing the navigation needs of&#xD;
    a particular type of user, it is usually a good idea to describe what navigation views are available and when you&#xD;
    should use one versus the other.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Welcome page is also a good place to link to release&amp;nbsp;information for the configuration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Welcome pages are defined as &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/supporting_material_F91C8C5B.html&quot;&#xD;
    guid=&quot;_SwvUgMaIEduMlb2cQZNTYw&quot;>supporting material&lt;/a>&amp;nbsp;guidance elements with a special icon.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Copyrights in the UMF&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    In the Unified Method Framework (UMF), every plug-in must have an associated copyright (and every plug-in can only have&#xD;
    one copyright).&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Copyrights are defined in Release Copyright plug-ins. There is one Release Copyright plug-in per licensing&#xD;
    level&amp;nbsp;that contains the copyright elements (defined as supporting material guidance elements) for that level.&#xD;
    Every plug-in at a particular licensing level needs to be associated with the copyright for that licensing level.&#xD;
    Copyrights are associated to plug-ins as part of the plug-in's definition.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If a specific copyright is needed for a specific plug-in, then perform the following to create a specialized copyright:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Define an Extends plug-in for the Release Copyright plug-in at the licensing level of the plug-in requiring the&#xD;
        special copyright.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        In the Extends plug-in, define a supporting material guidance element that extends the copyright element for that&#xD;
        licensing level. This results in a new copyright element that looks just like the original copyright element that&#xD;
        was extended.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Also in the Extends plug-in, define a supporting material guidance element that contributes to the extending&#xD;
        copyright element and add whatever special copyright information is needed. Now you have a specialized copyright&#xD;
        that includes the appropriate copyright&amp;nbsp;information for the licensing level plus the special copyright&#xD;
        information.&amp;nbsp;&lt;br />&#xD;
        Note: The extending element and the contributing element are both needed. If you add the specialized copyright&#xD;
        information to the extending element, then that information would override the text in the original base, and in&#xD;
        this case, that is not what we want (we want to add the specialized copyright information to the general licensing&#xD;
        level copyright information).&amp;nbsp;By using the extend-contributes pair, you can create a new element that includes&#xD;
        the same content as an existing element plus more. For more information on method content variability, see the&#xD;
        topic Using Method Content Variability in the &lt;a class=&quot;elementLinkWithType&quot;&#xD;
        href=&quot;./../../../practice.bus.mdev.base/guidances/guidelines/defining_method_elements_CADE4FF6.html&quot;&#xD;
        guid=&quot;_fx7TMD3REd-realK_We5vA&quot;>Guideline: Defining Method Elements&lt;/a>.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Associate the specialized copyright to the plug-ins (or individual method elements) that need it (copyrights&#xD;
        associated with a plug-in are automatically associated with all elements in the plug-in).&#xD;
    &lt;/li>&#xD;
&lt;/ol></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
