Re: [Libreoffice] Are we back to having this spec process again!?

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 <christoph@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