Eike Rathke [EMAIL PROTECTED] writes:
On Tuesday, 2006-10-31 22:48:39 +0100, Thorsten Behrens wrote:
how would a spec help (a community dev) in reaching such an agreement?
[snip]
What I was trying to point to is the fact that reading and editing
a collaborative wiki page for
Thorsten Behrens wrote:
Bernd Eilers [EMAIL PROTECTED] writes:
We do have a semi-automated process to generate Release Notes. This
takes advantage of the OpenOffice Document file format and a standard
template being used for the specification documents. Information from
specifications
Hi Thorsten,
On Tuesday, 2006-10-31 22:48:39 +0100, Thorsten Behrens wrote:
Specs aren't only about UI, they're also about behavior of a feature.
Behavior of a feature, if not obvious, is something that must be agreed
upon. We do have examples of started development, patches were sent in,
Hi Christian,
On Thu, 2006-11-02 at 00:47 +0100, Christian Lohmaier wrote:
But surely the specification needs to be final or stable or
whatever you want to call it before the code gets into the master.
Sure - it needs to be in a good state of agreement with the code,
although as we
Hi Michael, *,
On Thu, Nov 02, 2006 at 11:10:12AM +, Michael Meeks wrote:
On Thu, 2006-11-02 at 00:47 +0100, Christian Lohmaier wrote:
[...]
And if you need to change your whole feature multiple times, then you
ought to thing before. (and again this doesn't relate on how to actually
Hi Christian,
And if you need to change your whole feature multiple times, then you
ought to thing before. (and again this doesn't relate on how to actually
code it, but on what the feature is supposed to do)
Anyone that thinks they can sit down and design a perfect system and
then
On Thu, Nov 02, 2006 at 01:50:57PM +0100, Frank Schönheit - Sun Microsystems
Germany wrote:
Hi Christian,
And if you need to change your whole feature multiple times, then you
ought to thing before. (and again this doesn't relate on how to actually
code it, but on what the feature is
Hi Christian,
Yes: It's one time 9 days of work, as opposed to 9 times one day of work :)
No. For the user it is 3 times a different behaviour instead of one
change.
Okay, wasn't clear that you talk about changes in the feature after
users have seen it.
Even then - if this happened in a
On Thu, Nov 02, 2006 at 02:52:19PM +0100, Frank Schönheit - Sun Microsystems
Germany wrote:
Even then - if this happened in a snapshot build -, it wouldn't be a Bad
Thing per se, but that's perhaps a different story. (BTW: All bells and
whistles of our processes didn't save us from this
At least, that's also my experience: If the project is sufficiently
complex, then you can forget about the specify, implement, test waterfall.
Exactly. Writing the perfect spec before starting to code is some how a
waste of time. This is something which only works in theory and which is
not
Hi Bernd,
Bernd Eilers wrote
We do have a semi-automated process to generate Release Notes. This
takes advantage of the OpenOffice Document file format and a standard
template being used for the specification documents. Information from
specifications documents is extracted via XSLT and a
Hi Thorsten,
Thorsten Behrens schrieb:
Eike Rathke wrote:
Specs aren't only about UI, they're also about behavior of a feature.
Behavior of a feature, if not obvious, is something that must be agreed
upon. We do have examples of started development, patches were sent in,
but there wasn't
Hi Thorsten, all,
Thorsten Behrens schrieb:
Hey, and yes, having a feature documented is _also_ nice
IMHO it is not nice, but an indispensable part of software
engineering. A spec defines the _intention_ of a piece of software.
Without a clear and documented intention I cannot make
Christian Lohmaier schrieb:
Again: Specs (in my opinion) is about what the effect on the user is,
not on how you code the stuff.
Agree.
One thing this thread hopefully does, is to clarify such terms, so the
whole community understands about the same thing by the word spec.
A spec describes
Hello Kohei,
Kohei Yoshida wrote:
I have no doubt that expressing and formulating ideas into words is
probably fun and rewarding activity for you, just as it is fun and
rewarding for me to formulate my ideas into code. This is probably
why you're in marketing and I'm not. ;-)
I do write
Hi Cor,
On 11/2/06, Cor Nouws [EMAIL PROTECTED] wrote:
Maybe this whole discussion is influenced by the fact, that many in
FLOSS love freedom so much, that they become a little bit offended, when
they see some kind of format ;-) (of course no offence meant).
Nah. This thread has little to
David Fraser schrieb:
Hi Christian
Thanks for your offer! I think a wiki version of the Template would be a
substantial aid to many people, and from the rest of the response on the
mailing list I'm not alone in thinking that.
Could you let us know if you start working on this - I presume
Thorsten Behrens wrote:
Mathias Bauer [EMAIL PROTECTED] writes:
Not exclusively. Also developers will benefit from a spec if they have
to refactor/change/extend the code later on. Believe me, I can't count
the occasions any more where I would have been glad to have a
specification for a
Mathias Bauer [EMAIL PROTECTED] writes:
Thorsten Behrens wrote:
Mathias Bauer [EMAIL PROTECTED] writes:
Not exclusively. Also developers will benefit from a spec if they have
to refactor/change/extend the code later on. Believe me, I can't count
the occasions any more where I would
Hi Thorsten,
However, far more important than a string review, IMHO, would be to drop
German as a developer provided second source localization. Let's get rid
of that.
Aww, of course. I thought we already did that. :-/
+1 here. That's an obsolete requirement for an international project
such
On Tue, 2006-10-31 at 17:42 +0100, Christian Lohmaier wrote:
I disagree. Esp. when the UI is changed significantly the UI-mockups are
necessary. Both for finding flaws in the proposed design as well as for
documentation.
I'm well up for the UI team doing mock-ups and communicating
Hi David, All,
It would be great if we could continue the wiki discussion on
[EMAIL PROTECTED] I think this is the right place for stuff like that.
BTW. The spec template macro problems are now fixed.
Regards,
Christian
David Fraser schrieb:
Hi Christian
Thanks for your offer! I think a
Michael Meeks wrote:
But we didn't write down a spec. We conceived of the idea, then
implemented it, now we have it. The original conception of course was
prolly inaccurate, no-one gets things right 1st time, we most likely
have a solution that is now far better than that, similarly we
Mathias Bauer wrote:
Kohei Yoshida wrote:
2) The target audience is not very clear. Thanks to this thread,
though, now I'm beginning to see who the specification documents are
intended for (mostly for QA, right?).
Not exclusively. Also developers will benefit from a spec if they have
to
many people wrote:
As mentioned by others: it is a good thing if writing (some sort of)
specification can be made easier.
OTOH, I've dóne it once, and it took me about three hours. Including
studying the template and the related documentation at the Wiki - both
very good IMHO. Next
On 11/1/06, Cor Nouws [EMAIL PROTECTED] wrote:
Michael Meeks wrote:
But we didn't write down a spec. We conceived of the idea, then
implemented it, now we have it. The original conception of course was
prolly inaccurate, no-one gets things right 1st time, we most likely
have a
Hi Kohei,
Kohei Yoshida wrote:
While I agree with the gist of your statement, I must say this is not
universally applicable to all forms of creative activities, of which
coding is one.
Often a conceived idea of a certain code design can be easily
formulated in terms of programming code, but
Hi Thorsten,
Thorsten Behrens wrote:
However: I've seen (and joined) a very lengthy and intense discussion
on [EMAIL PROTECTED] about all good things that using the Wiki would bring.
About more community involvement especially. The Wiki came, but very
little extra time, if any at all, has been
Hi Michael, *,
On Wed, Nov 01, 2006 at 02:20:28PM +, Michael Meeks wrote:
On Tue, 2006-10-31 at 17:42 +0100, Christian Lohmaier wrote:
I disagree. Esp. when the UI is changed significantly the UI-mockups are
necessary. Both for finding flaws in the proposed design as well as for
Hi Cor,
On 11/1/06, Cor Nouws [EMAIL PROTECTED] wrote:
Hi Kohei,
I think it is party right what you write. Because I've some more
experience is writing words than code, I don't have that 'problem' and
maybe under estimate it.
I have no doubt that expressing and formulating ideas into
Hi Mathias,
On 10/31/06, Mathias Bauer [EMAIL PROTECTED] wrote:
Kohei Yoshida wrote:
2) The target audience is not very clear. Thanks to this thread,
though, now I'm beginning to see who the specification documents are
intended for (mostly for QA, right?).
Not exclusively. Also developers
Hi Kohei,
There are mainly two complaints I have with the current specification
project:
1) It asks for way too many details, especially in the UI design
section. It's not too bad if the feature involves only one
control/widget change. But once the change involves three or more
dialogs,
Hi Michael,
Michael Meeks wrote:
Hi Mathias,
So, while broadly agreeing with most of what you say:
On Mon, 2006-10-30 at 08:53 +0100, Mathias Bauer wrote:
Without the spec the QA wouldn't be able to even find bugs in
many cases (with the exception of obvious ones).
We hear
Thorsten Ziehm [EMAIL PROTECTED] writes:
Thorsten responding to Kohei:
An example you want to design a new car. One important thing are the
tires. You said the development team you need a tire for your new car.
In you mind you know all details you need at the tires - height, width,
rim, how
Thorsten Ziehm [EMAIL PROTECTED] writes:
The team which worked out the specification process know that the
specifications are not in the highest quality now. This is a learning
process for each member on the specification (User Experience,
Development, Quality Assurance and Documentation). So
Hi there!
There´s one thing we should not forget when discussing to use the Wiki
for creating Specifications.
We do have a semi-automated process to generate Release Notes. This
takes advantage of the OpenOffice Document file format and a standard
template being used for the specification
Hi Thorsten B.
The specification template is should a support to do not forget
something in a dialog. And there are many things you can forget, when
you have to work platform independent and language independent.
I think the basic misunderstanding between our two camps (Sun people
vs. OOo
Thorsten Ziehm [EMAIL PROTECTED] writes:
I think the basic misunderstanding between our two camps (Sun people
vs. OOo volunteers) is the fact that the typical workflow is simply
radically different.
That the workflow is different I see, but why it should be?
Why not? If this does not
Hi *,
On Mon, Oct 30, 2006 at 11:17:36PM -0500, Kohei Yoshida wrote:
On 10/30/06, Nikolai Pretzell [EMAIL PROTECTED] wrote:
Kohei Yoshida schrieb:
On 10/27/06, Nikolai Pretzell [EMAIL PROTECTED] wrote:
Kohei Yoshida schrieb:
[...]
But I wouldn't want to try spec'ing every minute detail
Bernd Eilers [EMAIL PROTECTED] writes:
We do have a semi-automated process to generate Release Notes. This
takes advantage of the OpenOffice Document file format and a standard
template being used for the specification documents. Information from
specifications documents is extracted via XSLT
Hi Thorsten,
On Tuesday, 2006-10-31 12:06:28 +0100, Thorsten Behrens wrote:
But the difference is that there's no request from high-above to
implement a certain feature, and no dedicated time in user experience
to roll out a detailed UI spec beforehand.
Specs aren't only about UI, they're
Hi Bernd,
On Tuesday, 2006-10-31 12:41:25 +0100, Bernd Eilers wrote:
We do have a semi-automated process to generate Release Notes. This
takes advantage of the OpenOffice Document file format and a standard
template being used for the specification documents. Information from
Michael Meeks wrote:
Hi Mathias,
So, while broadly agreeing with most of what you say:
On Mon, 2006-10-30 at 08:53 +0100, Mathias Bauer wrote:
Without the spec the QA wouldn't be able to even find bugs in
many cases (with the exception of obvious ones).
We hear this a lot.
Kohei Yoshida wrote:
2) The target audience is not very clear. Thanks to this thread,
though, now I'm beginning to see who the specification documents are
intended for (mostly for QA, right?).
Not exclusively. Also developers will benefit from a spec if they have
to refactor/change/extend
Eike Rathke [EMAIL PROTECTED] writes:
Specs aren't only about UI, they're also about behavior of a feature.
Behavior of a feature, if not obvious, is something that must be agreed
upon. We do have examples of started development, patches were sent in,
but there wasn't even an agreement on how
Mathias Bauer [EMAIL PROTECTED] writes:
Not exclusively. Also developers will benefit from a spec if they have
to refactor/change/extend the code later on. Believe me, I can't count
the occasions any more where I would have been glad to have a
specification for a feature that needed a larger
Thorsten Behrens [EMAIL PROTECTED] writes:
Having explicit UI guidelines/design rules would most probably allow
the average developer to correctly place a checkbox
Drats - even linked from the specs page:
http://wiki.services.openoffice.org/wiki/User_Interface_Guidelines
My bad,
-- Thorsten
Hi Nikolai,
Ideally, the developer should also be responsible for updating the
spec document to ensure that it keeps up with the requirement change
over the development cycle.
The developer not only should be, but is responsible for this.
Really? The new specification template separated the
Hi Nikolai,
The developer not only should be, but is responsible for this.
...
Wouldn't you agree that in case the developer is only the developer,
but does not take any of the other two mentioned roles, then it's *not*
her responsibility to ensure the synchrony?
No, I wouldn't. Actually, I'd
Hi Kohei,
Kohei Yoshida schrieb:
On 10/27/06, Nikolai Pretzell [EMAIL PROTECTED] wrote:
Kohei Yoshida schrieb:
In a not-so-ideal world, things don't always go as planned.
Requirements grow organically over the development life cycle of that
feature, but the spec document may not always
Kohei Yoshida wrote:
I also have this question: does every developer at Sun/StarDivision
successfully maintain the specs he/she wrote, and all specs posted on
the specs website currently reflect the current state of their
respective feature they describe with clear descriptions and no
Hi Christian
Thanks for your offer! I think a wiki version of the Template would be a
substantial aid to many people, and from the rest of the response on the
mailing list I'm not alone in thinking that.
Could you let us know if you start working on this - I presume
Kohei Yoshida wrote:
Hi David,
On 10/25/06, David Fraser [EMAIL PROTECTED] wrote:
This involved developing the spec collaboratively in the wiki
Unfortunately the spec team did not like this idea and have gone for an
OOo template for designing specifications with
Did the spec team discuss with
Hi Mathias,
So, while broadly agreeing with most of what you say:
On Mon, 2006-10-30 at 08:53 +0100, Mathias Bauer wrote:
Without the spec the QA wouldn't be able to even find bugs in
many cases (with the exception of obvious ones).
We hear this a lot. And, now we know that
Hi Nikolai,
On 10/30/06, Nikolai Pretzell [EMAIL PROTECTED] wrote:
Hi Kohei,
Kohei Yoshida schrieb:
On 10/27/06, Nikolai Pretzell [EMAIL PROTECTED] wrote:
Kohei Yoshida schrieb:
In a not-so-ideal world, things don't always go as planned.
Requirements grow organically over the
Thorsten Behrens schrieb:
David Fraser [EMAIL PROTECTED] writes:
...but I think there are still significant cases where using a wiki
is a much faster route for people (particularly outside
contributors) to use to collaboratively produce a specification.
Seconded. A wiki has a low barrier
Hi,
Kohei Yoshida schrieb:
The problem with the current specification process from my own
experience and observation is that, it puts the wrong focus on the
purpose that the project is intended to serve.
In a not-so-ideal world, things don't always go as planned.
Requirements grow
Nikolai Pretzell [EMAIL PROTECTED] writes:
The one issue I see is, how to finalize a spec and make it
stable/unchangeable for the times the functionality is unchanged. QA
and bug-fixing need a stable spec to compare the actual behaviour with
it.
I already alluded to some solutions in
Nikolai Pretzell [EMAIL PROTECTED] writes:
Actually, every feature that changes behaviour needs a spec. How else
should the QA be able to test the new feature? Against what should it
do that testing?
Uh, I'd rather put it this way: changing behaviour necessitates
updating a spec - _if_ there
On 10/27/06, Nikolai Pretzell [EMAIL PROTECTED] wrote:
Kohei Yoshida schrieb:
In a not-so-ideal world, things don't always go as planned.
Requirements grow organically over the development life cycle of that
feature, but the spec document may not always get updated.
There is a clear rule
Frank Schönheit - Sun Microsystems Germany [EMAIL PROTECTED] writes:
This doesn't mean we can't freeze the spec once all stakeholders agree
it's final, or call it make a snapshot, by moving the Wiki content to
a .odt at some time.
Sure. There's a bunch of tools that export (Media)Wiki
Hi David,
from a feature documentation standpoint it makes no difference to use
the template, a wiki, a HTML page, or what ever comes into your mind.
It is more important that the UI feature and its functionality is
described well. I personally think a wiki is absolutely fine to do that,
but
Hi David,
from a feature documentation standpoint it makes no difference to use
the template, a wiki, a HTML page, or what ever comes into your mind.
It is more important that the UI feature and its functionality is
described well. I personally think a wiki is absolutely fine to do that,
but
David Fraser schrieb:
Kazunari Hirano wrote:
Hi,
Frank Schönheit wrote:
However, what I really *really* like about this process is
the exchange of ideas and arguments.
I respect the process.
I encourage community developers and CJK developers to access the spec
project wiki [1] and the spec
Hi David,
from a feature documentation perspective it makes no difference to use
the template, a wiki, a HTML page, or what ever comes into your mind.
I think it is more important that the UI feature and its functionality
is described in well mannor. I personally think a wiki is absolutely
Kazunari Hirano wrote:
Hi,
Frank Schönheit wrote:
However, what I really *really* like about this process is
the exchange of ideas and arguments.
I respect the process.
I encourage community developers and CJK developers to access the spec
project wiki [1] and the spec template [2].
For
David Fraser [EMAIL PROTECTED] writes:
...but I think there are still significant cases where using a wiki
is a much faster route for people (particularly outside
contributors) to use to collaboratively produce a specification.
Seconded. A wiki has a low barrier for entry, can
Hi David,
For issue 12719 I attempted to have a faster and more accessible
specification process
This involved developing the spec collaboratively in the wiki
Unfortunately the spec team did not like this idea and have gone for an
OOo template for designing specifications with
This is
Hi David, *,
David Fraser wrote:
[...]
3) The spec process is apparently working well for those inside Sun,
less well for those outside. If there were an easier route for those
less involved in development to produce specs it could be run
concurrently as an alternate mechanism (possibly with
Hi Cor,
On 10/25/06, Cor Nouws [EMAIL PROTECTED] wrote:
Hi David, *,
David Fraser wrote:
[...]
3) The spec process is apparently working well for those inside Sun,
less well for those outside. If there were an easier route for those
less involved in development to produce specs it could be
70 matches
Mail list logo
