Re: Can we add the value "N/A" to the Target Milestone field

[Marcus]

Am 03/31/2016 07:40 PM, schrieb Andrea Pescetti:

Marcus wrote:

OK, as there were no further comments and no real disagree I'll create a
new RESOLVED - NOCODEFIX resolution status. This status should be set
when an issue was solved with no change in the source code (e.g., user
requests or how-to questions).


What's the maximum length? Maybe FIXED_WITHOUT_CODE is even more
intuitive (but OK for me with the other option too!).


I've created both and got no problem or error message.

OK, you won ;- ) : New status is FIXED_WITHOUT_CODE.

Marcus


-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org

Re: Can we add the value "N/A" to the Target Milestone field

[Marcus]

[Top-Posting]

OK, as there were no further comments and no real disagree I'll create a 
new RESOLVED - NOCODEFIX resolution status. This status should be set 
when an issue was solved with no change in the source code (e.g., user 
requests or how-to questions).


For every fix that touches the source code please use as always the 
RESOLVED - FIXED resolution status.


Marcus



Am 03/26/2016 10:58 AM, schrieb Marcus:

Am 03/26/2016 10:50 AM, schrieb Andrea Pescetti:

Marcus wrote:

Am 03/26/2016 12:13 AM, schrieb Andrea Pescetti:

If the aim is to create less confusion, all proposals I've seen have
the
result of bringing more confusion! So:

I don't see why this brings more confusion. It's the opposite, one
status for "resolved with a code fix" and the other for "resolved
somehow else".


It brings more confusion since it would need to be explained explicitly
(because DONE or MANAGED would apply, looking purely at their meaning,
to a code fix too, and it's only a convention that we use them for
"no-code" fixes only).


maybe, but the whole BZ can be confusing - especially for normal users. ;-)

 > And if we have more intuitive options I feel this would be better.

Do you have any idea in mind?


It doesn't have to be "NOCODE", but it should be
something that means "nothing to do with code", and DONE does not
really
convey the right meaning here.

Then NOCODEFIX sounds more concrete.


Yes, NOCODEFIX sounds good too. Again, so long as it is a word that a
developer cannot be mistaken into choosing instead of FIXED, it will be
OK for me. What we want to avoid is that a developer accidentally uses
DONE for a code fix and the issue is suddenly not listed in QA and
similar.


