[Libreoffice-qa] tag for new features

[Robinson Tryon]

On Thu, Dec 19, 2013 at 9:54 AM, bfoman <bfo.bugmail at spamgourmet.com> wrote:
> I would propose to start using flags after migration to own Bugzilla
> instance, as you cannot whiteboard everything and abusing this field will do
> more harm. See http://www.bugzilla.org/docs/4.4/en/html/flags-overview.html.

A large number of things will be (hopefully) overhauled once we have
our own instance of Bugzilla. I don't currently have an ETA for the
migration (probably in 2014) -- I just don't want to get anyone's
hopes up for a speedy fix!

> For instance following flags could be introduced:
> - documentation - indicating that a new feature should be documented
> - moztrap - indication that test case in moztrap should be created
> - relnotes - indication that a feature should be described on release notes
> page
> etc.
> Flags are searchable, so everyone interested in participating, whether it be
> creating moztrap test cases, writing documentation etc. could add a Bugzilla
> search or create a whine (when enabled) for particular flag.
> Flags have states, so a documentation request could be done simply by
> setting documentation? and when done changed to documentation+.

Interesting :-)


As I've mentioned previously, whatever improvements we add to Bugzilla
should be simple, extensible, and expressive.

As an example, let's consider bibisect tags in the whiteboard. We have
things like "BibisectRequest", "Bibisected", "NotBibisectable", etc.
These tags are rather expressive, which is great for a newcomer to the
system. Sometimes we'll mark a bug as not being bibisectable because
the bug isn't present on GNU/Linux. But what happens when we add mac
and windows bibisect repos to our quiver of QA weapons? At that point,
we need to have a good way to extend the system so that we can say
something like "NotBibisectable:OnLinux" or etc..

> Of course granting or denying a documentation flag could be allowed by
> documentation team for instance (or those in documentation bugzilla security
> group).

I'm very hesitant to restrict access to particular features in Bugzilla.

There are some pieces of QA we're in general agreement that we need to
restrict a bit (e.g. setting severity and priority, security-related
bugs, etc..), but I'd be hesitant to separate-out powers in Bugzilla
to particular teams, especially when I think we need to encourage more
inter-team collaboration. In general, I'd suggest that we wait until
we have a documented case of feature-abuse, and then we can lock it
down.

Just because you mentioned it, I think that documentation is really
important piece of our bug workflow. Lowering barriers to contribution
of new documentation (and clear guides on how to, say, take some
comments on a bug report and get them into the wiki or the Online
Help) will make it much easier for members of the QA Team to moonlight
as documentarians :-)

--R