[Phpwiki-talk] DEFINITION: Ticket Tracking

[<jo...@or...>]

Hello everyone.

"Ticket tracking" is like a to-do list for a group of people, or for many
groups of people.  The phpwiki to-do list on sourceforge is a kind of
ticket tracker, as are bug trackers like the ones on sourceforge or
"Bugzilla".  Help desks and call centers often use ticket tracking systems
to keep track of who they've helped and who else needs help.

Generally a ticket corresponds to some task that needs doing or something
that needs attention-- a disk that needs to be backed up, or a customer who
needs to be called back, or a report that needs to be looked over and
signed by a manager. Tickets begin their lives "open", and when the task is
completed, they are "closed".  Generally tickets contain some more state
than just that: they may know what kind of skills are necessary for their
completion, and they have a log of who has done work towards that ticket
and any comments they left.  Anyone can log in to the ticket tracking
system and see, with one search, which "open" (not-yet-completed) tickets
(tasks) there are for people with their expertise.

What I'm proposing is to add some new syntax to phpWiki pages that
integrate them into a ticket tracking system, so that if someone writes
text like "((finance:approve))" in their wiki page-- which means that they
want someone from the finance department to approve what they've written on
the page-- then a new ticket will be created which says just that.  If ever
someone from finance edits the page and removes that text
("((finance:approve))"), the ticket is closed.

Other tickets might look like:

        ((sales:rewrite))
        ((CEO:approve))
        ((george:explain))

Or, if you're a small company or just a single person, you can use this
system for reminders for yourself about where in your phpwiki you would
like some additional information, or what you would like to rewrite, using
the shorter form:

        ((rewrite))
        ((check))
        ((fixme))

And then from one page, the ticket tracking page, you get links to every
wiki page that needs some work, and you can search or sort through these
wiki pages based on what kind of expertise they need (sales/CEO/george) or
what needs to be done (rewrite/approve/explain/check), or when they were
last worked on, or who entered the request, etc.


NOTES AS TO IMPLEMENTATION

1. It's clear that this feature wouldn't be of use to everyone, and the
   phpwiki syntax-space is already getting kind of cluttered.  It would be
   nice, and fairly easy, to be able to turn syntax elements, including
   ticket recognition ("(())"), on and off.  So maybe a global ("define()")
   in the index.php file would turn this whole system on and off, and it
   would be off by default.

2. The logical time to create/open/close tickets is when the page
   containing them (or from which they have been deleted) is first saved.
   Right now the only parsing of page text on save is for converting tabs.
   This is in savepage.php.  I would have to add something, either there or
   in WikiDB_PageRevision::createRevision(), that checks for occurrences of
   the syntax and called out to the ticket functions is they are found.

3. Seth Cohn writes that phpGroupWare has a nice ticket tracking system.
   It does.  But phpGroupWare is *big* and one of the nicest things about
   phpWiki is that it's still pretty simple and small.  So here's what I
   will do: I will create a small, one page ticket tracker that can be
   distributed with phpWiki and that uses its own database table, but I
   will also include glue so that phpWiki can optionally call out to the
   PHPGW API instead, so that if you already happen to be using PHPGW,
   phpWiki will register tickets in it.  I've looked at the API, and this
   shouldn't be too hard.

   I'm not, however, going to do the work to "embed" phpWiki into a PHPGW
   module.  I have little interest in forcing the wiki into an even smaller
   box on my browser window, surrounded by even more buttons and menus.

That's all for now.  There are a lot of design decisions I haven't made yet.
I'll post a summary asking the groups opinion on a number of possibilities
in the next day or so.

Thanks,

        Joe
        http://orbis-tertius.net/joe/