Re: Let's get rid of UNCONFIRMED/CONFIRMED

[David Edmundson]

We have a thread where someone proposes removing statuses, and a proposal
which involves adding a status :/
That doesn't sound like we're unified on what we need at all.

​Personally I would use flags for this "reproducible" or not.

Advantages are:
 - it visibly lists who could reproduce it in a way that is retained after
status changes  (if set up as "multiplicable") and optionally even shows
who has tried and can't.

 - we can enable it per-product (doesn't even need a sysadmin)

 - we don't have to do a difficult migration over bugzilla.  Renaming some
fields is one thing, modifying the core is a lot of work and dangerous.



That hopefully frees up unconfirmed/confirmed to be back to their meaning of

 "do I need anything else from the reporter?"
yes -> needs info
no -> confirmed/resolved

which is how I'd like things to be

David

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Luigi Toscano]

Adriaan de Groot ha scritto:
> On Tuesday, 10 April 2018 19:18:07 CEST, Nate Graham wrote:
>> 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
>>
> 
> Is bugzilla really that hard to configure with a workflow? I ran into this
> recently with the FreeBSD bugzilla as well, where I needed extra information
> and this might be encoded into some fields -- but not into the status field,
> which is infuriatingly "new", "open", "in progress", "closed".

You can, iirc. It's more a human problem with the policy.

http://bugzilla.readthedocs.io/en/latest/administering/workflow.html


See my previous attempt on this list:
https://mail.kde.org/pipermail/kde-community/2016q4/003262.html

-- 
Luigi

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Nate Graham]

 On Tue, 10 Apr 2018 10:50:19 -0700 Albert Astals Cid wrote 
 
 > El dimarts, 10 d’abril de 2018, a les 19:43:51 CEST, Nate Graham va 
 > escriure: 
 > >  On Tue, 10 Apr 2018 10:29:54 -0700 Albert Astals Cid 
 > > wrote  
 > >  > 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. 
 > >  
 > > A "confirmed" status only makes sense as a contrast to "unconfirmed". For 
 > > bugs, we want that status because bugs that have been triaged and cannot 
 > > be 
 > > reproduced yet may be reproducible by someone else at some point in the 
 > > future. 
 > >  
 > > But for wishes it's different: if a "confirmed" status for a wishlist bug 
 > > means "Somebody looked at it and it is a wish that makes sense", then the 
 > > corresponding opposite "unconfirmed" status would be "Somebody looked at 
 > > it 
 > > and it is NOT a wish that makes sense." In this case, the correct course 
 > > of 
 > > action is to close it as RESOLVED WONTFIX or INVALID; there is no need to 
 > > keep open a wishlist bug that the developers have no intention of 
 > > implementing. 
 >  
 > So how do you propose i differentiate with items i have looked at from the  
 > ones i have not looked at yet when doing a search in bugzilla if they are 
 > both  
 > marked as OPEN? 

Ah I see what you mean now. Yes, that makes sense.

Nate

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Albert Astals Cid]

El dimarts, 10 d’abril de 2018, a les 19:43:51 CEST, Nate Graham va escriure:
>  On Tue, 10 Apr 2018 10:29:54 -0700 Albert Astals Cid
> wrote 
>  > 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.
> 
> A "confirmed" status only makes sense as a contrast to "unconfirmed". For
> bugs, we want that status because bugs that have been triaged and cannot be
> reproduced yet may be reproducible by someone else at some point in the
> future.
> 
> But for wishes it's different: if a "confirmed" status for a wishlist bug
> means "Somebody looked at it and it is a wish that makes sense", then the
> corresponding opposite "unconfirmed" status would be "Somebody looked at it
> and it is NOT a wish that makes sense." In this case, the correct course of
> action is to close it as RESOLVED WONTFIX or INVALID; there is no need to
> keep open a wishlist bug that the developers have no intention of
> implementing.

So how do you propose i differentiate with items i have looked at from the 
ones i have not looked at yet when doing a search in bugzilla if they are both 
marked as OPEN?

Cheers,
  Albert

> 
> Nate

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Nate Graham]

 On Tue, 10 Apr 2018 10:29:54 -0700 Albert Astals Cid wrote 
 
 > 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. 


A "confirmed" status only makes sense as a contrast to "unconfirmed". For bugs, 
we want that status because bugs that have been triaged and cannot be 
reproduced yet may be reproducible by someone else at some point in the future.

But for wishes it's different: if a "confirmed" status for a wishlist bug means 
"Somebody looked at it and it is a wish that makes sense", then the 
corresponding opposite "unconfirmed" status would be "Somebody looked at it and 
it is NOT a wish that makes sense." In this case, the correct course of action 
is to close it as RESOLVED WONTFIX or INVALID; there is no need to keep open a 
wishlist bug that the developers have no intention of implementing.

Nate 

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Adriaan de Groot]

On Tuesday, 10 April 2018 19:18:07 CEST, Nate Graham wrote:

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



Is bugzilla really that hard to configure with a workflow? I ran into this 
recently with the FreeBSD bugzilla as well, where I needed extra 
information and this might be encoded into some fields -- but not into the 
status field, which is infuriatingly "new", "open", "in progress", 
"closed".


TRAC is a bug tracker that does this well: 
https://trac.edgewall.org/wiki/TracWorkflow


The default workflow is pretty straightforward, but it's easy to customize 
to take into account wishlist items, triage and QA teams, etc. And it can 
spit out a diagram of its own workflow if you ask nicely.


[ade]

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Albert Astals Cid]

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 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 
>  > 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

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Nate Graham]

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?

Nate



 On Tue, 10 Apr 2018 09:10:00 -0700 tetris4 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  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
 >  
 >  
 >  
 > 
 > 
 > 
 > 
 >  
 > 

