On 03/22/2016 09:37 AM, Marcus wrote:
> 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: dev@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.
I would prefer DONE. MANAGED seems too nebulous to me.
I am also assuming that once RESOLVED-DONE is set, the issue
can be formally closed(?)
This has been a really good discussion by the way.
>
>> 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
>
>
--
--------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
