We have discussed how to get more people involved on the QA team meeting. One idea was to ask for help after user report a bug using the bugzilla assistant. It could show a page with some text like: --- cut --- Thank you for reporting problem in LibreOffice Let's make the next release better together. Nobody is perfect and there are some more problems reported. You could help us a lot with sorting them[1]. We are already working on the next release. You might want to check you preferred functionality or some new feature[2] before the final release is out. If you are in doubts. Do not hesitate to contact us on libreoffice-qa@lists.freedesktop.org --- cut --- Where [1] links to http://wiki.documentfoundation.org/BugTriage and [2] to http://wiki.documentfoundation.org/QA/Testing/Feature_Tests I am sure that anyone withe better marketing skills might come up with better text. Anyway, we could improve it later at any time.
Rob, any chance that you add such page, please?
The text needs to be tweaked before it is published. It would be better if it read more like this with very little change in the words that you used (below): ======================= Thank you for reporting a problem with LibreOffice. Nobody is perfect and more bugs have been reported. Let's make the next release better together. You could help us a lot with sorting them[1]. We are already working on the next release. You might want to check your preferred functionality or some new feature[2] before the final release is out. Should you have any questions, do not hesitate to contact us on our QA mailing list -- libreoffice-qa@lists.freedesktop.org ======================= You could perhaps get some better text if you described what you wanted to achieve with the text. It looks like these new bug-reporters are being asked to help out with sorting bug submissions, OR, to "test-try" a pre-release and report back on bugs that they may find. If this is the case, then you could perhaps re-write it like this below: ======================= Thank you for reporting a problem with LibreOffice. Your help is very appreciated. Nobody is perfect and more bugs have been reported. Join us in making this release even better. You could help with sorting bugs[1]. OR We are already working on the next LibreOffice release. You might want to check your preferred functionality or some new feature before the final release is out[2]. You could help us by submitting any other bugs that you may encounter with the pre-release. Should you have any questions, do not hesitate to contact us on the QA mailing list at libreoffice-qa@lists.freedesktop.org (or at our QA email address info-qa@libreoffice.org). ======================= NOTE: That I feel that we should provide an email address to a REAL QA member, just in case the the new bug-submitter is interested but does not want to join a mailinglist. We would just have to make sure to put a working QA email address there ... I just made that one up. If we can partner up new bug-submitters who are interested in QA with a QA member, then we could mentor them into being good at triage or good at submitting bugs etc. Maybe someone else may want to "massage" the text even more? Note that if you are not in a hurry for this, that you could post it on the "Marketing list" where we (I am a marketing team member) like to do this kind of "text" massaging. Cheers, Marc
> > We have discussed how to get more people involved on the QA team meeting. > One > idea was to ask for help after user report a bug using the bugzilla > assistant. > It could show a page with some text like: > > > --- cut --- > Thank you for reporting problem in LibreOffice > > Let's make the next release better together. > > Nobody is perfect and there are some more problems reported. > You could help us a lot with sorting them[1]. > > We are already working on the next release. > You might want to check you preferred functionality or > some new feature[2] before the final release is out. > > If you are in doubts. Do not hesitate to contact us on > libreoffice-qa@lists.freedesktop.org > > --- cut --- > > Where [1] links to http://wiki.documentfoundation.org/BugTriage > and [2] to http://wiki.documentfoundation.org/QA/Testing/Feature_Tests > > I am sure that anyone withe better marketing skills might come up with > better > text. Anyway, we could improve it later at any time. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > > -- > Unsubscribe instructions: E-mail to website+help@global.libreoffice.org > Problems? > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > List archive: http://listarchives.libreoffice.org/global/website/ > All messages sent to this list will be publicly archived and cannot be > deleted > I say we should just get something up as soon as possible, personally I like Nobody is perfect and there are some more problems reported. You could help us a lot with sorting them[1]. Then we can edit it easily going forward. I also agree that having direct contact with a QA member would be good for those not wanting to join a mailing list, lastly I would say get our IRC channel on there also. I am willing to be the "go to" for an email if someone is interested in getting involved.
Thanks for hints. I like the Marc's proposal: --- cut --- Thank you for reporting a problem with LibreOffice. Your help is very appreciated. Nobody is perfect and more bugs have been reported. Join us in making this release even better. You could help with sorting bugs[1]. --- cut --- The intention of the message is to get more volunteers for the QA work. If anyone is active enough to report a bug, she might want to do a bit more. The primary task is to get volunteers for the so-called "Bug Triage" see http://wiki.documentfoundation.org/BugTriage. This process helps to prepare bugs for Developers. It can be done also by non-developers. It is about:
Grr, I pressed the "Submit" button too fast without intention :-) So, the bug triage process is primary about: * make sure that the bug is reproducible and clear * search for duplicates * prioritize bug (reasonable severity, priority, people in CC, MABs) * add more useful information (backtrace, bibisect, test documents, screenshots) In the original text, I wanted to invite people also for other QA task (pre-release testing). Well, we might try to make the text simple and ask only for the bug triage in the beginning. We might add more hints if it gets successful. Last thing. I suggest to use the mailing list address. I think that people could send mails to the mailing list even if they are not subscribed. The important thing is that anyone approves the mail and anyone else provide some answer within one or two days. I am afraid that a single person might get overloaded quite fast. Also there is a risk of vacations and other outages. Of course, personal mail is a lower barrier. On the other hand, bug triagger should has somehow strong personality anyway. It is not easy to deal with the many bugs ;-)
Hi All, I have been following this. And putting a fixed text on the screen should be easy. But it should be discussed first what needs to be put there. I think the original text was good. IRC isn't a channel most people use so I don't think that is needed for this text.
True about IRC but I think that if you're getting involved, it's a good thing to keep in mind as a lot of activity is there. As for the text, I'm for just starting something simple and then modifying as necessary. Bjoern's wording seemed fine for the time being, after it gets up we'll discuss changes during our QA call. I am marking this as NEW as it's something that is confirmed and we want to do :)
Another option for IRC is to have it be a link to webchat.freenode.net, not sure if you can autofill the room name with #libreoffice-qa...this way it's as easy as pushing connect to join the room
I suggest to get more people on the IRC channel before we point new volunteers there. I see there only 4 persons now: kendy, mmeeks, pmladek, and Sweetshark. When I speak for myself, I read IRC only when someone mentions my name and the irc client icon starts blinking in the systray. Sometimes I am concentrated too much and miss even the blinking. Then I react with a big delay (hour(s)) when I see the red colored channel name during a "regular" check. I can't speak for others but they are on many channels, so they can't follow all comments. I guess that they are using a similar strategy.
Fair enough, so can we agree to get text that reads: "Thank you for reporting a problem with LibreOffice. Nobody is perfect and more bugs have been reported. Let's make the next release better together. You could help us a lot by verifying them[1]." Then have a link to a really really simple wiki (I'll create this, the one we discussed during QA call). Three simple points that basically says what to do.
For what it is worth here is a modification that was worked on by some of the marketing team members. We avoided as much as possible "contractions", "possessives" and "EN colloquialisms", some of the sentences that sounded too apologetic were removed as well as unecessary text. Also be aware that the LibreOffice forums will most likely come online very early in the new year and it would be possible to send the users to a possible QA section on the forums, which has a lower entrance barrier and has a shorter learning curve. The text could then be modified to send the user to the forums rather than the mailing lists. ===== NEW TEXT ===== Thank you very much for your e-mail and interest in LibreOffice. Due to the increasing popularity of the free office suite, we receive a lot of support requests every day. Unfortunately, we cannot reply personally to every e-mail, as our engagement in the project is completely voluntary and restricted to our spare time. However, the Community does offer a large variety of mailing lists to support its users. We have compiled an overview at http://www.libreoffice.org/get-help/mailing-lists/ Please have a look at these pages, and send your inquiry to the applicable mailing list. A member of our mailing list will then respond and try to address the details of your inquiry. ===== NEW TEXT ===== ===== ORIGINAL TEXT ===== Thank you very much for your e-mail and your interest in LibreOffice. Due to the increasing popularity of the free office suite, we receive lots of support requests day by day. Unfortunately, we can't reply personally to every e-mail, as our engagement in the project is completely on a volunteer basis and in our spare time. This often demands several hours of volunteer engagement per day, leaving no time to respond to individual requests. However, the Community does offer a large variety of mailing lists to support its users. We have compiled an overview at http://www.libreoffice.org/get-help/mailing-lists/ Please have a look at these pages, and send your inquiry to our mailing lists. Chances are high that your problem then will be solved very soon. ===== ORIGINAL =====
I don't particularly like sending them to a mailing list page, many people hate mailing list and don't know how to organize them correctly. I would much prefer asking them directly to get involved with triaging as it's the easiest way to start getting involved and our back log is so large that I think it doesn't look good to the community when it takes nearly 2 months to touch a bug
here is a link that we'd like to point reporters to: http://wiki.documentfoundation.org/Triage_For_Beginners#Triaging_in_4_Steps Incredibly basic instructions just to get people involved, more likely than not if they take that step, they'll participate more (or at least that's the hope)
Marc, I am afraid that you misunderstood the request. We can't track bugs in the mailing list because it would be a nightmare. We need to track bugs in bugzilla. We want to ask users to triage (sort, approve) the existing bugs. The text will be displayed the users her own bug using a wizard. Joel, I am afraid that the steps are too easy. I miss some important things: 1. Make sure that the bug has clear steps how to reproduce it. It does not help if an user spend one hour on reproducing and then just move the bug to the step NEW. 2. Prioritization. What would happen if the bug is really annoing and nobody escalate it via the MABs, CC-ing developers or severity flag. We need to expect some results after the bug is moved in the state NEW. Otherwise, the work could create even bigger mess. I am sorry, I am quite busy because of some deadlines. I can't think about a better text today.
(In reply to comment #14) The idea is not to track bugs in the mailing list, which would not be the right way, I agree that the bugzilla is the only tool to track bugs. It sounds more like there should be mentor oversight; the user would be sent off to a Joel's beginner page, but, along with the possibility of mentorship to help the user gain triaging skills with help from an experienced QA member. As an idea, maybe we should look more at establishing a QA mentorship group who would be tasked with training new QA arrivals. They could then help/train new QA members until their skills were adequate to do triaging by themselves. With a good beginner's page and coupled with mentorship, it doesn't have to be a long process for the mentors. This would make for a more effective triaging group. Once new QA triaging team members prove their competency, they could then take up some of the mentorship and leave the more experienced QA members to do other work. Cheers, Marc
I updated the page, what I didn't want to do is have an explanation for how to do most annoying bugs (block, enter code, leave a comment over on MAB explaining why). So instead what I put is another point that says; "If the bug seems particularly annoying -- such as a crash or some other bug that results in loss of data or the inability to produce professional quality work -- please email all of the QA Experts which can be found here (link) with the subject being FDO#"bug number" I agree that it should be a mentor program, unfortunately I'm not positive that's realistic as our QA team really is 5 or so consistent people all of whom probably have 3 people worth of work on their plates already. But, I'll add to agenda for next QA call. Petr any ideas about that?
I would use something like the following text at http://wiki.documentfoundation.org/Triage_For_Beginners: 1. Find[1] a bug that you want to try to reproduce 2. check if it is reproducible; leave a comment, set status NEW or NEEDINFO[2] 3. check if component, severity and priority looks reasonable[3] 4. escalate major, critical, and blocker bugs[4] 5. optional: add more useful information[5] If you are in doubts, please contact us on libreoffice-qa@lists.freedesktop.org The links [1][2][3][4][5] should point to a more detailed information: [1] how to find non-triagged bugs [2] hints what to do if it is reproducible, what to do does not work, what to do it is works [3] hints what means reasonable component, ... well, this is not clear even for experienced triaggers but it should be important part [4] hints how to escalate bugs (developers in CC, Whiteboard flags, MABs) [5] hints how to add more useful information (more Whiteboard flags, check if it is a regression, add backtrace, do bibisect, add test document, screenshot, easier steps to reproduce) My approach is that we should teach people how to do it correctly from the beginning. Of course, we must not scare them by complex intro page but we should provide handy links to details. I prefer to link particular sections than just link the whole scary page on the end. The text on the intro page need to describe the basic idea, so people could do the job intuitively even without reading details. Finally, I still suggest to point people to the mailing list. IMHO, http://wiki.documentfoundation.org/QA/QA_Team is not a good idea because the page is not up-to-date, some people might not react well. I think that some shared place would work better. We need to create a living and friendly place from the QA mailing list anyway. We could add more shared channels if we have them later. If you do not mind, I could update the wiki.
I have submitted a patch to the git to enable this. It will be on the next update of the BSA. I have used: Thank you for reporting a problem with LibreOffice. Your help is very appreciated. Nobody is perfect and more bugs have been reported. Join us in making this release even better. You could help with sorting bugs[1]. I have pointed to http://wiki.documentfoundation.org/Triage_For_Beginners.
*** Bug 47663 has been marked as a duplicate of this bug. ***
Petr: Yeah I have no problems with you updating the wiki :) I'm interested to see what you have in mind as I think I'm mis-reading your response (are you going to create 5 new wiki's, where each [1][2]...etc....is linked to to describe that step? I do agree that we should teach how to triage correctly to begin with, anything that makes that easy to do is a plus. Thanks for editing the page @Rob: Thanks for the update to BSA, we'll get the wiki updated hopefully in the next couple days.
I have updated http://wiki.documentfoundation.org/Triage_For_Beginners and some other pages that it is linked to. In the end it is a mix of Joel's and mine ideas. I changed my mind and kept the 4 steps easy. I did not ask for updating severity, priority, whiteboard and other stuff there. Though, I mentioned it in the section that advertize the full triage page :-) I also removed some details and the too strong "IF AND ONLY IF" to make it better readable and more encouraging. I hope that new people will do their best and do reasonable things. We need to teach them anyway. Feel free to update it as you like. I might have missed some point, ...
Looks great to me, thanks again Petr