On Sun, 15 Jun 2003, Stefano Mazzocchi wrote:
There are two possible methodologies I see:
1) big to small - give users all possible freedom and restrict that
freedom once we understand potentially problematic usages.
2) small to big - give users the least possible freedom based on some
Giacomo Pati wrote:
I'm late, I know ;-)
But welcome anyway!
On Sun, 15 Jun 2003, Stefano Mazzocchi wrote:
2) small to big
+1
Andrew.
--
Andrew SavoryEmail: [EMAIL PROTECTED]
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
2) small to big - give users the least possible freedom based on some
required functionality and grow as the users express their needs.
+1 simplest thing that could possibly work.
-Original Message-
From: Tony Culshaw [mailto:[EMAIL PROTECTED]
Sent: 16 June 2003 18:10
To: [EMAIL PROTECTED]
Subject: Re: [vote] FOM design methodology
I've considered using in in the past for a project and then
rejected it as being in the api too unstable basket.
Hah
Need it be either/or?
(This is a possibly a naive question, but you wanted feedback!)
Could there be a 'solid' and an extended 'experimental' contract?
Solid would be 'written in stone', nothing could be removed from it.
Experimental would have _additions_ to the basic contract, would have
Stefano Mazzocchi wrote:
2) small to big - give users the least possible freedom based on some
required functionality and grow as the users express their needs.
+1
Carsten
Stefano Mazzocchi wrote:
2) small to big - give users the least possible freedom based on some
required functionality and grow as the users express their needs.
+1
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
2) small to big - give users the least possible freedom based on some
required functionality and grow as the users express their needs.
+1
+1
--
Torsten
2) small to big - give users the least possible freedom based on some
required functionality and grow as the users express their needs.
+1
regards Jeremy
As a normally voteless community developer/user:
On Monday, June 16, 2003, at 12:31 AM, Stefano Mazzocchi wrote:
For this reason, I want to know the community feeling on the
methodology
that should be applied to FOM design.
There are two possible methodologies I see:
1) big to small - give
At 03:58 AM 6/16/2003, you wrote:
Stefano Mazzocchi wrote:
2) small to big - give users the least possible freedom based on some
required functionality and grow as the users express their needs.
+1
Tony Culshaw wrote:
I've considered using in in the past for a project and then rejected it as
being in the api too unstable basket.
Anything that ensures code that I cut now won't break later and has more of
a future gets my vote.
[+1] small to big.
[-1] big to small.
I agree.
Stefano Mazzocchi wrote:
1) big to small - give users all possible freedom and restrict that
freedom once we understand potentially problematic usages.
2) small to big - give users the least possible freedom based on some
required functionality and grow as the users express their needs.
+1 for
On Mon, Jun 16, 2003 at 09:58:10AM +0200, Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
2) small to big - give users the least possible freedom based on some
required functionality and grow as the users express their needs.
+1
Here is my +1
Michael
Carsten
2) small to big
+1 from me
Ricardo Rocha wrote:
Stefano Mazzocchi wrote:
1) big to small - give users all possible freedom and restrict that
freedom once we understand potentially problematic usages.
2) small to big - give users the least possible freedom based on some
required
Joerg Heinicke wrote:
2) small to big
+1 from me
Ricardo Rocha wrote:
Stefano Mazzocchi wrote:
1) big to small - give users all possible freedom and restrict that
freedom once we understand potentially problematic usages.
2) small to big - give users the least possible freedom based on
On Sun, 15 Jun 2003, Stefano Mazzocchi wrote:
There are two possible methodologies I see:
1) big to small - give users all possible freedom and restrict that
freedom once we understand potentially problematic usages.
2) small to big - give users the least possible freedom based on some
Stefano Mazzocchi dijo:
There are two possible methodologies I see:
1) big to small - give users all possible freedom and restrict that
freedom once we understand potentially problematic usages.
2) small to big - give users the least possible freedom based on some
required functionality
I've considered using in in the past for a project and then rejected it as
being in the api too unstable basket.
Anything that ensures code that I cut now won't break later and has more of
a future gets my vote.
[+1] small to big.
[-1] big to small.
- Original Message -
From: Stefano
On Sunday, June 15, 2003, at 07:31 PM, Stefano Mazzocchi wrote:
2) small to big - give users the least possible freedom based on some
required functionality and grow as the users express their needs.
+1
-pete
21 matches
Mail list logo
