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

Thu Jan 23 13:35:00 UTC 2014

Because:

  * The change in the wiki was in *contradiction* with what said by a
    Canonical employee in Ask Ubuntu
    <http://askubuntu.com/questions/231230/how-do-i-get-design-input-on-a-paper-cut/231231>.
  * I have *no news* the rule had been there in the past (so I wasn't
    the one who removed it in the first place).

I *wrongly* reverted it, by commenting on it for just in case I was wrong.

So *nothing* to do with arguing. In fact, I *agree* with the rule of 
"only assign bugs to yourself, and only just before starting working on 
them" for any case; *without exception*. In fact, the mentioned case 
here demonstrated to stack bug reports for the One Hundred Papercuts 
project (what is the first waste to be avoided, according to Lean 
Management).

Regards ?

El 22/01/14 16:15, Brendan Donegan escribió:
> 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
>> <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 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 
>>
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140123/baad5a91/attachment.html>