Gjallar brainstorm (was Re: [Setools] Gjallar (previously known as Q2) next steps!)

[goran at krampe.se]

Hi!

=?ISO-8859-1?Q?St=E9phane_Ducasse?= <stephane.ducasse at univ-savoie.fr>
wrote:
> 
> On 3 août 06, at 21:12, Hans N Beck wrote:
> 
> > Hi Stef,
> >
> > Am 03.08.2006 um 17:18 schrieb Stéphane Ducasse:
> >
> >>> I am currently focusing on the advanced filtering mechanism. The
> >>> architecture is in place but lots of detailed work is still left  
> >>> to do.
> >>
> >> We started to have a look at Q2. Florent is jumping on it and will  
> >> bombard you with
> >>
> >
> > Which of the many aspects of Gjallar (bugs, requirements, general  
> > tracking,  workflow, visualization, the system as a whole ....)  
> > interests you (or your working group) ?
> 
> For now I do not understand it, even by looking at the screenshots. :)
> I do not understand what is a process nor what is a filter....

A Process is an "issue process" with all that it entails. Like a system
within the system.
The customer has many different issue processes ranging from software
and hardware developmen, customer support processes, sales processes,
personell management processes, internal IT issues etc etc.

Each such issue process typically has different sets of users, different
workflows, different fields/forms to gather information about the issue,
different permission schemes and so on.

So in Gjallar we first have a "global" level with all users, all
processes and all global reusable objects like forms and custom objects
(=imported entities from external systems that are kept in synch,
typically using ODBC).

Each user has access to n of the Processes. Then each Process knows "the
rest" about how issues are dealt with within that Process.

The only two mechanisms in the system that "ties" processes together
are:

1. Two or more Processes importing the same objects from the global
space. Like for example the same Form. Or of course, overlapping Sets of
users.

2. Cases (the term used in Gjallar for "issue") can link to each other
between Processes.


Gjallar has a detailed implementation of DeepCopying and has a
collection of Process prototypes. So when the administrator shall create
a new Process he/she can "clone" one of the existing Process prototypes
and get a Process up quickly and with a suitable configuration.

One of the most important configuration you do for a Process is to
specify the Workflow. A Process only has one workflow (some systems can
have different workflows for different kinds of issues but we have
simplified it and then consider that to be a separate Process) so within
a Process all issues follow the same lifecycle.

A Workflow is a directed graph of Stages and Transitions. One specific
stage is the start stage and several are end stages. A case (=issue) can
only exist in one stage at a time. So it moves from the start stage
using the available directed transitions to other stages and eventually
ends up in a stage marked as an end stage.

Cases are never deleted and never "drop out" of the workflow. So they
simply get piled up in end stages. The start stage can be considered
like an inbox and we actually often call it the "Inbox".

Ok, then you asked about Filters. A filter is mathematically speaking a
boolean function taking a case (issue) as an argument. So given a
collection of cases you can apply a filter to get a subset.

In Gjallar there are two kinds of filters:
- the freetext filter using the external free text engine Swish-e.
- the normal filter which is either:
	- an arbitrary boolean expression of predicates
	- a simple conjunction of predicates (p1 AND p2 AND p3)

There are different kinds of predicates but typically all fields or
other attributes of a case can be used. For example, a multiselect list
box of all stages in the workflow.

Then to top it off you can stack filters on top of each other - like a
pipeline.

These filters can then be constructed by the user and are typically
owned by the user. Think of a filter as a complex select: expression (or
SQL expression). :)

Filters are then used in many different areas of Gjallar. Of course they
are used for searching/filtering the cases - but also for making fine
grained subscriptions of email notifications and reports/exports.

> Now what I would like to be able to express is the following:
> 	- kind of to do list that harversters could edit remotely

One way is to create a Process called "Todo lists", then create a very
simple workflow for it, like New->Working->Done. Then make a simple form
- all cases already have Subject, Description, Reporter, Responsible,
Attachments and a few other things built in. But you can add more fields
or even extra forms, which will appear as separate tabs in the tab UI
for the case.

Then to "classify" todo list items you typically create a CustomObject
which is like a table with fields. The simplest CustomObject could be
one called say... "Severity" with values like "Annoying", "Minor",
"Major", "Disaster".

Then you tie that CustomObject to a drop down list box in a Form, like
for example the default case creation form.

> 	- bugs life-cyle that could be attached to different squeak projects.

The life cycle is described by the Workflow. We could either create a
standard Workflow for bugs, then createt a Process prototype with that
workflow and clone it once for each Squeak project. But that would
create a bit too many Processes, so again, a good way is to express
which Squeak project a bug belongs to by using a CustomObject and a drop
down list to select from - much like in Mantis.

So typically you use one Process if all cases can share the same
workflow (same stages and transitions with rules), the same permission
model and the same set of users (but the permission model can let
different people do different things).

Well, this was a long email - it probably makes better sense after
reading the design document that I will put up tomorrow or later
tonight.
 
> Stef

regards, Göran