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