Christoph, I feel that you are taking this in a bit too generalized way. I'm talking about the use of a specification for this particular bug report, which I repeatedly said is "overkill". Anyway, my answers are below.
On Sat, Jul 9, 2011 at 4:46 PM, Christoph Noack <christ...@dogmatux.com> wrote: > Hi Kohei, > > you know that I'm both subscribed to this bug, so I feel free to comment > on this - rather from the UX point-of-view (although I know some people > from Documentation, QA, ... who think similar). > > Am Samstag, den 09.07.2011, 13:39 -0400 schrieb Kohei Yoshida: >> Regarding this bug >> >> https://bugs.freedesktop.org/show_bug.cgi?id=39068 >> >> Rainer started the specification process for this. > > I'd like to say that he offered to write a specification - which is a > bit different from a full-fledged "process". Isn't it positive if > somebody (whoever this is) cares about collecting the information if the > complexity of the issue avoids handling all inside a simple bug report? So, here are few things I need to mention. I don't consider this particular bug report to be anywhere near complex. It's a simple bug report where the reporter was expecting to print a sheet with only cell colors on it, but Calc wouldn't print it because Calc consider that sheet to be empty. That's all. But somehow, during the triage, an additional bug was discovered in Calc's auto print range detection, which confused me initially but in the end I sorted it out and summarized it in two bullet points in Comment 11, which I quote here --- So, this is a combination of two separate issues. 1) Sheets with only cell colors are not printed unless the printing of empty sheets is enabled, either in the Calc Print option page or in the printing dialog. 2) Even with the printing of empty sheets is enabled, Calc's automatic range detection fails to detect correct printing ranges. --- And I believe both Rainer and Regina were focusing on point 2), which is different from the original bug description, which was point 1). I was later going to split 2) into another bug report, but anyways... So, the decision we needed to make, as far as the original bug report was concerned, was whether it would make sense to treat a sheet with only cell colors as a non-empty sheet. That's all, at least in my mind. Then, Rainer offered this specification http://wiki.documentfoundation.org/Calc_-_Printing_of_Cells_without_Contents which contains A LOT more information than my bullet point 1). I don't know about you, but I want to keep simple things simple, and I want to keep the amount of information proportional to the level of complexity (or simplicity) of the issue being handled. So, I was a bit surprised to see that much description borne out of this simple bug report. > Especially if nobody urged him to do so - he already invests a lot of > time for LibO. Sure. But if someone writes a specification someone else has to read it to verify it. So, to me, writing a very detailed description for such a simple bug report is anti-productive, for everybody involved (and I happen to be listed as the developer). > As Rainer stated, some of the changes do affect some rather fundamental > definitions within the help - how should the Documentation team know? By asking us, or checking the release notes, where we gather all significant changes between releases. > And the different example documents showed (at least for me) that > separating the issue from the intended behavior is difficult. If we > change that behavior - how should QA know what to test? By asking us, or checking the release notes, or maybe something else we need to come up with for QA. Note that we do also care about improving the QA-ability of new features, so please don't think for a second that we don't care about this. But I do feel strongly that specification is not the answer to this. That's like trying to kill a mosquito with a bazooka. >> I thought one thing we decided to do was not to re-introduce this >> over-engineered, time-wasting specification process. Is this a new >> development in the LibreOffice space? > > I welcome if people announce / describe some of the intended changes > without major changes in the visible functionality. But, I currently > perceive a lot of doubled work outside the development team due to the > lack of information. Sure, and that's surely an area we want to see improved. But the first step to that will be improving our communication on how to solve this. Again, I don't think writing specification is an answer there either. > There are also some examples within Calc where such a lack of > information requires a lot more time for UX and Usability work (although > we lack developers, currently it is Development Power >> UX). However, > bothering the developers for details about the intention, the detailed > behavior or having fundamental discussions in the issue tracker after a > change has been introduced - I think that's tedious for developers as > well. We should avoid that. Are you saying that you guys (UX, doc and QA) should avoid "bothering" us in the issue tracker, or avoid "bothering" us in general? Depending on which one my answer will be different. I put the word 'bother' in quote because I don't believe that's the right verb to use in this context. I would be delighted if one of you ask us about features I developed. I wouldn't consider that a "bother". (Throwing user questions or bug reports at developers are different matters...) Either way, you do need to ask us the developers about what's intended and what's not intended anyway. Otherwise how would you guys ever know that? I don't think there is anything wrong with it. Also, the lack of information is not just an issue for you guys, but to some extent an issue for us as well. Lots of things in this code base are undocumented, and even we have hard time differentiating what behaviors are intended and what aren't. > >> Not to mention I'm very disturbed by this. > > I'm sorry that you feel like this - I'm sure this wasn't intended by > Rainer. But I have to admit that some people (myself included) / teams > feel irritated by lacking information (in advance). Maybe this is a good > starting point to re-think how non-trivial changes are worked on ... > switching from Easy to Serious Hacks :-) Well, we have started gather all changes in the Release Note section of the Wiki, and I consider that as the appropriate medium to communicate the changes between versions. That should be light-weight enough for us that it won't be too much of a burden, and hopefully is a good enough medium for you to gather information about what has been changed. Again, I strongly believe that specifications are overkill. For complex features *maybe*, but for others, definitely not. Another thing I dislike about specification is that how much detail is appropriate is not known beforehand, and the spec writer often ends up over-specifying things when all that's needed was just a simple few sentences. So, I much rather prefer we provide changes in the Release Note, then have you guys ask us where you need more clarification or more details. BTW, I'm a bit traumatized by the word "specification" because that word brings back the bad memory of the old OOo days. So, I'd rather we avoid that term altogether, but I do understand that that's a selfish request & I don't see that happening anyways. And lastly, if you guys feel somehow that you shouldn't ask the developers any questions for your UX, QA or documentation needs, which I consider to be very important, then I believe this project is failing. Anyway, this is all I have to say. Peace, Kohei _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
