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

Fri Aug 4 07:54:15 UTC 2006

Thanks goran

Can you give me one example of what is a process, an issue and a case

Process: managing bug fixes
Issue: ...
Case: ...

> 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
> _______________________________________________
> Setools mailing list
> Setools at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/setools