I got the idea to rename FIXED into FIXEDINCODE. Unfortunatelly, it's a
default and therefore a non-changeable name. :-(


-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org

Re: Can we add the value "N/A" to the Target Milestone field

[Marcus]

Am 03/22/2016 04:48 PM, schrieb Dennis E. Hamilton:

Many interesting ideas, ...


-Original Message-
From: Carl Marcum [mailto:cmar...@apache.org]
Sent: Tuesday, March 22, 2016 03:35
To: d...@openoffice.apache.org
Subject: Re: Can we add the value "N/A" to the Target Milestone field

On 03/22/2016 05:02 AM, Marcus wrote:

Am 03/22/2016 10:00 AM, schrieb Marcus:

[ ,,, ]

[ ... ] what about RESOLVED -

MANAGED?

This word is maybe better known in the world. This term shows that

the

issue has some work in it and was tackled. With a closing comment you
can see where and why it was successful managed (resolved).


from Jira I also know that RESOLVED - DONE is a common way to say that
an issue was successfully resolved.

Marcus


Having a RESOLVED - DONE would be especially good for tasks also.


[orcmid]

MANAGED is interesting because of its flexibility. How it was managed should be 
accounted for in the commentary.


ACK


DONE does seem to apply to Tasks and Enhancement requests.


Right, and user requests are very often nothing else (e.g., "my document 
is broken, how to repair it?").



DECLINED also seems to apply to both Tasks and Enhancements.  It is also a 
counterpart to ACCEPTED in those cases.


Yes, it doesn't indicate that there is a solution/workaround available.

@all:
It seems we could have a consensus in creating a new MANAGED or DONE 
status to set when issues are no real code problems, but more 
user-oriented. Finally, they were solved for the user's satisfaction 
(e.g., provided how-to's or repaired documents, etc.). However, no fix 
in the source code has been done.



At qa@ Pedro Lino made some useful observations about how terms impact 
reporters and observers of the Bugzilla activity.

In respect to that, I have been using WONTFIX as a way to indicate that we have 
no capacity to do anything about an issue, especially a longstanding one.  This 
is primarily a way of discouraging non-project commenters arguing among 
themselves and to also indicate that the issue is understood, recognized, and 
continued lobbying is not useful.  I think DECLINED may be useful in some of 
those cases, but WONTFIX is more truthful when the project doesn't have a way 
to do anything.  NOTFIXING is closer to the reality.  (CANTFIX would also 
indicate that the problem is not with the issue, but with project capability at 
this time.)  The door is not closed completely, but it is not clear when the 
door will ever be opened.

I agree that we do need a diagram and a description of the general application 
of Bugzilla categories and resolution cases.  We might also need to revisit how 
the search defaults work with respect to the various categories.  This seems 
like a good Wiki [update] effort.  We also don't want to split things into so 
many categories that application and understanding becomes more difficult.


After we have an agreement I can take over this task to grep the data in 
Wiki to consolidate and update them with the new information.


Marcus


-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org

Re: Can we add the value "N/A" to the Target Milestone field

[Pedro Lino]

> It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED
>>> - NOTOURBUG is not much better than NOTANISSUE.
>>>
>>> RESOLVED - HANDLED might be closer, with the comment that achieves
>>> this explains how it is handled. (I.e., documentation, workaround,
>>> whatever.)
>>>
>>> I'm not in love with that term and don't know how it works for
>>> non-native English-language participants.
>>>
>>
>> I like it as it is more general. However, what about RESOLVED - MANAGED?
>> This word is maybe better known in the world. This term shows that the
>> issue has some work in it and was tackled. With a closing comment you
>> can see where and why it was successful managed (resolved).
>>
>
> from Jira I also know that RESOLVED - DONE is a common way to say that an
> issue was successfully resolved.
>

NOT_AN_ISSUE seems a bad option. The problem which is affecting someone is
dismissed. In my opinion it is as as offensive as WORKSFORME (used in
LibreOffice) and WONT_FIX (used in both projects)

HANDLED, MANAGED only applies if there are workarounds (which is not always
the case).

NOTOURBUG means that the Devs looked at it and although they recognize it's
a problem, there is nothing they can do because the problem is somewhere
else.
I agree it's a but short and rough but it's difficult to be nice and
meaningful with a single word (or glued words). This can be further
explained in the Comments when changing status if the developer is in such
a mood...

NOTABUG could be used instead of WONT_FIX (when it's reported as a bug but
AOO decides it is working as expected) and DECLINED when it's a
suggestion/enhancement (and AOO decides it is not interesting/productive)

Just my 2 cents ;)

Re: Can we add the value "N/A" to the Target Milestone field

[Marcus]

Am 03/22/2016 10:00 AM, schrieb Marcus:

Am 03/22/2016 03:37 AM, schrieb Dennis E. Hamilton:



-Original Message-
From: Pedro Lino [mailto:pedl...@gmail.com]
Sent: Monday, March 21, 2016 16:53
To: qa@openoffice.apache.org
Subject: Re: Can we add the value "N/A" to the Target Milestone field


It's not about to draw the line between issues that are resolved and
verified solutions. It's about to differentiate issues that are in the

real

application and therefore need to be fixed in the source code. Here we

use

(or better should use) RESOLVED - FIXED.

But what about issues that are also reporting a problem but the

solution

(if there is any) is somewhere else? RESOLVED - FIXED doesn't fit,

RESOLVED

- NOT_AN_ISSUE also not.



Why not use the same nomenclature as the "sibling project"? RESOLVED -
NOTOURBUG

[orcmid]

It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED
- NOTOURBUG is not much better than NOTANISSUE.

RESOLVED - HANDLED might be closer, with the comment that achieves
this explains how it is handled. (I.e., documentation, workaround,
whatever.)

I'm not in love with that term and don't know how it works for
non-native English-language participants.


I like it as it is more general. However, what about RESOLVED - MANAGED?
This word is maybe better known in the world. This term shows that the
issue has some work in it and was tackled. With a closing comment you
can see where and why it was successful managed (resolved).


from Jira I also know that RESOLVED - DONE is a common way to say that 
an issue was successfully resolved.


Marcus


-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org

Re: Can we add the value "N/A" to the Target Milestone field

[Marcus]

Am 03/22/2016 12:52 AM, schrieb Pedro Lino:

It's not about to draw the line between issues that are resolved and
verified solutions. It's about to differentiate issues that are in the real
application and therefore need to be fixed in the source code. Here we use
(or better should use) RESOLVED - FIXED.

But what about issues that are also reporting a problem but the solution
(if there is any) is somewhere else? RESOLVED - FIXED doesn't fit, RESOLVED
- NOT_AN_ISSUE also not.



Why not use the same nomenclature as the "sibling project"? RESOLVED -
NOTOURBUG


in general it's OK to look for other projects how they handle such 
problems. But NOTOURBUG sounds really ignorant and a bit offensive - at 
east in my ears. When I think about the users that reporting such issues 
and mostly they think it's important because they cannot go on with 
their work, then they deserve a more meaningful status name.


Dennis has made a good suggestion where I'll go on with answering.


I believe Apache QA needs a flowchart such as
https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_Flowchart_Version_0.1.pdf
https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg


I'm pretty sure we have a similar flow chart somewhere in the depths of 
our Wiki. But yes, in general this would help to understand how the 
issue statuses are working together.


Marcus


-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org

RE: Can we add the value "N/A" to the Target Milestone field

[Dennis E. Hamilton]

> -Original Message-
> From: Pedro Lino [mailto:pedl...@gmail.com]
> Sent: Monday, March 21, 2016 16:53
> To: qa@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
> 
> > It's not about to draw the line between issues that are resolved and
> > verified solutions. It's about to differentiate issues that are in the
> real
> > application and therefore need to be fixed in the source code. Here we
> use
> > (or better should use) RESOLVED - FIXED.
> >
> > But what about issues that are also reporting a problem but the
> solution
> > (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit,
> RESOLVED
> > - NOT_AN_ISSUE also not.
> >
> 
> Why not use the same nomenclature as the "sibling project"? RESOLVED -
> NOTOURBUG
[orcmid] 

It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED - 
NOTOURBUG is not much better than NOTANISSUE. 

RESOLVED - HANDLED might be closer, with the comment that achieves this 
explains how it is handled.  (I.e., documentation, workaround, whatever.)
 
I'm not in love with that term and don't know how it works for non-native 
English-language participants.

> 
> I believe Apache QA needs a flowchart such as
> 
https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_ 
Flowchart_Version_0.1.pdf
> https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg
[orcmid] 

That's a useful companion topic.  (The PDF is apparently defective - Acrobat 
Reader doesn't see anything in it on Windows.)

The .odg works though. I don't like that flowchart much.  I don't think it 
covers the range that is needed for us.   Perhaps it is incomplete and just 
deals with the front-end of issue triage?




-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org

Re: Can we add the value "N/A" to the Target Milestone field

[Pedro Lino]

> It's not about to draw the line between issues that are resolved and
> verified solutions. It's about to differentiate issues that are in the real
> application and therefore need to be fixed in the source code. Here we use
> (or better should use) RESOLVED - FIXED.
>
> But what about issues that are also reporting a problem but the solution
> (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit, RESOLVED
> - NOT_AN_ISSUE also not.
>

Why not use the same nomenclature as the "sibling project"? RESOLVED -
NOTOURBUG

I believe Apache QA needs a flowchart such as
https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_Flowchart_Version_0.1.pdf
https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg

Re: Can we add the value "N/A" to the Target Milestone field

[Pedro Lino]

On Mon, Mar 21, 2016 at 10:32 PM, Marcus  wrote:

> Am 03/21/2016 10:36 PM, schrieb Kay Schenk:
>
>> [top posting]
>>
>> Thanks for all the help with this and for the new NONE for
>> target release. Hopefully, it will be used sparingly
>> assuming we us e RESOLVED-FIXED as only for issues in which
>> an actual commit is used. Issue 126828 has now been changed
>> to UNCONFIRMED. How to differentiate UNCONFIRMED from
>> RESOLVED--NOT AN ISSUE will be a challenge. Hopefully, this
>> can be clarified to our QA helpers
>>
>
> I repeat my suggestion for another resolution status as it maybe got lost
> in people's inboxes.
>
> My suggestion is to create a RESOLVED - RESOLVED status. Maybe still to
> close to RESOLVED - FIXED, but then let's see if there are better wordings.
>

There is already a final status after RESOLVED - FIXED. It's VERIFIED -
FIXED. It is set after a QA member verifies that the fix actually solved
the problem and that it does not occur in the RC.

Hope this helps.

Re: Can we add the value "N/A" to the Target Milestone field

[Kay Schenk]

[top posting]

Thanks for all the help with this and for the new NONE for
target release. Hopefully, it will be used sparingly
assuming we us e RESOLVED-FIXED as only for issues in which
an actual commit is used. Issue 126828 has now been changed
to UNCONFIRMED. How to differentiate UNCONFIRMED from
RESOLVED--NOT AN ISSUE will be a challenge. Hopefully, this
can be clarified to our QA helpers

And, dang, one my examples was NOT a correct illustration of
the problem. Too many BZ windows open yesterday I guess.

Ok, back to my investigations.

On 03/21/2016 12:05 PM, Dennis E. Hamilton wrote:
> 
> 
>> -Original Message- From: Patricia Shanahan
>> [mailto:p...@acm.org] Sent: Monday, March 21, 2016
>> 09:10 To: d...@openoffice.apache.org Subject: Re: Can we
>> add the value "N/A" to the Target Milestone field
>> 
>> On 3/21/2016 8:59 AM, Kay Schenk wrote:
>>> On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton
>> <dennis.hamil...@acm.org
>>>> wrote:
>>> 
>>>> I want to clarify this.
>>>> 
>>>> I think the problem might be that "Resolved -
>>>> Fixed" is being used incorrectly. As far as I know,
>>>> there are many cases where this
>> resolution
>>>> is used where one of "Resolved - Not an Issue"
>>>> (though not too
>> often),
>>>> "Resolved - Irreproducible", "Resolved - Won't
>>>> Fix", or "Resolved - Obsolete" should be used.
>>>> 
>>>> Is that what you are seeing, Kay?
>>>> 
>>> 
>>> ​Well  maybe so. In the past, I have used
>>> RESOLVED-FIXED to determine what's been committed to
>>> our source, thus leading to a Target Release. 
>>> Yesterday, I started going through RESOLVED-FIXED
>>> items to be sure
>> some of
>>> these fixed issued did have a Target Release. Some of
>>> these RESOLVED-
>> FIXED
>>> issues seem to be either user support
>>> issues/questions that do not
>> entail
>>> source code corrections at all, or similar type
>>> situations. In one of
>> the
>>> cases I sited above, I think the issue originator
>>> marked it with RESOLVED-FIXED, and really i don't
>>> know if this was the right thing to
>> do
>>> or not.
> [orcmid]
> 
> My impression is that original reporters rarely do this
> and might not even have the necessary karma.
> 
> As you can see in one of the two you linked to, I was the
> guilty culprit [;<).
> 
>>> 
>>> So, we can use the new NONE (thank you Marcus!) as
>>> the Target Release,
>> or
>>> do something else to ignore these types of issues for
>>> verification in
>> a
>>> build. The problem is stemming from the use of BZ as
>>> both a code centric
>> problem
>>> reporting mechanism and a user support tool.
>> 
>> I don't think it should be marked RESOLVED-FIXED unless
>> it was actually fixed, and therefore has a release in
>> which the fix first appears. To me, RESOLVED-FIXED with
>> a target release of NONE is self-contradictory.
>> 
>> What is the objection to changing the resolution to
>> reflect reality?
>> 
>> For example, if it was a user support issue that does
>> not entail a source code correction, shouldn't it be
>> marked RESOLVED - NOT_AN_ISSUE rather than RESOLVED -
>> FIXED with a target date of NONE?
> [orcmid]
> 
> I agree that RESOLVED - FIXED might be inappropriate in
> many cases.  However, RESOLVED - NOT AN ISSUE is often
> too heavy-handed.  It can clearly be an issue to users,
> especially when it is an identifiable usability matter
> although not a code bug, but still there may be some
> clear product-behavior deficiency.  And the issue may be
> recognized as such by the project, too.
> 
> The problem is "Issue for Whom," when it is about a
> deficiency in the product but not a bug in the
> conventional sense.  Since we our software is
> user-facing, it would be good to own that such issues are
> issues for us as providers of something valuable to
> users. BZ is our basic mechanism for existence and
> attention to such cases.
> 
> I also recall seeing "NOT AN ISSUE" used when
> IRREPRODUCIBLE might be a better matter (i.e., when the
> reporter fails to provide needed details to know
> specifically what the matter is).
> 
> Also, sometimes the "fix" is elsewhere (i.e.,
> documentation, workarounds on a wiki, whatever).  I
> suppose that means CONFIRMED but not acte

Fwd: Can we add the value "N/A" to the Target Milestone field

[Kay Schenk]

Forgot to copy qa on my reply.

-- Forwarded message --
From: Kay Schenk <kay.sch...@gmail.com>
Date: Mon, Mar 21, 2016 at 8:59 AM
Subject: Re: Can we add the value "N/A" to the Target Milestone field
To: OOo Apache <d...@openoffice.apache.org>, Dennis Hamilton <
dennis.hamil...@acm.org>



On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton <dennis.hamil...@acm.org
> wrote:

> I want to clarify this.
>
> I think the problem might be that "Resolved - Fixed" is being used
> incorrectly. As far as I know, there are many cases where this resolution
> is used where one of "Resolved - Not an Issue" (though not too often),
> "Resolved - Irreproducible", "Resolved - Won't Fix", or "Resolved -
> Obsolete" should be used.
>
> Is that what you are seeing, Kay?
>

​Well  maybe so. In the past, I have used RESOLVED-FIXED to determine
what's been committed to our source, thus leading to a Target Release.
Yesterday, I started going through RESOLVED-FIXED items to be sure some of
these fixed issued did have a Target Release. Some of these RESOLVED-FIXED
issues seem to be either user support issues/questions that do not entail
source code corrections at all, or similar type situations. In one of the
cases I sited above, I think the issue originator marked it with
RESOLVED-FIXED, and really i don't know if this was the right thing to do
or not.

So, we can use the new NONE (thank you Marcus!) as the Target Release, or
do something else to ignore these types of issues for verification in a
build.
The problem is stemming from the use of BZ as both a code centric problem
reporting mechanism and a user support tool.
​

>
> In those cases, it is preferable to change the resolution.
>
> > -Original Message-
> > From: Andrea Pescetti [mailto:pesce...@apache.org]
> > Sent: Sunday, March 20, 2016 14:09
> > To: qa@openoffice.apache.org; d...@openoffice.apache.org
> > Subject: Re: Can we add the value "N/A" to the Target Milestone field
> >
> > Kay Schenk wrote:
> > > We seem to have a number of issues in BZ that are now listed
> > > as Resolved/Fixed but don't seem to pertain to an actual
> > > upcoming release.
> >
> > Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is
> > a perfectly valid value for these cases.
> >
> > Just to be clear: 4.1.2 was a maintenance release and issues had to be
> > approved as release blockers in that case. 4.2.0 will be a normal
> > release, made from trunk, so everything that is on trunk (untile a
> > certain moment when we will decide to branch) will be into it
> > automatically. So the target is 4.2.0 in those cases.
> >
> > Regards,
> >Andrea.
> >
> > -
> > To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: qa-h...@openoffice.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
--
MzK

"Time spent with cats is never wasted."
-- Sigmund Freud




-- 
--
MzK

"Time spent with cats is never wasted."
-- Sigmund Freud

RE: Can we add the value "N/A" to the Target Milestone field

[Dennis E. Hamilton]

Thanks for the "None" Target, Marcus.

> -Original Message-
> From: Marcus [mailto:marcus.m...@wtnet.de]
> Sent: Sunday, March 20, 2016 15:38
> To: d...@openoffice.apache.org
> Cc: qa@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
> 
> Am 03/20/2016 09:08 PM, schrieb Kay Schenk:
> > We seem to have a number of issues in BZ that are now listed
> > as Resolved/Fixed but don't seem to pertain to an actual
> > upcoming release.
> >
> > Examples:
> > https://bz.apache.org/ooo/show_bug.cgi?id=126652
> > https://bz.apache.org/ooo/show_bug.cgi?id=126828
> >
> > Can we add something like "N/A" or the like to our Target
> > Milestone field rather than the default "--" so we know
> > these should never be considered for a release?
> 
> sounds reasonable. I've added an "None" to the list of available
> milestones for many products (the application modules and related
> things).
> 
> Marcus
> 
> 
> -
> To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: qa-h...@openoffice.apache.org


-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org

Can we add the value "N/A" to the Target Milestone field

[Kay Schenk]

To our BZ admins.

We seem to have a number of issues in BZ that are now listed
as Resolved/Fixed but don't seem to pertain to an actual
upcoming release.

Examples:
https://bz.apache.org/ooo/show_bug.cgi?id=126652
https://bz.apache.org/ooo/show_bug.cgi?id=126828

Can we add something like "N/A" or the like to our Target
Milestone field rather than the default "--" so we know
these should never be considered for a release?

Thanks.
-- 

MzK

"Time spent with cats is never wasted."
   -- Sigmund Freud

-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org