Changes to wiki page Bugs/Importance

[Thomas Ward]

Alberto,

I think you've missed some very important things here.  I also think you've
missed the entire "community" idea that we have here.  For bug
documentation it tends to stand without any explanation at all that if you
are going to do major changes to bugs or the definition of a term related
to bugs you should open a discussion on the changes first, especially if it
will break the relationship of documentation pages in relation to other
pages or cause a disruption in helping new triagers get acquainted with
everything.

I've made comments below here on your message.  Please read them and
respond.  I also ask you questions at the very end.  So please read them.

On Fri, Dec 6, 2013 at 2:05 PM, Alberto Salvia Novella <
es20490446e at gmail.com> wrote:
> Why I changed pages without asking
> - Because I guess letting people make changes and discussing only those on
> which we don't agree makes further progress, further than speaking
> everything before hand. And if there's no consensus letting other's
opinion
> to prevail.

By making *major substantial changes to the documentation* you have broken
multiple links in the wiki.  You have broken the consistency of other pages
as well.  Not to mention the quick-links I have to the documentation, the
first question I had shortly after you revised the pages was "Where did the
documentation go?" and to me as a bug triager who regularly refers to the
documentation, that raised a very large red flag.

>
>
> When I'm reverting the page to the version previous to my editions
> - When some members of Ubuntu Quality formally disagree with the previous
> methodology, and I'll understand and respect the decision.

Jean-Baptiste is a member of the Ubuntu Quality team.  They're also a
member of the Bug Control team.

I am a member of the Ubuntu Quality team.  I'm also a member of Bug Control.

I have the same concerns as Jean-Baptiste, and I'm sure that other, more
senior members, of the Quality team and the Bugs team(s) have some issues
with major changes that are not announced or discussed.

>
>
> Why I renamed the page from "bugs" to "bug importance"
> - For the title page to be semantic complete itself; what its not
important
> for developers but to the average user. If this was accepted, I had planed
> to do the same to the rest of pages for consistency.

*Why?  The URL shows "Bugs/Bug Importance" rather than "Bugs/Importance".  *The
previous URL was sufficient to identify that the importance is related
directly to Bugs as it falls in the Bugs/ section of the wiki.

>
> Why I haven't redirected the previous page title to the new one
> - Because keeping the number of pages to the minimum to make browsing for
> pages of the same category simpler, because I've corrected links in all
the
> pages I've found, and because it's already easy to find the new page in
the
> suggestions for these minimum cases where the link is broken.

*By not redirecting the old page to the new one, you've broken several
things which I have written on Ask Ubuntu, as well as my "fast click links"
to take me to the documentation myself and others rely on.*  I have two
"gold standard" questions regarding Bug Triage, Importance, and Status, and
they all link to each other and to the wiki documentation.  As well, by not
redirecting the old page to the new one you are potentially going to be
breaking other documentation outside of the Bug wiki pages which relate to
Importance.

>
>
> Why I have deleted the header
> - Because it's expected that nearly every user that enters the page to be
> looking to not something more than bug importance itself. Perhaps there
can
> be a header for making easier to navigate between documentation, but the
> header we had here looked rather like a warning; so it is expected it to
> distract the user rather than making navigation to look simpler, specially
> being in the top of the page.

The header should remain.  As Jean-Baptiste states, *it links the
documentation for triaging together*, showing that it is related to the
Triage procedures and provides quick-access to switch around in the
documentation.

>
>
> Why I removed the introduction
> - Because what is bug importance is self-explanatory, specially being
> expected that the user will come to this page from one that speaks about
> what bug triaging is.

You make several assumptions here.  You make the assumption that *new bug
triagers* on Bug Squad (and in future, QA's Bug Triage role) *are going to
understand the bug permissions system.* By removing the introduction you
are forcing users to read the triage guide which explains the permissions.
 But at-a-glance having the Introduction there is worthwhile.

I strongly support *readding the introduction* for this reason.

>
>
> Why I putted how to set bug importance at the bottom of the page
> - Because this is information you read one time, over bug importance sets
> being read many times. And it's already easy to notice this information is
> there.

*You make the assumption people will read to the bottom.*  This assumption
is not an ideal assumption to make, as a lot of times people will want an
at-a-glance easy-to-find section that they dont' have to scroll the entire
page for in order to find how to get information on how to set bug
importance.  Bug controllers and people who have been triaging for a while
either as Bug Squad or the new Bug Triager roles in QA would know this, but
new volunteer triagers won't necessarily know this.  *I strongly recommend
moving this section about how to set importance back to the beginning.*

>
>
> Questions
> - Would I have been able to edit the page if I had to explain these
points,
> and the rest of them, before the edition; or I had simply chosen not to
try
> so?

After discussion about the *major substantial changes to Bugs documentation* I
think the answer would be "yes".  Major changes like these are typically
discussed, before you just go ahead with the changes.

> - Is this the same to the rest of people?

I think this would apply to everyone.

> - How much time do you thing a message like this will someone take to
write?

Ask yourself this: How long would it take for me to describe the changes I
am making to the documentation?  Would the extra delay in the time it takes
to have this discussion actually be that much of a problem?

> And to answer? How do you see this for every choose (or not choose)?

You can answer this yourself by asking yourself "How long did this response
to Jean-Baptiste's message take to write?"

> - What is more important for you: things to be simple, or things to be
> correct?

Was the previous documentation *incorrect*?  No, it wasn't.

The previous page and documentation was both *correct* and *simple*, from
my point of view. Discussing simplifying it further would have been good to
discuss anyways, however just going ahead and making changes makes that
difficult, as you would not get the opinions of others on QA or bug
control, or other people on QA who might be interesting in starting to work
on triage, and would have opinions on simplifying things.

> - What is the advantage of Ubuntu as operating systems over the rest for
> users?
> - And for its management, is it the same?

I'm not sure either of these questions are relevant to the handling of
major changes to the bug triage documentation.

>
>
> Just ideas 🐂
>
>
> El 06/12/13 08:00, Jean-Baptiste Lallement escribió:

><snip>


------
Thomas
LP: teward
irc: TheLordOfTime or teward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20131206/341958af/attachment-0001.html>