RE: RE: [Design] Requirements?

On Wednesday, November 27, 2002 7:43 PM, Mitchell Baker said:
> You bet we're listening.

I knew :-)

> We're trying to get our heads around the
> project status, since we're new to this, identify existing info that
> would be useful to post, and drive some basic documentation.

... and that's quite a job! It could easily have been a full-time
occupation, only catching up on _one_ of the mailing lists at some times.

> For
> example, a chunk of thinking has been done about calendaring.  I've
> suggested that we ought provide a  overview of basic calendar
> plans, a
> description of how the calendar fits in with the general architecture
> (RDF repository/database, etc.) and other packages, and
> perhaps a list
> of topics we know need to be addressed.   This info would
> also provide
> context for subsequent, more detailed discussions.  We also need to
> provide some basic responses to the many suggestions received
> to date.


>  I believe these would be the mose helpful starting points.
(Comments on the starting points in a parallel posting)

I think the key question is whether you want the process(es) to be primarily
driven by the technology or the requirements.

Taken to the extreme, technology driven means something like "Hey, look we
have this fancy RDF-ZODB-Quantum-Mechanic-Probability-storage here, what
could we use it for?", on the other hand requirements driven (also taken to
the extreme) could mean a statistical survey identifying the typical classes
of Chandler users, then cooking that down to interviewing a representative
number of them closer to derive their use cases, and give the result as
untouchable axioms to the developers.

None of these extremes can work for Chandler as an open-source and
community-dependant project. I would prefer a primarily requirements driven
process but with bi-directional and tight feedback-cycles with the applied
technology.

To me, there doesn't seem to be any real difference in product management
for an open source, non-profit project and closed-source, commercial project
if you're aiming at a user base outside the open-source development
community itself, but I would really like to hear the thoughts of you
people, having tons of experience in this field!

IMO, you got to know your customer and his needs, if your "product" isn't
going to be just another nice technology proof of concept.

Another process question is top-down or bottom up - but this is probably
something you cannot (and should not?) steer in an community-process.

Regards,

Arnulv

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process