IssueHandling

Proposal for a changed issue handling

responsible owner paradigm

Currently every issue is assigned to an owner. There are default owners defined per project. The default owner reviews the incoming issues and is assigning the issues the the correct owners in engineering. In most cases also the target milestone will be set (next release, 3.x, Later, PleaseHelp). So some engineers have several hundred issues assigned which is an unreasonable high amount of issues. Idea is to introduce a new owner "unassigned" (nobody is already occupied in OOo) to which issues can be reassigned to indicate that anybody else is able to jump on this issue.

Name	Pros	Cons
dedicated owner	There's every time a responsible owner to ask	there is only one owner, people don't care about issue assigned to others
	clear responsibility	unclear responsibility, the project group is in charge
	assigned to the right person	unclear transparency, it's is unclear if the owner really intend to work on this issue in the near future
issues with owner unassigned	transparency: owner do not intend to work on issue in reasonable timeframe
	a developer has an reasonable amount of issues
	a developer is not blocking issues

Proposal:

• Introduce owner "unassigned". all issues (Defects) with P3-P5 and target Office Later are candidates to get assigned to that owner. The target OOoPleaseHelp will become obsolete then.
• Anybody who wants to work on such assigned issues, is welcome to grab this issue and assign to himself.
• Important issues (see criteria below for issue with actual target) should never keep unassigned. In case that no owner can be found within the project, the project owner is in charge to look for an assignment. If this also fails these issues should be put onto the weekly release status meeting agenda (<http://wiki.services.openoffice.org/wiki/ReleaseStatus_Minutes#Agenda_for_next_meeting>) for a resolution.

y.x Targets (2.x, 3.x, etc)

Issues which is not being actively worked on but is intended to do so, will have target 3.x. Once a child workspace have been created and issue has been registered the target milestone may be set to the actual release target. In the current situation more issues are already set to the actual release target, this leads to the situation, that just before release those issue will be re-targeted to the next release.

Proposal:

Issues (Defects) with

• keywords "regression", "crash", "loop", "usability", "release_blocker",
• issues of Priority P1, P2,

can set to the next release target even with no assigned cws or even owner. Introducing these criteria also would encourage the desired usage of keywords at all. Keyword make priorisation more easy (not all of the above keywords may exist right now).

Issues (Defects) which

• have P3-P5 priority
• not assigned to living cws

should have target 3.x to get fixed in a reasonable time frame.

Possible problem here is that in the future also the 3.x target will contain too much issues assigned to a single developer.

default ownership

Currently in most project there is _one_ owner assigned to be the default owner. The work load can be divided by introducing an alias (Database already has dba_needsconfirm for this). The responsibility that this queue get reviewed on a regular basis is up to the project lead ( and the QA lead for this project is applicable).

closing issues

Currently the issues get reassigned to an QA person to verify the issue in the child workspace. This person also has the duty to verify and close that issue once integrated in the master (latest at release time).

Proposal: Do the verification of these issues on master in justified cases. The Project owner / QA Lead can decide to do mass closing of issues if they think that this is reasonable. Anybody is able to reopen those issues in case of mistaken.

best practices

defects reported within cws

defect reported on a cws do have [<cws_name>] in their title.

patches

Patches with target OOoLater do not make any sense. They should be integrated asap or if significant work on the patch is required, the issue type should be changed to defect or enhancement again

ideas

• cwsaddtask also adds the name of the cws into issue "status whiteboard"

ToDOs

Features and Enhancements

all Feature and Enhancement issues which nobody is actually working on should have the owner "requirements". Proposal: Move all these Issues matching these criteria to that owner.