Re: Improving Bugzilla Status Names
Andrew Crouthamel kirjoitti 5.9.2018 klo 5.28: d. If bug is not fixable due to technical limitations, or expected behavior, set to RESOLVED + ASDESIGNED. WONTFIX is also typically used to refuse to implement features that are out of scope or not aligned with a product vision. Just wanted to point out that in these cases ASDESIGNED does soften the message, but does not clarify it :) Ilmari
Re: Improving Bugzilla Status Names
On 09/04/2018 10:01 PM, Christoph Feck wrote: I still oppose to name a status NEW (again). It only attracts "how is this NEW? this is already [random timespan here] OLD!" comments. There will always be products/components that have no active maintainer to look for bugs in a limited timeframe. My suggestions are OPEN, REPORTED, or UNRESOLVED. I could get behind OPEN or REPORTED. Nate
Re: Improving Bugzilla Status Names
On 05.09.2018 04:28, Andrew Crouthamel wrote: Hello, As part of the "Streamlined onboarding of new contributors" goal from 2017 (https://phabricator.kde.org/T7116), Nate, myself, Julian, and others have been working on ways to clean up Bugzilla, as well as the bug reporting and triaging system in the "Improvements to Bugzilla - Making it easier and simpler" sub-task (https://phabricator.kde.org/T6832). The next item on the list we would like to address is changing some of the names of the Status fields and Resolved sub-fields. This is something that has come up numerous times, but seems to fizzle out without a consensus. The last major discussion regarding it was held early in the year, here: https://mail.kde.org/pipermail/kde-community/2018q1/004395.html. And before that, in this Bug report from Nate (https://bugs.kde.org/show_bug.cgi?id=383753). I've read through these, merging the feedback from everyone and with the team working on T6832 we'd like to propose the following name changes: UNCONFIRMED -> NEW WONTFIX -> ASDESIGNED INVALID -> NOTABUG I still oppose to name a status NEW (again). It only attracts "how is this NEW? this is already [random timespan here] OLD!" comments. There will always be products/components that have no active maintainer to look for bugs in a limited timeframe. My suggestions are OPEN, REPORTED, or UNRESOLVED. -- Christoph Feck
Re: Improving Bugzilla Status Names
+1 from me, needless to say. :) Nate On 09/04/2018 08:28 PM, Andrew Crouthamel wrote: Hello, As part of the "Streamlined onboarding of new contributors" goal from 2017 (https://phabricator.kde.org/T7116), Nate, myself, Julian, and others have been working on ways to clean up Bugzilla, as well as the bug reporting and triaging system in the "Improvements to Bugzilla - Making it easier and simpler" sub-task (https://phabricator.kde.org/T6832). The next item on the list we would like to address is changing some of the names of the Status fields and Resolved sub-fields. This is something that has come up numerous times, but seems to fizzle out without a consensus. The last major discussion regarding it was held early in the year, here: https://mail.kde.org/pipermail/kde-community/2018q1/004395.html. And before that, in this Bug report from Nate (https://bugs.kde.org/show_bug.cgi?id=383753). I've read through these, merging the feedback from everyone and with the team working on T6832 we'd like to propose the following name changes: UNCONFIRMED -> NEW WONTFIX -> ASDESIGNED INVALID -> NOTABUG This would keep the current bug triaging flow, but clarify and soften meanings for bug reporters. Example bug flow: 1. New bugs would be reported and assigned NEW. 2. Bugs are triaged and reviewed. a. If reproducible, bugs are set to CONFIRMED. b. If bug is not reproducible, more information is requested from the reporter and set to NEEDSINFO + WAITINGFORINFO. c. If bug is not a bug, set to RESOLVED + NOTABUG. d. If bug is not fixable due to technical limitations, or expected behavior, set to RESOLVED + ASDESIGNED. 3. After a set period of time, say 30 days, NEEDSINFO + WAITINGFORINFO bugs are set to RESOLVED + NOTABUG. This would allow triagers to come into a product and understand: 1. Which bugs need first review and reproducing, helping developers out by acting as that second-level support. (NEW) 2. Which need a second look or closure due to lack of information, reproducibility, and age. (NEEDSINFO + WAITINGFORINFO) 3. Which bugs are waiting for developer action such as patch development or decision to support a request, and probably do not need triager action. (CONFIRMED) This is a pretty minor change, as all it will do is make some words nicer and clarify the triaging process. Hopefully this is agreeable to everyone, we believe it is the best compromise between all of the feedback previously provided in the past two years. Feedback? Comments? Consensus? Thanks! Andrew Crouthamel
Improving Bugzilla Status Names
Hello, As part of the "Streamlined onboarding of new contributors" goal from 2017 (https://phabricator.kde.org/T7116), Nate, myself, Julian, and others have been working on ways to clean up Bugzilla, as well as the bug reporting and triaging system in the "Improvements to Bugzilla - Making it easier and simpler" sub-task (https://phabricator.kde.org/T6832). The next item on the list we would like to address is changing some of the names of the Status fields and Resolved sub-fields. This is something that has come up numerous times, but seems to fizzle out without a consensus. The last major discussion regarding it was held early in the year, here: https://mail.kde.org/pipermail/kde-community/2018q1/004395.html. And before that, in this Bug report from Nate (https://bugs.kde.org/show_bug.cgi?id=383753). I've read through these, merging the feedback from everyone and with the team working on T6832 we'd like to propose the following name changes: UNCONFIRMED -> NEW WONTFIX -> ASDESIGNED INVALID -> NOTABUG This would keep the current bug triaging flow, but clarify and soften meanings for bug reporters. Example bug flow: 1. New bugs would be reported and assigned NEW. 2. Bugs are triaged and reviewed. a. If reproducible, bugs are set to CONFIRMED. b. If bug is not reproducible, more information is requested from the reporter and set to NEEDSINFO + WAITINGFORINFO. c. If bug is not a bug, set to RESOLVED + NOTABUG. d. If bug is not fixable due to technical limitations, or expected behavior, set to RESOLVED + ASDESIGNED. 3. After a set period of time, say 30 days, NEEDSINFO + WAITINGFORINFO bugs are set to RESOLVED + NOTABUG. This would allow triagers to come into a product and understand: 1. Which bugs need first review and reproducing, helping developers out by acting as that second-level support. (NEW) 2. Which need a second look or closure due to lack of information, reproducibility, and age. (NEEDSINFO + WAITINGFORINFO) 3. Which bugs are waiting for developer action such as patch development or decision to support a request, and probably do not need triager action. (CONFIRMED) This is a pretty minor change, as all it will do is make some words nicer and clarify the triaging process. Hopefully this is agreeable to everyone, we believe it is the best compromise between all of the feedback previously provided in the past two years. Feedback? Comments? Consensus? Thanks! Andrew Crouthamel
Bugzilla product visibility change
Hello sysadmin! In https://phabricator.kde.org/T6832, we seemed to reach general agreement that products closed to new bugs shouldn't appear on the Browse page in bugzilla (https://bugs.kde.org/describecomponents.cgi). Is this a feasible change to make? Thanks, Nate
Re: Qt World Summit 2018
On 2018-09-04, Eike Hein wrote: > In the debrief, I think we were quite happy with how things went and > concluded if we get another chance, we'd try to do it again. The Qt > Company feels the same way, as they've reached out and offered similar > accomodations for this year as well. I think we should be more clear up front about what exactly the amount of work for the conference are. I'm not sure I'll attend again as a KDE person. There was too much being free worker and too little time to attend the conference part of the conference. I do think we should try harder to just be there with a KDE booth and a 4-8 people to man it in alternating schedules, and not do much other during conference time. /Sune
Re: Qt World Summit 2018
Hi Eike I want to be there, i miss last time event and should not miss this one. []'s On Tue, 4 Sep 2018 at 11:32, Eike Hein wrote: > > Hi, > > Qt World Summit 2018 is coming soon - this year it'll be a > smaller-scale, single-day event. Again in the bcc in Berlin, on December > 6th. > > Last year we managed to significantly raise the bar of KDE's presence at > the event, with a coordinated visual theme backed by assets such as crew > shirts, banners, stickets. We also managed to set ourselves apart from > vendors exhibiting at the event by doubling-down on more of a "part of > the Qt community" profile - our booth provided attendees a reprieve in > the form of device charging stations, and KDE showed its presence as > co-hosters of the event by assigning a person to every room and helping > run the show. > > Dot: https://dot.kde.org/2017/10/13/kde-powers-qt-world-summit > > In the debrief, I think we were quite happy with how things went and > concluded if we get another chance, we'd try to do it again. The Qt > Company feels the same way, as they've reached out and offered similar > accomodations for this year as well. > > I'd like us to take them up on the offer, as our relationship with the > Qt community and company remain of great importance to us. > > To do this we need people. Who can be in Berlin on December 6th to carry > our flag and represent KDE? > > > Cheers, > Eike >
Qt World Summit 2018
Hi, Qt World Summit 2018 is coming soon - this year it'll be a smaller-scale, single-day event. Again in the bcc in Berlin, on December 6th. Last year we managed to significantly raise the bar of KDE's presence at the event, with a coordinated visual theme backed by assets such as crew shirts, banners, stickets. We also managed to set ourselves apart from vendors exhibiting at the event by doubling-down on more of a "part of the Qt community" profile - our booth provided attendees a reprieve in the form of device charging stations, and KDE showed its presence as co-hosters of the event by assigning a person to every room and helping run the show. Dot: https://dot.kde.org/2017/10/13/kde-powers-qt-world-summit In the debrief, I think we were quite happy with how things went and concluded if we get another chance, we'd try to do it again. The Qt Company feels the same way, as they've reached out and offered similar accomodations for this year as well. I'd like us to take them up on the offer, as our relationship with the Qt community and company remain of great importance to us. To do this we need people. Who can be in Berlin on December 6th to carry our flag and represent KDE? Cheers, Eike
Re: Default bug editing privileges can't change Importance field
Ok great, thanks for clearing that up. I'll make sure to add that information to the Bug Triaging wiki page. Sent from ProtonMail mobile Original Message On Sep 4, 2018, 2:46 AM, David Edmundson wrote: > It's not a mistake. From the thread where permissions are relaxed: > >>How about we make it so that normal users have full privilages except the >>following: >> >>- Can't bulk change >>- Can't change Importance field >>- Can't re-open bugs in the CLOSED state > > For a user user the bug that affects them is always the most important. > We need something for devs to still be able to use. > > If you're a triager/developer we can get you edit rights. > > David
Re: Default bug editing privileges can't change Importance field
It's not a mistake. From the thread where permissions are relaxed: >How about we make it so that normal users have full privilages except the following: > >- Can't bulk change >- Can't change Importance field >- Can't re-open bugs in the CLOSED state For a user user the bug that affects them is always the most important. We need something for devs to still be able to use. If you're a triager/developer we can get you edit rights. David
