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

Hi Kohei, *


Am 11.07.2011 15:46, schrieb Kohei Yoshida:
> On Sun, 2011-07-10 at 11:57 +0200, André Schnabel wrote:
> > All that said: if you can suggest some other word for "spec" I'd be
> > quite happy.
> Dennis suggested "design notes".  I normally call it either feature
> documentation, feature description, feature page, or simply just a wiki
> page for feature XYZ.

Ok, among those I'd prefere "design notes".

> To me, the word "specification" implies much more than just a collection
> of information; it implies formality and final, approved decision that
> cannot be changed without paperwork, votes, or whatever is the formal
> way of proposing changes.

Oh - we are on the same side here :) I never ever again want to see a 
bugreport rejected, just because an obvious bug works "as defined in the 
spec and we cannot change the spec".

I want those design notes for mainly two reasons:

- before / during / right after implementation we know that a small team 
did some elaboration how a certain feature should be implemented and 
found consensus on how to implement. The implementation should be based 
on this consensus and not be changed by a single party. (But please: no 
formalism, no big administration .. if there is a team that's all you 
need .. if there is no team, then don't stop working)

- some time after implementation the notes could be used as input for 
further implementation /changes, documentation, testing ... So it's a 
(hopefully helpfull) input for future tasks - nothing that schould 
hinder future work.


> But I think Michael's explanation is pretty
> much in line with how I perceive this term, and why I think it's a
> mis-used term for this purpose.

So please let's not stick to the term :)

I agree to many of Michael's points as well as to Bjoern's. E.g. no 
bugfix (that improves the situation and does not just move from one 
awkward situation to another) should be delayed, just for the "sake of 
having a spec". No one should be put in charge of doing some work 
without being asked beforehand etc.

I'd like to have all this as help for developers. E.g. I don't want to 
write the help texts (there are lot's of people who have much better 
skill in technical writing) - I don't want to do an in-deep analysis of 
competitor's software features - I don't like to elaborate migration 
szenarios. But I want people to make people that many of such things 
need to be done - and my experience from the last few weeks is, that 
hardly anybody outside the dev-list is aware of this :(

regards,

André