El dimarts, 10 d’abril de 2018, a les 19:18:07 CEST, Nate Graham va escriure:
> I'll jump in too.
> 
> I think it's important to mention that Bugzilla is not purely a developer
> tool: it's an interface between developers and users. We can't neglect the
> user experience in favor of the developer experience. With thoughtful
> design, we should be able to handle both without compromising either.
> 
> These appear to be the concerns:
> - Some users interpret "UNCONFIRMED" to mean "KDE doesn't care and the
> developers hate me!" - Some KDE developers want the possibility of a more
> granular bug triaging workflow ("nobody's looked at it" -> "somebody looked
> at it but couldn't reproduce it yet" -> and "somebody looked at it and was
> able to reproduce it".
> 
> I can see the value in these statuses. Maybe we can support them while also
> using terminology that doesn't unnecessarily upset or confuse our users.
> How about this mapping:
> 
> OPEN -> Nobody's looked at it yet
> TRIAGED -> Somebody looked at it but couldn't reproduce it yet
> CONFIRMED -> Somebody looked at it and was able to reproduce it
> 
> None of these proposed "open" statuses--or for that matter any of the
> existing "open" statuses--make sense for wishlist bugs. Wishes don't need
> to be confirmed, triaged, new, etc. Could we also just have a single OPEN
> status for wishlist bugs?

Of course it makes sense for wishlists to be confirmed. 

OPEN -> Nobody's looked at it yet
CONFIRMED -> Somebody looked at it and is a wish that makes sense.

Cheers,
  Albert


> 
> Nate
> 
> 
> 
> ---- On Tue, 10 Apr 2018 09:10:00 -0700 tetris4<tetr...@gmail.com> wrote
> ----
>  > Hi all,
>  > 
>  > 
>  > Sorry for bumping an old thread. I'm responsible for the Streamlined
>  > Onboarding goal and Bugzilla seems  to be a hot topic relating to this.
>  > This is already the second thread I'm posting this message, the first
>  > one being
>  > https://mail.kde.org/pipermail/kde-community/2018q1/004274.html
>  > 
>  > Nate had proposed a dedicated  goal for Bugzilla back when the goals
>  > where voted and it got merged with  Onboarding as they overlapped. I
>  > thought it made sense to bring that  back and I reopened it as a
>  > sub-task of the Onboarding goal so we can properly track its progress:
>  > https://phabricator.kde.org/T6832
>  > 
>  > 
>  > 
>  > Can someone update this task with any outcome that came from this
>  > discussion? Was any change suggested here implemented? Is there anything
>  > else pending or that could be done to improve things?
>  > 
>  > 
>  > 
>  > Cheers,
>  > 
>  > Neofytos
>  > 
>  > 
>  > On Wed, Feb 28, 2018 at 12:23 PM, Boudewijn Rempt <b...@valdyas.org>
>  > wrote:
>  > 
>  > On Wednesday, 28 February 2018 08:58:51 CET Ilmari Lauhakangas wrote:
>  >  > What you need to focus on right now is not bikeshedding about statuses
>  >  > etc., but to recruit more and more QA/triagers. The QA team is
>  >  > Martin's
>  >  > "second level support". This is the primary solution.
>  >  
>  >  Yeah, I guess this is all just bikeshedding. Adding a status would help
>  >  me,
>  >  but it wouldn't solve the largest problem. And I don't personally thing
>  >  that s/UNCONFIRMED/NEW or vice versa would make any difference. If it
>  >  makes people happy, why not...
>  >  
>  >  > Two years ago we had essentially the same "should we add a TRIAGED
>  >  > status" -discussion over at LibreOffice, initiated by myself. This was
>  >  > almost purely thinking about QA workers, not developers - yes, we are
>  >  > that independent. In the end we did not add the status. It is hard to
>  >  > predict the effects of increasing complexity so we did not bother.
>  >  
>  >  That's a good point, too.
>  >  
>  >  
>  >  --
>  >  Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org




Reply via email to