<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <div class="quote">On Jan 23, 2014 7:13 AM, ubuntu-quality-request@lists.ubuntu.com wrote: </div> <div class="BodyFragment"> <div class="PlainText">Send Ubuntu-quality mailing list submissions to ubuntu-quality@lists.ubuntu.com To subscribe or unsubscribe via the World Wide Web, visit <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality">https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality</a> or, via email, send a message with subject or body 'help' to ubuntu-quality-request@lists.ubuntu.com You can reach the person managing the list at ubuntu-quality-owner@lists.ubuntu.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Ubuntu-quality digest..." Today's Topics: 1. Re: Freshman to mail list (Peng An) 2. Some points on the Wiki for Bug(squad|control) (C de-Avillez) 3. Re: Some points on the Wiki for Bug(squad|control) (Brendan Donegan) 4. Fwd: [Ubuntu-phone] Core app hack days are coming back! (Nicholas Skaggs) ---------------------------------------------------------------------- Message: 1 Date: Wed, 22 Jan 2014 21:35:39 +0800 From: Peng An <wenpengan@gmail.com> To: Jackson Doak <noskcaj@ubuntu.com> Cc: "ubuntu-quality@lists.ubuntu.com" <ubuntu-quality@lists.ubuntu.com> Subject: Re: Freshman to mail list Message-ID: <CAJ6_He1QKubaZAB=Z=uxDWn_xOkHOG2yHvdUVBOh3sYGFxqA5A@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi Jackson, Sorry for later, I have just COB now. I have not used the irc before, I am reading the manu.. 2014/1/22 Jackson Doak <noskcaj@ubuntu.com> > Welcome Alex, > Is there anything in particular you'd like to do in the QA team? > <a href="https://wiki.ubuntu.com/QATeam/Roles">https://wiki.ubuntu.com/QATeam/Roles</a> has a decent overview of what we do. > If you know python, both testdrive and autopilot have a lot of stuff in > progress. > > If you have any questions about this, ask. Most of us are also on irc, if > you want to contact us that way. > > > On Wed, Jan 22, 2014 at 5:16 PM, Peng An <wenpengan@gmail.com> wrote: > >> Hi, >> >> Glad to meet you. >> >> First, let me introduce myself. >> 1, I have worked at a Server Vendor 5+ years. >> 2, I have 5+ years QA experience, about HW/BMC/Windows/Linux/BIOS. >> 3, I have 3+ years Test plan/Case writing, and familiar with Test Drive. >> 4, I have coworked with Dell, HP, Lenovo and Google for many years >> 5, I have used Ubuntu for more 3 years. >> >> And now, I want to contribute to Open Source, so I want to join the QA >> team. >> If you have any questions and suggestions, please donot hesitate to >> contact me. >> >> Alex, >> >> >> >> -- >> Ubuntu-quality mailing list >> Ubuntu-quality@lists.ubuntu.com >> Modify settings or unsubscribe at: >> <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality">https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality</a> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <<a href="https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140122/651f7741/attachment-0001.html">https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140122/651f7741/attachment-0001.html</a>> ------------------------------ Message: 2 Date: Wed, 22 Jan 2014 08:51:04 -0600 From: C de-Avillez <hggdh2@ubuntu.com> To: <ubuntu-quality@lists.ubuntu.com>, <ubuntu-bugsquad@lists.ubuntu.com> Subject: Some points on the Wiki for Bug(squad|control) Message-ID: <20140122085104.57ce8400@icatu> Content-Type: text/plain; charset="us-ascii" Hello folks TL;DR -- do not assign bugs to other people. I noticed, a few days ago, some edits on the Bugs/* namespace. In general, good work, and a good consolidation on the multiple (and almost, but not completely identical) pages. There was, though, a edit that I do not agree with. So, to start, let's posit two principles (and I am talking about triaging here): * 1. The documentation about how to deal with bugs in Ubuntu is contained (or pointed to from) in the Wiki, under the Bugs namespace; * 2. NOWHERE else is a good place. Simple principles. The whole idea, after all, is to allow anyone, either starting to help or trying to remember things, a *single* place to go to find information. So, back to the issue at hand. This edit dealt with Bug status and, on reading it, I noticed that a restriction we had in place for quite a long time was not there anymore. This restriction goes as follows: "in general, NEVER assign a bug to somebody else." So I edited the page, and added it back [1]. I was surprised to find, later, a re-edit of the page with this restriction taken out again [2], with a a comment "As seen it <tinyurl.com/pm76zuw>, this is not true in all cases." That is not the issue. The issue is one should NOT assign bugs to other people. There are some reasons for this: * I see no problem with assigning bugs to teams (or projects): teams (and projects) usually survive changes. People join, and leave, teams and projects -- their interests changes --, but the teams (and projects) tend to stay. * this has been heavily abused in the past; we were all tired of finding ourselves with a new bug assigned to us *even* when it was not our area/interest/responsibility. * in the same vein, I do not need other people to decide what I have to do *without* contacting me first to see if I agree. This is really, really, bad manners. The restriction was there for a reason. It should be back there (but I am not going to re-edit the page, and start a silly "you are wrong; no YOU are wrong" wiki edit battle). And on the comment ("As seen it <tinyurl.com/pm76zuw>, this is not true in all cases."): It does not matter. We may see a series of rules on How To Assign A Bug To Other People in thousands of pages in the web. But, for triaging, the ONLY VALID PLACE is under the Bugs/* namespace, at <a href="https://wiki.ubuntu.com">https://wiki.ubuntu.com</a>. This also show WHY having a single point for triaging (and, in general, for documentation) is a better option. I , personally, cannot understand why would anyone have thought to go to askubuntu.com to ask how to triage a bug. And, worse, why would anyone answer there giving a *different* process, and NOT update the wiki? And this brings another point: these pages provide GENERAL guidance. I certainly do not want to see them grow without limit so that evey single minuscule aspect of triaging can be documented. But I can accept redirection to more specific pages (as long as we do not grow *these* pages without bounds). This is it. It is partially a rant, partially a -- for me -- reasonable request. Cheers, ..C.. [1] <a href="https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004438.html">https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004438.html</a> [2] <a href="https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004436.html">https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004436.html</a> -- ab alio expectes alteri quod feceris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <<a href="https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140122/7d203719/attachment-0001.pgp">https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140122/7d203719/attachment-0001.pgp</a>> ------------------------------ Message: 3 Date: Wed, 22 Jan 2014 15:15:54 +0000 From: Brendan Donegan <brendan.donegan@canonical.com> To: ubuntu-quality@lists.ubuntu.com Subject: Re: Some points on the Wiki for Bug(squad|control) Message-ID: <52DFE0AA.8020309@canonical.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 22/01/14 14:51, C de-Avillez wrote: > > Hello folks > > TL;DR -- do not assign bugs to other people.n Looks like a poor interpretation of the wiki. If we say 'in *general* NEVER assign a but to somebody else' that actually means that there may be specific cases where it can be done, such as the entry on askubuntu <a href="http://askubuntu.com/questions/231230/how-do-i-get-design-input-on-a-paper-cut/231231#231231">http://askubuntu.com/questions/231230/how-do-i-get-design-input-on-a-paper-cut/231231#231231</a> which discusses a *very* specific case where assigning to a user is allowed - which should be interpreted as 'in this specific case, the user 'Nick Tait' gives you his implicit permission to assign papercut bugs to him' - not 'oh hey, in general you can just assign bugs to whoever you want'. Anyway having a process where a bug is assigned to a named user is dubious so that should be changed. > > I noticed, a few days ago, some edits on the Bugs/* namespace. In > general, good work, and a good consolidation on the multiple (and > almost, but not completely identical) pages. > > There was, though, a edit that I do not agree with. So, to start, let's > posit two principles (and I am talking about triaging here): > > * 1. The documentation about how to deal with bugs in Ubuntu is > contained (or pointed to from) in the Wiki, under the Bugs namespace; > * 2. NOWHERE else is a good place. > > Simple principles. The whole idea, after all, is to allow anyone, > either starting to help or trying to remember things, a *single* place > to go to find information. > > So, back to the issue at hand. This edit dealt with Bug > status and, on reading it, I noticed that a restriction we had in > place for quite a long time was not there anymore. > > This restriction goes as follows: "in general, NEVER assign a bug to > somebody else." > > So I edited the page, and added it back [1]. > > I was surprised to find, later, a re-edit of the page with this > restriction taken out again [2], with a a comment "As seen it > <tinyurl.com/pm76zuw>, this is not true in all cases." > > That is not the issue. The issue is one should NOT assign bugs to other > people. There are some reasons for this: > * I see no problem with assigning bugs to teams (or projects): teams > (and projects) usually survive changes. People join, and leave, > teams and projects -- their interests changes --, but the teams (and > projects) tend to stay. > * this has been heavily abused in the past; we were all tired of > finding ourselves with a new bug assigned to us *even* when it was > not our area/interest/responsibility. > * in the same vein, I do not need other people to decide what I have > to do *without* contacting me first to see if I agree. This is > really, really, bad manners. > > The restriction was there for a reason. It should be back there (but I > am not going to re-edit the page, and start a silly "you are wrong; no > YOU are wrong" wiki edit battle). > > And on the comment ("As seen it <tinyurl.com/pm76zuw>, this is not true > in all cases."): It does not matter. We may see a series of rules on How > To Assign A Bug To Other People in thousands of pages in the web. > But, for triaging, the ONLY VALID PLACE is under the Bugs/* namespace, > at <a href="https://wiki.ubuntu.com">https://wiki.ubuntu.com</a>. > > This also show WHY having a single point for triaging (and, in general, > for documentation) is a better option. I , personally, cannot understand > why would anyone have thought to go to askubuntu.com to ask how to > triage a bug. And, worse, why would anyone answer there giving a > *different* process, and NOT update the wiki? > > And this brings another point: these pages provide GENERAL guidance. I > certainly do not want to see them grow without limit so that evey > single minuscule aspect of triaging can be documented. But I can > accept redirection to more specific pages (as long as we do not grow > *these* pages without bounds). > > This is it. It is partially a rant, partially a -- for me -- reasonable > request. > > Cheers, > > ..C.. > > > [1] > <a href="https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004438.html"> https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004438.html</a> > [2] > <a href="https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004436.html"> https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004436.html</a> > > > ------------------------------ Message: 4 Date: Wed, 22 Jan 2014 15:12:32 -0500 From: Nicholas Skaggs <nicholas.skaggs@canonical.com> To: "ubuntu-quality@lists.ubuntu.com" <ubuntu-quality@lists.ubuntu.com> Subject: Fwd: [Ubuntu-phone] Core app hack days are coming back! Message-ID: <52E02630.4070304@canonical.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" I'll be around during these hack days as well. If you want to help contribute some autopilot tests or hack on the existing tests for these apps, plan to attend :-) Nicholas -------- Original Message -------- Subject: [Ubuntu-phone] Core app hack days are coming back! Date: Wed, 22 Jan 2014 19:36:26 +0100 From: David Planella <david.planella@ubuntu.com> To: ubuntu-touch-coreapps <ubuntu-touch-coreapps@lists.launchpad.net> CC: ubuntu-phone <ubuntu-phone@lists.launchpad.net> Hi all, Given the success of the previous Core Apps Hack Days last cycle, we've decided to bring them back! Tomorrow we will publish a detailed announcement, but I thought I'd give an initial heads up to all teams not to catch anyone off-guard. The tentative schedule is to focus to 2 apps per hack day, as follows: Friday 24th January: * Reminders * Music Monday, 3rd February * Calendar * Shorts Tuesday, 4th February * Clock * Calculator Wednesday, 5th February * File Manager * Doc Viewer Thursday, 6th February * Weather * Terminal If you're a core app developer and want to help with the preparation, things that might be useful to lower the barrier of contribution could be: - Triage bugs in your project, assigning them the priorities you judge appropriate - Add tags to group bugs that you can point new contributors too (e.g. 'bitesize', 'ui', etc.) - ... You're all very talented and creative developers, so I'm sure you have your own ideas to bring to the mix too :) Looking forward to seeing the contributions during the Hack Days! Cheers, David. -------------- next part -------------- An HTML attachment was scrubbed... URL: <<a href="https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140122/8240904b/attachment.html">https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140122/8240904b/attachment.html</a>> -------------- next part -------------- -- Mailing list: <a href="https://launchpad.net/~ubuntu-phone">https://launchpad.net/~ubuntu-phone</a> Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : <a href="https://launchpad.net/~ubuntu-phone">https://launchpad.net/~ubuntu-phone</a> More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a> ------------------------------ -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality"> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality</a> End of Ubuntu-quality Digest, Vol 75, Issue 22 ********************************************** </div> </div> </body> </html>