Specifications for Enhancement Requests

[Rainer Bielefeld <ra...@bielefeldundbuss.de>]

Hi all,

today I read "[Issue 124455] introducing a attribute for spacing between 
paragraphs with the same paragraph style" 
<https://issues.apache.org/ooo/show_bug.cgi?id=124455>. I think it's an 
Idea what is worth to think over, but it is one of those where several 
relations and possible obstacles have to be considered before a decision 
can be done whether we want to invest developer time for implementation.

I think for complex requests we should create something like a short 
specification where we collect all facts and thoughts, try to reach 
common sense how we should proceed.

<https://wiki.openoffice.org/wiki/Specification_template> seems a little 
oversized, too complex and so rather deterring. Does anybody know a more 
simple Template, more or less similar to a check-list for the essentials 
like
* possible benefit
* risks
* To be considered, related issues
* alternatives (different solution, Extension)
* real life scenarios
* competitors' approach
* accessibility impact,
* Related Bugzilla issues

CU

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org

Re: Specifications for Enhancement Requests

[Andrea Pescetti <pe...@apache.org>]

Rainer Bielefeld wrote:
> https://issues.apache.org/ooo/show_bug.cgi?id=124455 ...
> I think for complex requests we should create something like a short
> specification where we collect all facts and thoughts, try to reach
> common sense how we should proceed.
> https://wiki.openoffice.org/wiki/Specification_template seems a little
> oversized, too complex and so rather deterring.

Contrary to popular belief (at least in some circles), many things at 
Apache became easier, not more complex! So: for sure we won't be 
requiring that specification template any longer.

What we have seen at Apache is something like Oliver's specification for 
his work on input fields:
https://wiki.openoffice.org/wiki/Writer/Input_Fields
(and Andre and others wrote clean, easy specification pages too).

In all cases, though, this was maintained directly by the developer 
working on a feature. So I suggest that you give a real developer 
(probably Oliver in this case) the possibility to assess the idea and 
tell us if it makes sense and how complex it is to implement. Then, 
depending on his feedback and subject to availability of someone who 
knows, it can be developed by an existing developer, proposed for a 
Summer of Code project and so on.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Specifications for Enhancement Requests

[Andrea Pescetti <pe...@apache.org>]

Rainer Bielefeld wrote:
> https://issues.apache.org/ooo/show_bug.cgi?id=124455 ...
> I think for complex requests we should create something like a short
> specification where we collect all facts and thoughts, try to reach
> common sense how we should proceed.
> https://wiki.openoffice.org/wiki/Specification_template seems a little
> oversized, too complex and so rather deterring.

Contrary to popular belief (at least in some circles), many things at 
Apache became easier, not more complex! So: for sure we won't be 
requiring that specification template any longer.

What we have seen at Apache is something like Oliver's specification for 
his work on input fields:
https://wiki.openoffice.org/wiki/Writer/Input_Fields
(and Andre and others wrote clean, easy specification pages too).

In all cases, though, this was maintained directly by the developer 
working on a feature. So I suggest that you give a real developer 
(probably Oliver in this case) the possibility to assess the idea and 
tell us if it makes sense and how complex it is to implement. Then, 
depending on his feedback and subject to availability of someone who 
knows, it can be developed by an existing developer, proposed for a 
Summer of Code project and so on.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org