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

[Bjoern Michaelsen]

Hi Andre, all,

On Sun, 10 Jul 2011 11:57:34 +0200
André Schnabel <andre.schnabel at gmx.net> wrote:

> Am 09.07.2011 19:39, schrieb Kohei Yoshida:
> > Regarding this bug
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=39068
> >
> > Rainer started the specification process for this.
> 
> I'd rather say he started to collect information in a structured way
> to help all the people involved in a new feature implementation. And
> to make more people aware that their help is needed.

Which is a good and important thing because it helps to keep focus and
consistency and lessens the risk of duplicate work. However there are a
few things to keep in mind when writing these:
- Keeping track of related bugs is a very good thing. It might be even
  better to create a meta bug for the spec that is blocked by all the
  subtasks (instead of manually tracking them on a wiki page which
  will be outdated and is errorprone). Bugzilla is a powerful tool, use
  it!
- Bugs should always be selfconsistent work items. A bug should always
  contain all the information needed to fix the issue and not more.
  Esp. it should not even be required to read a spec to understand and
  fix single issue for it.
- It is good to have 'contacts' on the spec. But nobody should show up
  there without being asked first (which I assume happened here), as it
  will imply responsibility and workload.

In general, I think it is not bad to have specifications covering a
wider set of bugs to make sure things develop in a consistent
fashion(*), as long as they do not keep coders from coding.

The tricky scenario is: When a volunteer coder sees a bug, wants to
fix it, but the spec has not been finished yet. In such situations IMHO
we must allow for a well-its-better-than-it-was-before-fix even if there
is no full spec yet. This is simply because the volunteer is willing to
contribute _now_ and not later. He might not be willing to adjust his
fix according to the spec later? True, but if you prevent him to do an
ad-hoc fix now, chances of further contributions from the volunteer are
even less.

Of course, sometimes someones well-its-better-than-it-was-before-fix is
a sucks-worse-in-a-different-way-fix for somebody else. Personally, I
tend to be more conservative in those cases (i.e. keeping the old
behavior) because of the expected technical experience of our target
endusers. But those need to be discussed on a case-by-case basis anyway.

My 2cents.

Best,

Bjoern

(*) Those would also help a lot in the creation of release notes I
guess, which is still a bit frantical right now.
-- 
https://launchpad.net/~bjoern-michaelsen