On Thu, Dec 19, 2013 at 9:54 AM, bfoman <[email protected]> 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 _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: [email protected] Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
