[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wikitech-l
Subject:    Re: [Wikitech-l] Bugzilla workflow: keywords
From:       "Daniel Friesen" <daniel () nadir-seen-fire ! com>
Date:       2012-08-29 0:22:44
Message-ID: op.wjr0n6ytdykrql () daniels-macbook-air ! local
[Download RAW message or body]

On Tue, 28 Aug 2012 15:48:51 -0700, MZMcBride <z@mzmcbride.com> wrote:

> Jon Robson wrote:
>> Personally I don't like these keywords in bugzilla __at all__ and don't  
>> use
>> them. This is mostly because I think they are extremely hidden in the
>> interface.
>>
>> From my point of view bugzilla should provide a status: 'in review'
>> alongside 'new', 'unconfirmed', 'resolved' and 'assigned'
>
> It'd be nice if the statuses weren't all shouted and single words.  
> INREVIEW
> is pretty unpleasant.

HACKS!

...selector... { text-transform: lowercase; }

Time to start tweaking the css.

>> This would be useful for cases where a pull request has been sent or a
>> patch attached - so effectively the ticket has almost been resolved  
>> pending
>> this last review step.
>
> Right. We've been hitting this more and more lately. It used to be that
> you'd commit to SVN, mark the bug as fixed, and then if your revision was
> reverted, the bug would be reopened by the person doing the reverting.  
> With
> Git, the development workflow has changed, so it makes sense to adjust
> Bugzilla's workflow as necessary.
>
>> I find the status filter much more useful and would allow me to easily  
>> see
>> what bugs needs review. It also helps me filter the bug list to attempt  
>> to
>> solve things that haven't been tackled.
>
> You should be able to just as easily filter by keyword, but this isn't to
> suggest that I disagree with your broader points (more below).
>
>> If I review a patch or a pull request and don't think it's suitable  
>> then I
>> would propose that we mark it as REOPENED. This at least signals to the
>> provider of the patch that more work needs to be done.
>>
>> Thoughts?
>
> I think we should take a holistic approach to the Bugzilla workflow. I  
> was
> hoping the incoming Wikimedia Foundation entomologist would work on this.
> It'd be great to fix one aspect of bug filing (such as the use of  
> keywords),
> but it'd be even better to take a look at the entire workflow and figure  
> out
> ways to make it suck less.
>
> For example, the high-level categorizations are pretty awful currently.  
> What
> is and is not a product is inconsistent and confusing. I started some  
> notes
> about this at
> <https://www.mediawiki.org/wiki/Requests_for_comment/Bugzilla_taxonomy>.
>
> Perhaps that page could/should be re-titled to "Bugzilla workflow" and we
> could address a few outstanding Bugzilla workflow problems at once?
>
> MZMcBride


-- 
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[prev in list] [next in list] [prev in thread] [next in thread]