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 system.

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:

P1 – Existing Tasks, Work Products and Roles with no text or creation of new ones
P2 – Existing Process, Categories and Guidance with no text or creation of new ones
P3 – Broken/missing relationship between elements, organization/packaging of elements, review of existing content/structure
P4 – Enhancement that does not affect current implementation or bring immediate value
P5 – Nice-to-have enhancement

How is change request severity determined?

This field describes the impact of a bug. Examples related to method content:

Blocker

Blocks development and/or testing work.

E.g.: EPF Composer can’t open library

Critical

Crashes, loss of data, severe memory leak.

E.g.:  web site crashes, tool crashes, loss of text/elements in library

Major

Major loss of function.

E.g., missing text in element (like brief and main description), broken links (in the tree browser or between elements)

Normal

Default; common loss of function.

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

Minor loss of function, or other problem where easy workaround is present

Trivial

Cosmetic problem like misspelled words or misaligned text

Enhancement

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?

TBD

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 feature.

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 of Bugzilla. 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.