My 2c
"As Designed" should be the only answer. Bug is subjective. If the
user thinks the designed behaviour is
broken then they will always think of it as a bug. Invalid is worse,
because yes it tells the user they are an idiot.
Even if the program is working "As Designed" it does not mean its
fantastic, or couldn't be improved, also saying "as designed" does not
make any comment about the person logging the report (The other two
do). If someone spends a reasonable amount of time filling out a bug
report, then there may be work needed to an area even if it is working
"As Designed". Marking it "As Designed" would allow the conversation to
continue about what specifically regarding the "As Designed" behaviour
is problematic. "Invalid" and "Not a Bug" cut off continued dialogue
and look dogmatic/arrogant.
Steven
On 12/10/19 9:36 pm, Jeff Young wrote:
The main thing I didn’t like in the Launchpad workflow was the “Invalid” tag.
After one of our users spends a lot of time (or even a little) logging a bug,
it often gets their back up if you mark it “invalid”.
(In the past I’ve used systems that labelled this either “Not a Bug” or “As
Designed”. The later is probably the least triggering.)
Cheers,
Jeff.
On 12 Oct 2019, at 10:57, Nick Østergaard <[email protected]> wrote:
The document is still open for comments on
https://docs.google.com/document/d/1pRcqXIXSn1_Ep2mYtSnoJWFahi9fMx4UJ8UEwFFwLkQ/edit?usp=sharing
On Thu, 10 Oct 2019 at 11:30, Ian McInerney <[email protected]> wrote:
On a similar note, the issue workflow will need to be modified if the GitLab
tracker is used. Unfortunately, GitLab doesn't seem to have the same
functionality as the Launchpad tracker with respect to issue status and
severity. This might be a good time to finalize the earlier work that Nick had
started to formalize the issue process and the bug tracker workflow before we
transition to the GitLab tracker. That way we can define how we want to do this
from the outset. This will probably require some trial and error and
discussions to fully work it out.
-Ian
On Thu, Oct 10, 2019 at 8:51 AM Maciej Suminski <[email protected]> wrote:
On 10/10/19 2:30 AM, Andrew Lutsenko wrote:
<snip>
In terms of issues migration I think moving open issues via script and
locking down launchpad tracker is the best option. Even if migrated
issues and comments on them will be owned by some service account/bot.
It should be doable to include enough information there so that it's
clear who originally posted it and the context is not lost.
I agree, I am not sure if there is any added value in having correct
authors assigned to issues/comments, compared to displaying the
information in the contents field. Since I have spent some time
scripting both Launchpad and Gitlab, let me see how it can be done.
Cheers,
Orson
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
