https://bugs.freedesktop.org/show_bug.cgi?id=66986

--- Comment #7 from Joel Madero <[email protected]> ---
Apologies that I hurt your feelings mariosv - this was not the intended goal. I
have been involved with the project for quite some time and I was just trying
to explain policies in a way that made it clear where we stood. I'm not sure
why you marked the bug as INVALID if you're still seeing it (as perhaps someone
else COULD reproduce it but no one else will look at it if it's marked as
INVALID). 

The general rules are:
(1) If an experienced QA member (which I am one) cannot reproduce the bug we
mark as WFM and then ask user to retest, if they can still reproduce they mark
the bug as UNCONFIRMED and the QA member finds another person to retest. About
25% of our bugs are WFM, so this workflow keeps things moving and gets users to
retest their own bugs if a new version has come out or others are not
experiencing the same issue.

(2) You cannot put your own bug in MAB status - this includes QA members (I
have never once put one of my own bugs as MAB UNLESS it's a crasher). The
reason for this is quite simple, EVERYONE thinks their own bugs are MAB. We
need an independent judge to decide if it's MAB or not. Experienced QA members
have a general idea of what constitutes as a MAB. FWIW I have asked several
other QA members about this one and not one thought it was a MAB. If you
disagree, you can RESPECTFULLY explain why you think it is and ask us to
reconsider

(3) A bug should not be marked as REOPENED unless it was marked as FIXED by a
developer and then the reporter still sees the problem. Specifically a bug
should always be in UNCONFIRMED until reproduced by another person -- my
original comment specifically said "mark as UNCONFIRMED."

(4) A bug should not be a MAB unless it is marked as NEW (confirmed
independently by a second person). MAB get somewhat special treatment by top
developers - we don't want them wasting time until QA has at least confirmed
that the bug exists as their time is very valuable

These are guidelines that help us keep our bug tracker clean and helps keep
things organized in a way that means something. Otherwise we would have
thousands of MAB's as every user would put every bug in the status. 

Again, apologies if you were offended - we do appreciate the help that you've
given the project and hope to see you around still

All the best

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to