Introductory

2014-01-22 Thread Luca Biolcati 
Dear Friends,

I've been using Ubuntu since 2008, when I used to use 'Intrepid Ibex'
version 8.10. I think that the Ubuntu Community is a great invention.
Everyone can share free software! It's the demonstration that when people
work together the results are great!! I'm studying PHP, C, Java languages!! I
would like to contribute to the community, even if it will be very small
one. I hope to learn something from this new experience. I think that in
life you never finish to learn!!

Filiberto
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Help

2014-01-22 Thread Leonardo Liao 
On Jan 23, 2014 7:13 AM, ubuntu-quality-requ...@lists.ubuntu.com wrote:
Send Ubuntu-quality mailing list submissions to
ubuntu-quality@lists.ubuntu.com

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
or, via email, send a message with subject or body 'help' to
ubuntu-quality-requ...@lists.ubuntu.com

You can reach the person managing the list at
ubuntu-quality-ow...@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 
To: Jackson Doak 
Cc: "ubuntu-quality@lists.ubuntu.com"

Subject: Re: Freshman to mail list
Message-ID:

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 

> Welcome Alex,
> Is there anything in particular you'd like to do in the QA team?
> https://wiki.ubuntu.com/QATeam/Roles 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  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:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
>>
>>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140122/651f7741/attachment-0001.html>

--

Message: 2
Date: Wed, 22 Jan 2014 08:51:04 -0600
From: C de-Avillez 
To: ,

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
, 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 peo

Re: Fwd: [Ubuntu-phone] Core app hack days are coming back!

2014-01-22 Thread Nicholas Skaggs 

On 01/22/2014 03:16 PM, Carla Sella wrote:

On 22/01/2014 21:12, Nicholas Skaggs wrote:
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




At what time will they be ?
What if someone cannot attend ? will there be something that one can 
look or read afterwards ?
I'll await details from David, but last time they lasted throughout the 
European day into the evening a bit. If you can't attend but still want 
to help and need help getting started, ping myself or the list and we're 
always happy to help :-)


However, in general the development teams and everyone tries to be 
available at the specified day and time to the extent possible. It was a 
lot of fun last time. Being able to chat directly with the developers is 
wonderful.


So as to your ability to attend, I can't answer specifically yet Carla :-|

Nicholas
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Fwd: [Ubuntu-phone] Core app hack days are coming back!

2014-01-22 Thread Carla Sella 

On 22/01/2014 21:12, Nicholas Skaggs wrote:
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




At what time will they be ?
What if someone cannot attend ? will there be something that one can 
look or read afterwards ?



--
Carla Sella
email: carla.se...@gmail.com
https://launchpad.net/~carla-sella
http://qa.ubuntu.com/

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Freshman to mail list

2014-01-22 Thread Nicholas Skaggs 
Welcome! As Jackson mentioned, review the roles page and decide which 
avenue(s) you want to pursue. We're all happy to help you with any 
specific questions. Sounds like you've got some rather nice experience 
you can bring to the table. Looking forward to working with you!


Nicholas

On 01/22/2014 01:16 AM, Peng An 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: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Fwd: [Ubuntu-phone] Core app hack days are coming back!

2014-01-22 Thread Nicholas Skaggs 
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 
To: ubuntu-touch-coreapps 
CC: ubuntu-phone 



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.


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-ph...@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Some points on the Wiki for Bug(squad|control)

2014-01-22 Thread Brendan Donegan 

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 
http://askubuntu.com/questions/231230/how-do-i-get-design-input-on-a-paper-cut/231231#231231 
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
, 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 , 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 https://wiki.ubuntu.com.

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]
https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004438.html
[2]
https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004436.html






--
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Some points on the Wiki for Bug(squad|control)

2014-01-22 Thread C de-Avillez 

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
, 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 , 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 https://wiki.ubuntu.com.

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]
https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004438.html
[2]
https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004436.html

-- 
ab alio expectes alteri quod feceris


signature.asc
Description: PGP signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Freshman to mail list

2014-01-22 Thread Peng An 
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 

> Welcome Alex,
> Is there anything in particular you'd like to do in the QA team?
> https://wiki.ubuntu.com/QATeam/Roles 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  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:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
>>
>>
>
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Freshman to mail list

2014-01-22 Thread Alberto Salvia Novella 

Oh, here we are for you.

Have a nice day ?


El 22/01/14 07:25, Jackson Doak escribió:

Welcome Alex,
Is there anything in particular you'd like to do in the QA team? 
https://wiki.ubuntu.com/QATeam/Roles 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 > 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:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality






-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality