hi,Rob
I inform Priority and Severity fields from BZ help
1.
*Priority:* The bug assignee uses this field to prioritize his or her
bugs. It's a good idea not to change this on other people's bugs.
2.
*Severity:* This indicates how severe the problem is - from blocker
("application unusable") to trivial ("minor cosmetic issue"). You can also
use this field to indicate whether a bug is an enhancement request.
if you are interested in other fields ,you can get from
https://issues.apache.org/ooo/docs/en/html/bug_page.html
For the level for Priority and Severity , refer
http://www.mediawiki.org/wiki/Bugzilla/Fields
SeverityMeaningBlockerBlocks further development and/or testing work.
CriticalCrashes, loss of data (internally, not your edit preview!) in a
widely used and important component.MajorMajor loss of function in an
important area.NormalDefault/average.MinorMinor loss of function, or other
problem that does not affect many people or where an easy workaround is
present.TrivialCosmetic problem like misspelled words or misaligned text
which does not really cause problems.EnhancementRequest for a new feature
or change in functionality for an existing feature.
PriorityMeaningimmediateMust be fixed immediately (means: "Drop any other
work"). Reports should have an assignee set in the "Assigned to" field, and
both assignees and further affected parties (e.g. Engineering
Management<http://www.mediawiki.org/wiki/Wikimedia_Engineering>)
should also be informed by private email, to be on the safe side.highestShould
be fixed as next task by a team and certainly before the next deployment.
Teams should only have very few issues (preferably one) with highest
priority at the same time. Reports should have an assignee set in the
"Assigned to" field. In case of Platform
Engineering<http://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering>tickets,
notify
RobLa <http://meta.wikimedia.org/wiki/User:RobLa-WMF> separately.highNot
the next task, but should be fixed soon. Depending on teams & manpower this
can take between one and six months.normalMedium priority; would be good to
get fixed somewhere in the future. Contributed patches might speed fixing
up.low
This can be fixed, but we're not going to worry about it. Patches very
welcome and required for progress.
lowest
This can be fixed, but we're not going to worry about it. Patches very
welcome and required for progress.
On Wed, May 8, 2013 at 9:08 PM, Rob Weir <robw...@apache.org> wrote:
> On Wed, May 8, 2013 at 8:54 AM, Yuzhen Fan <fanyuz...@gmail.com> wrote:
> > Hi,
> >
> > We have pretty high backlog for unresolved defects, we need to clean them
> > as much as possible before we exit full regression. Before we focus on
> the
> > fixing work, let's set the filter and get the defect list with high
> > priority.
> >
> > I would suggest we use this way:
> > 1. Get candidate defects by query: severity = blocker, critical and
> status
> > = unconfirmed, confirmed, reopened
> > 2. Evaluate them and set/unset Flags as 4.0.0_release_blocker to get
> defect
> > list with high priority
> > 3. Assign these defects to development volunteers for fixing and QA to
> > verify once get resolved
> >
> > You comment and suggestion are welcome!
> >
>
> Maybe someone can help clarify something: The BZ form has two fields
> for rating bugs: P1/P2/P3/P4 field and a
> blocker/critical/major/normal/minor/trivial field. What is the
> difference?
>
> Also, the 4.0 release blocker has 3 values: ?/+/-. The way we did it
> before was to set the field to "?" to propose it as a blocker, and
> then discuss it on the dev mailing list. If there was consensus it
> was a blocker then the value is changed to "+".
>
> -Rob
>
>
> > Regards,
> > Yu Zhen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
