Thanks for your comment, here is the updated process based on the feedback
1. Get candidate bugs by query: severity = blocker, critical and status =
unconfirmed, confirmed, reopened OR keyword includes "crash".
2. For every candidate bug above, set field " 4.0 release blocker" to "?"
to propose it as a blocker, and and then discuss it on the dev/qa mailing
list. If there is consensus it is a blocker then the value is changed to
"+".
3. Mark bugs to priority = P1(immediate) after get consensus from
discussing on the dev/qa mailing list
4. Assign these bugs to development volunteers (let bug assignee prioritize
his or her bugs except P1) for fixing and QA to verify once get resolved.
Regards,
Yu Zhen
On Thu, May 9, 2013 at 10:44 AM, Liu Ping <doneyours...@gmail.com> wrote:
> 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
> >
> >
>
