The following are some general guidelines when defining method plug-ins:
Consider the following when deciding whether or not to create a new plug-in:
Don’t modify content in plug-ins that are locked or owned by other parties. Instead, create a new plug-in that
extends or replaces the base content. Standard plug-ins provided as part of a standard library should be locked to
avoid inadvertent changes. Lock any third-party plug-ins after importing them.
Each plug-in has a physical file that contains information about all of the other content elements in the plug-in.
Therefore, if several individuals are working on content for the same plug-in, that file will need to be carefully
controlled. In such cases, you may want to consider dividing the method content that will be added to the base
method content into more than one plug-in to avoid contention over the plug-in file.
Before defining new plug-ins, be sure to review the structure and content of existing method plug-ins. This is
especially important in those cases where you are customizing or building on an existing method.
Special instructions when authoring in the UMF: When defining plug-ins that are to exist within the Unified Method Framework (UMF), the practice framework plug-in types need to be
considered. These types affect what elements can be placed in what plug-in. For example, base definitions for
practice-specific method elements are defined in Practice Base (or Extend) plug-ins, and base definitions for
non-practice-specific method elements are defined in Core Base (or Extend) plug-ins. However, assignments that are
delayed are defined in Assign plug-ins. For more information on delayed assignment, see Guideline: Delayed Assignment in the UMF. For more information on the plug-in types,
see Concept: Practice Library Plug-In Types.
In addition, all UMF plug-ins must have a specified copyright (see Guideline: Copyrights in the UMF), as well as release information (see Guideline: Release Information in the UMF).