Talk:QA/Meetings/2013/April 19

    From The Document Foundation Wiki

    Some quick thoughts

    QA/Meetings/2013/April 19#PENDING ITEM: What to do with FDO bugs filed against Extensions.2C Templates

    I recommend not to proceed as written. I have added me as default QA contact because I can quickly narrow down the reasons of the problem and contact the author directly directly if it seems to be a real bug. Currently there is no way to contact authors directly via Extensions website, and there are some good reasons not to spread contact addresses too wide, that might be abused as support contact. -- Rainer Bielefeld 2013-04-20T15:05:50 (UTC)

    Hi Rainer -- User:Jmadero has taken up the lead on this particular Action item. I'd ping him directly to make sure that he saw your email reply pointing at this page.

    • Regarding setting you as the Default QA Contact, I think one of the concerns was that we have a "bus factor" of one -- i.e., if we lose you, we don't have a 2nd person to fill your shoes.
    • We also didn't reach agreement that the QA Team should handle all Extension-related bugs. If we do set someone (you, etc..) as the Default QA Contact, that would seemingly give the appearance that we would make sure that the bug got fixed. We felt like we weren't sure the QA Team was ready to take on that responsibility, at least not until we had more assurances that we'd be able to hand bugs to extension authors.

    -- Qubit (talk) 2013-04-20T21:27:08 (UTC)

    Hi Rainer, there are essentially two scenarios:

    • users dont contact the extension authors at all, in which case, the bugs will silently die at some point
    • users contact the extensions authors via the contact address on extensions. If such requests become overwhelming to the extensions site, its admins will find a way to improve the situation. But that is a problem of the extension site -- not of QA.

    --Bjoern-michaelsen (talk) 2013-04-20T22:44:54 (UTC)

    QA/Meetings/2013/April 19#NEW ITEM: What to do with releases after EOL .28Robinson.2C Joel.29

    The suggestions are not proper. Concerning delisting see here. I am already active with "delisting" old alpha and rc Versions for what no reports have been done for a long time, see Bugzilla administration info on QA mailing list.

    Couple of points:

    1. I'm not sure what you meant re: the conversation between Pedro and Bjoern. Bjoern was at the April 19 meeting and agreed that 6 months after EOL seemed like a reasonable time to de-list the version #'s.
    2. Again, Bus Factor of 1. We don't have a documented process for when to remove these versions. I think we should have a documented process, rather than "when Rainer feels like it." What would you suggest for the rule?

    -- Qubit (talk) 2013-04-20T22:03:58 (UTC)

    What "Tech Support"?

    • Tech support -- as in, when a users asks us to fix a bug related to a version of LO. -- Qubit (talk) 2013-04-20T22:03:58 (UTC)

    The only thing to do for bugs reported for a obsolete Version is to check whether the problem persists in a current Version. Generally it takes only half the time for an experienced tester to to that test compared with discussion and explications for reporter how to do.

    • It's nice for us to have a rule/consistent message about what we're going to do with EOL releases. That's what I was asking about. -- Qubit (talk) 2013-04-20T22:03:58 (UTC)
    • DUP? so mark as DUP
    • Vanished: so mark WFM, also see QA/BSA/BugReport Details#Whiteboard "If a bug in a stable version vanished ..."
    • Still exists: confirm and so on
    • Problems to reproduce? Ask reporter to use a server installation to check whether bug persists in current Version

    -- Rainer Bielefeld 2013-04-20T15:05:50 (UTC)

    Right, that sounds like how we handle all bugs, so I think we're in agreement. My point was that (for example) the 3.5 release is not EOL in Ubuntu. I wanted to make sure that we were all on the same page, presenting the same message about how to handle a user who asks for tech support. I see users like this on the Ask site as well, and wanted to make sure that I had the QA Team behind me when I indicated that they needed to upgrade. That's why I raised it at the meeting :-) -- Qubit (talk) 2013-04-20T22:03:58 (UTC)

    QA/Meetings/2013/April 19#NEW ITEM: What to do about dupes when we can.27t find dupe .23 .28Joel.29

    I agree, we should try something like that, we should try to have a set of 5 .... 10 requests like that like bibisectrequest, dupemerequest, windowstestrequest, linuxtestrequest, ...

    or so, only some suggestions. The terms should be crystal clear so that willing experts can create a RSS feed for requests without being bothered by lots of requests where they can't help. -- Rainer Bielefeld 2013-04-20T15:05:50 (UTC)


    QA/Meetings/2013/April 19#NEW ITEM: How to deal with Unconfirmed bugs that QA team cannot triage .28Joel.29

    I agree, we need more methodical attempts to get those bugs away from UNCONFIRMED, but please do not overengineer that with lots of Whiteboard tags. Simple solutions:

    • We need some more detailed info on the QA team pages concerning skills
    • Simply ask on QA list, you should always quickly find someone who knows someone who can help

    -- Rainer Bielefeld 2013-04-20T15:05:50 (UTC)

    QA/Meetings/2013/April 19#NEW ITEM: OS Specific Whiteboard Status .28Joel.29

    My recommendation: Simply write the OS Version into the summary line like Bug tdf#61944 Impossible to Launch from CLI Fedora 18 / Gnome 3.6. We have similar issues with onlyWORD2003.doc and similar. -- Rainer Bielefeld

    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Talk:QA/Meetings/2013/April_19&oldid=108174"