[whups] new to whups
Fri Oct 25 21:15:31 2002
Quoting Gary Weinreb <email@example.com>:
> I've been messing around with it, modifying it as a Projects management
> app,, rather than a Bug tracking app.
I'd be curious about what kinds of things that you were changing.
> Some parts, such as the Query Builder, don't make any sense to me, are
> incomplete, or I've yet to discover their workings.
The Query Builder is for putting together complex searches that you can
save, edit, and re-run later. I seem to be talented at breaking it, but as
of my last commits, it was actually working quite well.
> Same with the Reports section.
Try it as of yesterday...
> Basically, you have the following data elements:
> 1) Modules - top level, I use this for Client Name.
> 2) Type - I use this like a template for Project Type, as each Type
> a set of:
> 2.1) States - I think of this as the Stages of progress that a Project
> goes through...
> 2.2) Priorities - I use this to indicate whether things are on track
> timewise, i.e. I use Priorities like Normal, Rush, Super-Rush, or more
> recently, I use Green (OK), Yellow (Caution), Orange (Warning), Red
> (Danger), Blue (Excellent). (If you see where I'm thinking of going with
> this vis-a-vis Horde Categories, you're right on!)
This is all pretty accurate.
> 2.3) Subjects - I don't use these, but you can set up key words which
> can apparently be queried against...
It's the summary. I hated not having a one-line tag for what each
> 2.4) Responsible Users - For me, authenticating via
> Imp-CyrusIMAP-SASL-PAM-MySQL, these are horde_users who have Identities
> set up through Imp. There may be other ways to have responsible users,
> you can add any name you want in Whups, but the only users for whom the
> notification (see below) mechanism works, are those with Imp Identities.
> I would like to rework this to include Internal Users (as is), and
> External Users, for some notification events.
Yes, we need much better support for public users; we'll need this for
having Whups run bugs.horde.org.
> 3) Versions - I use this to set up time oriented sets of Tickets
> (Projects). i.e. I set up a version for each Project Cycle.
Yup. Also intended pretty specifically for horde uses, so that we can track
RELENG_1, RELENG_2, HEAD, etc. for each application inside the same Module.
> 4) Tickets - This is an Instance (in OOP parlance) of a Type. I call
> each of these a Project, rather than a Ticket, and I use several Projects
> with the same Module (Client) and Version, to manage a set of Projects
> for a recurring creative process, such as a creative production process
> which recurs on a weekly cycle and requires Audio Production tasks and
> Graphics Production tasks, as well as Administrative Tasks.
Yup, I can see all that. Same thing more or less for bugs/tickets.
> Basically, one creates a Ticket (Project), and for each change of State,
> Assignment (to a User), Priority, or addition of a Comment, responsible
> Users are notified via email, and an Audit Trail is maintained.
> Whups integrates with Hermes (time-tracking) in the following
> manner: Hermes seems to use the whups_modules table as it's data source
> for what is called Client:Job. The other data element in Hermes that
> could integrate with Whups is called Job Type, which seems like it should
> be mapped to whups_types, but currently isn't.
There was a reason I didn't do this, and I don't remember what it was.
Brain? What brain?
> So, I'm looking for guidance/input/comments/collaboration on fleshing
> Whups out as a Project Management App. in a manner which I can share back
> with the Horde Project. It may be, as Chuck has indicated previously,
> that Whups as a Project Module should be a separate module. I don't know
> the answer to that. I know that I don't understand how to make even the
> simple changes I'm making to the interface elements (human readable
> references to data elements, calling Tickets: "Projects", for instance)
> work with the Internationalization mechanism in a reasonable manner. It
> seems that we would need multiple sets of translations. I can imagine
> that different industries use different terminology for aspects of their
> work flow, and that the existing framework of Whups lends itself to a
> variety of Process Management/Procedural Delegation type applications. It
> seems that to make it as flexible as possible, Admins would be able to
> name what they want to call at least some of the data elements for their
> implementation, i.e. Ticket-Project-Job-Process-Class-Session-Appointment.
That makes sense; I'm not sure if modifying the en_US translation would be
enough for you, but it's described here:
(or is that not quite the right entry - Eric?)
> I'd also like to have the ability to fine-tune what happens at various
> events, i.e. When a Project of Type ABC, goes from State 01 to State 02,
> Notification is sent to Internal Users Joe, Sue, and Mary, and External
> User Client_Tom; but when it goes from State 02 to State 03, only the
> Internal Users Joe and Sue are notified.
That sounds great; a workflow like that would take some work to develop, but
could be widely applicable if it was generic enough.
> Likewise, when a Project changes State, I'd like to automatically
> generate a certain set of Tasks (Nag integration), and request a specific
> User assign them manually, or assign them based upon some algorithm.
> I'd like to have the State change when all of it's Tasks are Completed,
> or conversely, resist changing State UNTIL it's Tasks are all Complete.
Also oooh :)
> I'd greatly appreciate some guidance on this, and would be honored to
> contribute back to Horde.
I'd encourage you to keep discussing what you'd like done, and hopefully get
to the point of patches; we can get you CVS access to whups if you start
doing heavy work on it. The workflow stuff sounds especially exciting to me,
as you may have figured out.
Charles Hagenbuch, <firstname.lastname@example.org>
"People ask me all the time what it will be like living without otters."
- Google, thanks to Harpers