Re: bugzilla, it's products, how they relate to projects. it's a mess...

[tetris4]

Hi all,

A bit late to the party, yet I'm responsible for the Streamlined Onboarding
goal and Bugzilla seems to be a hot topic relating to this. Nate had even
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 so I reopened it as a sub-task:
https://phabricator.kde.org/T6832

Can we continue the discussion there?

Cheers,
Neofytos





On Thu, Feb 1, 2018 at 3:36 PM, Boudewijn Rempt  wrote:

> On Thursday, 1 February 2018 14:31:46 CET Adriaan de Groot wrote:
> > On Thursday, February 1, 2018 7:20:11 AM EST Ilmari Lauhakangas wrote:
> > > On 01.02.2018 12:50, Boudewijn Rempt wrote:
> > > > On Wednesday, 31 January 2018 20:44:13 CET Ilmari Lauhakangas wrote:
> > > >> In LibreOffice, we only restrict priority and severity and even
> those
> > > >> upwards from medium/normal. We monitor messy stuff with a script:
> > > >> https://gerrit.libreoffice.org/gitweb?p=dev-tools.git;a=
> history;f=esc-r
> > > >> ep
> > > >> ort ing/qa-tools.py
> > > >
> > > > That looks pretty interesting!
> > >
> > > If anyone wants to have a chat with Xisco about the script, he will be
> > > at FOSDEM: https://fosdem.org/2018/schedule/track/open_document_
> editors/
> >
> > That's great -- perhaps we can sit down near the KDE booth with Boud and
> > Xisco and some others to work on a way to clean up and to provide better
> > onboarding for triagers. "Do the stuff that needs doing and make a plan",
> > let's say.
> > > This has a mugshot:
> > > https://blog.documentfoundation.org/blog/2016/08/31/presenting-xisco-
> fauli
> > > -t he-new-qa-engineer/
> >
> > Well that doesn't help, he looks exactly the same as at least 3000 other
> > people at FOSDEM, with glasses, beard and a geeky smile.
> >
> > I'll look out for him too (with my glasses, beard, and geeky smile :) )
>
> Maybe I should shave off my beard tomorrow morning... Or, I could don a
> suit!
>
>
> --
> Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org
>
>
>

Re: KDE goals IRC office hour

[tetris4]

Hi all,

As ade mentioned, this directly relates to the onboarding goal and it's
indeed something we can improve. I started an issue on Phabricator to make
sure this topic is properly tracked:
https://phabricator.kde.org/T8484

Can we continue the discussion there?

Cheers,
Neofytos

On Mon, Mar 19, 2018 at 3:33 PM, Adriaan de Groot  wrote:

> On Sunday, 18 March 2018 11:43:00 CET, Ilmari Lauhakangas wrote:
>
>> Thanks also to Raphael Catolino for the original Docker work and for
>> still keeping at it. This is valuable not only for KDE, but for LibreOffice
>> as well while we evaluate this thing.
>>
>
> So I was just playing with the Janitor service. The KDE container is
> rather broken (no desktop shell packages installed, so you don't get a
> desktop or anything, and if the screen locker comes up, then there's no way
> to enter a password -- keypresses are not registered), so I tried the
> Thunderbird container instead.
>
> What you get is noVNC in a browser tab, to a container instance just for
> you. You get a checkout of the sources of Thunderbird, plus whatever
> development tools you need to edit, build, and test Thunderbird. Well, I
> assume so -- TB itself has no README, INSTALL or HACKING file, and running
> configure tells me that the mail application is missing. But, in theory, if
> I knew how to work on TB, I could.
>
> So it's really cool, actually: "I want to help with " translates to
> "start browser and point at foo-on-janitor", and assuming foo is set up
> there, bam, start hacking already.
>
> It is not really clear how one would submit changes afterwards -- I guess
> it would be useful to have a "log in to GH" or "log in to KDE Phab" link on
> the desktop to make that kind of thing clear to drive-by contributors.
> Afterwards, you can just delete the container and it's gone. This could be
> *really* useful for those drive-by contributors, or people asking "how do I
> get started?" There is a risk, in the sense that pushing one container with
> one set of tools and one underlying distro *might* skew the kind of
> contributors we get.
>
> I suppose we should do FreeBSD + Clang + Plasma as a devel container, then
> new contributors will write non-Linuxism, non-GCCism code without noticing
> what's underneath, right? (I kid, I kid .. syscall numbers don't match up).
>
> Right now the service is invite-only, and some of the user-handling is a
> little weird. Once you're in the system, logging in (in the web browser, to
> be able to manage your containers) works like this:
> - enter email address in login page
> - get email, which has a one-time link which logs you in
> - click on link, and use the resulting browser tab for managing
>
> The (web) UI has a couple of quirks, mainly that clicking on things
> changes the cursor to "forbidden" while things happen, which can take quite
> a while. So sometimes it's click, wait, wait, hope that it completed. I
> understand there are multiple improvements to the web-UI in the works.
>
> My plan right now is to play with the KDE docker file until I get a feel
> for what's actually there, and to massage it (or rather, I'll suggest
> changes to R.Catolino, who maintains that particular dockerfile) towards
> some kind of "you want this workflow" setup. I somehow doubt that setting
> up a container for all possible kinds of KDE development is useful (you can
> already sort of see this in Janitor -- it's not like Rust, Firefox and
> Thunderbird are all jammed into one container, either). So in first
> instance, I'll be aiming for an up-to-date (-ish) Plasma desktop with dev
> tools installed ready to work on KMyMoney and Okular (an arbitrary
> selection).
>
> [ade]
>