EPF Change Request Management FAQ
The EPF project uses the OpenUP to guide and organize the activities of the team.
The following FAQ answers questions that are commonly asked by EPF community members interested
in becoming involved with the project, as well as new members of the EPF committer team.
What is a Work Items List?
According to OpenUP, a Work Items List is a collection of all work that has
to be done in a project. We use Bugzilla to record all types of work items for a project:
requirements of any nature (functional, non-functional), change requests,
design constraints, infrastructure needs, architecture and technology work, and
so on. Work in this list is prioritized and assigned to people to work on.
For the development of EPF Composer, requirements (or features) at a high level are captured in a Vision document. Requirements that need to be further
detailed are captured in Use-Case Model. Work Items List captures the work to be assigned to people to deal with a requirement,
change request and so on.
In general, when developing new content for an existing or new Method Plug-in, we make use of a Vision (for high level needs and features)
and a Work Items List.
How are change requests recorded?
To request a change, submit a Bugzilla
bug or enhancement for the EPF project.
Consider the following when submitting your change request:
- What need of the EPF community will be addressed by the change request?
- Why is this need not met by existing capabilities?
- What dependencies are added or removed by this capability?
- What will become obsolete by this capability?
- What is the recommended target milestone for this change request?
How are change requests prioritized for future milestones?
Bugzilla uses a voting system to prioritize bugs.
Each user gets ten (10) votes in the EPF project to distribute among fixes and new features.
EPF committers use the vote totals from open change requests for milestone planning.
Read more about the Bugzilla voting
Bugs can be queried by number of votes using the advanced search
feature in Bugzilla.
Votes do not automatically redistribute themselves.
For example, if you vote for a bug and the bug is later closed, your vote will remain assigned to that bug.
Therefore, it is important for the EPF committers to give the community a window of opportunity to assign their votes before milestone planning is performed.
How is change request priority determined?
Priority describes the importance and order in
which a bug should be fixed. This field is utilized by the committers/contributors
to prioritize their work to be done. The available priorities range from P1
(most important) to P5
(least important.) Examples related to method content:
– Existing Tasks, Work Products and Roles with no text or creation
of new ones
– Existing Process, Categories and Guidance with no text or creation
of new ones
– Broken/missing relationship between elements, organization/packaging
of elements, review of existing content/structure
– Enhancement that does not affect current implementation or bring
– Nice-to-have enhancement
How is change request severity determined?
This field describes the impact of a bug. Examples related to method content:
Blocks development and/or
E.g.: EPF Composer can’t open library
Crashes, loss of data,
severe memory leak.
E.g.: web site crashes, tool crashes, loss
of text/elements in library
Major loss of function.
E.g., missing text in element (like brief
and main description), broken links (in the tree browser or between
Default; common loss of
E.g.: new element to be added, missing text
in element (other fields than brief and main description), broken links
(on a page), elements without any relationships
Minor loss of function,
or other problem where easy workaround is present
Cosmetic problem like misspelled
words or misaligned text
Request for enhancement
Make sure that:
P1 and P2 bugs (for current milestone) have assignees and
Major, Critical and Blocker bugs are assigned to current milestone
Who is responsible for reviewing new change requests in Bugzilla?
Everyone should review new change requests, test them for validity and ask questions and provide feedback using the Bugzilla record of the change request.
Each committer has a specific area of focus and will review new change requests as they are added to Bugzilla.
Bugzilla should be the primary communication mechanism when commenting, asking questions, or posting workarounds for a change request.
For example, beginning a separate discussion in email or newsgroups about a specific Bugzilla change request could lead to a loss of context and history about the decisions affecting the change request.
Who is responsible for creating the project milestones and timeline?
The EPF committers are responsible for creating the project milestones and timeline.
This is not possible, however, without substantial input from the EPF community.
The bug voting process, comments in Bugzilla change requests, and discussion in the mailing lists and newsgroups are the best way to communicate your organization’s needs to the EPF team.
How do I set up my development environment, version control and configuration management?
Set up Eclipse, Bugzilla and CVS using the EPF Composer Development Guide
How often are official builds of EPF Composer and published method configurations posted for download?
How does a committer deliver changes to EPF?
Committers on the EPF project deliver changes to the project using CVS.
See the EPF Composer Development Guide
for information on setting up CVS.
Although not strictly enforced by tooling, all changes should be related to an open Bugzilla record.
This is good practice and also allows the person creating the change to place a bug ID in comments in the source code.
After delivering changes with CVS, update the Bugzilla record related to this change.
How does a non-committer deliver changes to EPF?
Non-committers in the EPF community should attach their changed source files to the related Bugzilla record.
Additionally, it may be necessary to notify a specific committer that a patch for a new feature or bug fix is available in Bugzilla.
What types of reports are available to show defect rates, closure rates, etc?
Tabular and graphical reports can be generated from Bugzilla using the Reports
Who decides if a new change request is valid or unique?
Everyone in the EPF community should review new change requests created in Bugzilla and discuss them in the appropriate forum.
The committers on the EPF project determine the final disposition of a Bugzilla change request.
How do I submit a change request to Bugzilla?
First, make sure you have a Bugzilla account.
See the EPF Composer Development Guide
for steps to create a Bugzilla account.
New change requests are added to Bugzilla here
When adding a new change request, select the Technology classification and select the EPF project.
On the Enter Bug page, select a component and provide a summary and description.
Use the Severity selection to indicate whether change request is a defect or an enhancement.
If you have any additional data, screenshots, sample code or any other related artifacts for the change request, attach them after you have initially submitted the change request. After creation of the change request the ability to add attachments or comments is possible.
You will see these links on the page.
Please review the Eclipse bug writing guidelines
before submitting the first time.
How do I update a change request?
Project committers have the ability to change most fields on a Bugzilla change request.
Other users will be able to add attachments and add comments to a Bugzilla record.
To update a record, find the record using the basic or advanced search feature
Open the detail page for the record.
After making changes, adding comments or attachments, click the Commit button at the bottom of the page to make your changes permanent.
Bugzilla users who are watching this record will receive email notification of the record change.
What is the relationship between change requests and requirements?
Bugzilla is used to manage the OpenUP artifact Work Items List.
EPF team members manage the Vision and Use Case OpenUP artifacts in CVS in the design folder.
The Vision document communicates the stakeholder needs and high level feature requirements to a broad audience of stakeholders.
The Use Case Model details the requirements.
We use the Work Items List (Bugzilla) to manage the scope of requirements and any other change request.
Thus, for the features that the EPF team is going to scope for a milestone, we create a Bugzilla record, set the priority in it, and assign it to committers, who use the same record for reporting.
The Vision and the Use Case documents can trace to the Bugzilla records by using the Bugzilla URLs.
Likewise, Bugzilla records can contain ViewCVS URLs to point to Use Case documents.