Fwd: [whups] More design thoughts

[Mike Baptiste]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think this sounds great.  We're thinking along the same lines - using
the horde framework for a SourceForge like environment with whups being
a key part of that.  The parts are all there (pretty much)

My one concern is this sounds like it might reduce the flexibility of
whups - where now we create 'types' with their own states (filed into
classes like New/Assigned/Resolved, etc)  This makes it a very useful
system.  So I worry about making whups too specific to software project
mgmt.  Now this may just have been an example of how it would work,
which is fine.

SO are you saying that you're taking the abstraction level up one more
(ie instead of modules -> ticket types -> version we'd have Products ->
Product Type -> ??? -> ????)

Mike

PS - Got sidetracked on my attachment work (gotta love no power in NC -
7 days!) but hope to get soem stuff posted soon.

Chuck Hagenbuch wrote:
| I'm cleaning out my mailboxes; this is a little blast from the past. Might
| stimulate some inspiration here. Or something. :)
|
| ----- Forwarded message from jcptch@osfmail.isc.rit.edu -----
|     Date: Fri, 23 Jul 1999 09:58:25 -0400
|     From: Jon Parise <jcptch@osfmail.isc.rit.edu>
| Reply-To: whups@horde.org
|  Subject: [whups] More design thoughts
|       To: whups list <whups@horde.org>
|
| Alright, it looks like my mind is still in the design phase.  Here
| are my latest thoughts:
|
| Whups is a project management system, so, at the highest level, we
| have a project.  At this point, I think it's best for whups to
| support only a single project at a time (eg. the Horde Project).
|
| Projects are composed of products.  In our case, imp, horde (core),
| troll, turba, etc. are our products.  Most of what we focus on is
| at the product level.
|
| Products
|  - Versions
|    - changelogs
|  - Bugs
|  - Feature Requests
|  - Developers
|
| Things like CVS, documentation, and FAQ's are composed of multiple
| products.
|
| So, that's where my thinking is at the moment.  There a sort of
| heirarchy there.  I guess it would be straightforward to just write
| the thing, but I want to make sure it's expandable enough to apply
| to projects other than Horde.
|
| You'll note I mentioned documentation.  We're kinda lacking in that
| area, and I think it would be neat to include it as part of whups.
| Multiple people could contribute to or revise documentation in an
| online browsable form, maybe linked back to cvs.
|
| phplib is handling all of the session stuff / user auth stuff
| nicely, so I'll just use whatever chuck comes up with for that.
|
| Once again, I think bugs should be the first subsystem to be
| implemented.
|
| I still need to work out all the database details.  I started some
| of that last night.  I'm going to go pick apart some of the
| existing code to support this structure, but, once again, comments
| are requested.
|

- --
Mike Baptiste - MSB Networks - mike@msbnetworks.net
Download my GnuPG key at http://msbnetworks.net/msbnet.gpg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9+Qe8tbf8BjvL+3ERAnqiAKDNGFI7024xgpk7iCps0Dl2ef+3CQCeI5lf
1xQLkJQauaDStUPtReDTsgA=
=+iC+
-----END PGP SIGNATURE-----