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 < [email protected]> 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
-- Ubuntu-quality mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
