pcplantdb

[John Schinnerer <john@eco-living.net>]

Aloha,

> Whats the difference between closed, resolved and compleated?

Resolved means the developer claims to have fixed the bug.

Completed means the person(s) a task is assigned to claim(s) to have 
completed the task.

Closed means that for either of the above cases, some person responsible 
for verifying such things has verified that the bug really is fixed or 
the task really is completed.

In the case of a bug, the tester verifies (or not) the developer's claim 
of a fix.

In the case of a task, there would ideally be verification of task 
completion by some person managing the task - this is not well defined 
at present in our situation.

> Is there a way to mark a resolved issue as being part of the
> on going regression test.

A bug will be set to resolved when a developer makes a change intended 
to fix the bug in code that will be part of the next release.

In other words, any bug with status 'resolved' needs to be regressed 
against the next build.

> There seem to be some things in the tracker
> which we don't need to revisited, and other which do need checking
> with each new release.

For bugs:
A bug fix will either work, and the bug then be marked 'closed', and 
thus not revisited...
...or a bug fix will not work, and the bug then be set back to 'open' 
status, and then be revisited again (regressed) in some later build.

A given task may or may not be related to a particular build, so 
revisiting 'task' issues will probably vary wildly.

> It seems like the issue tracker is being used for some seperate things:
>     1) regression testing system
>     2) bug reporting

These two are part of the same system.  Bug reporting and regression 
testing are mutually interlinked:

A bug is reported and gets set to 'open' status.
A developer makes a fix and sets it to 'resolved' status.
A tester regresses (tries to reproduce) the allegedly 'resolved' bug in 
the new build and sets it to 'closed' (if bug is gone) or 'open' (if bug 
is still present).

>     3) project managment, i.e. scheduling tasks to be done

Yes, this would be an issue of type 'task'.

>     4) feature requesting

This would be an issue of type 'suggestion'.

> I'm wondering if its posible to split these up. May be this is what
> the Task tag is for.

Yep, exactly.  To see all still-in-progress tasks, do a search for all 
issues of type 'task' and status 'open'.

To see all bugs that need to be regressed in a new build, search for all 
issues of type 'bug' and status 'resolved'

...and so on...the ability to name and save your most common searches 
(queries) as links in your sidebar is one of the very nice features of 
Roundup.

> I guess the process might be
>     a) A "feature request" is added.
>     b) we discuss whether or not we want to implement it and
>     what priority it has.
>     c) The "feature request" is promoted to a "task". I.e something to 
> be done.
>     c1) Specification updated.
>     d1) Task is compleated.
>     d2) Tests developed to check that the feature works as intended.

Yep, that would be a process for dealing with issues of type 'suggestion'.
If it's not a current priority it can remain as a 'suggestion' until 
whenever we periodically revisit pending suggestions.

>     e) regression happens.

Regression testing wouldn't apply in this case.

It would apply if the feature is broken or partly works, resulting in a 
bug or bugs being generated, resulting in a fix or fixes being done, 
which fixes would then be regressed in the next build to see if the 
feature was now working, or was less broken.

> Order of d1/d2 could be different. As a design methodology, there is a
> lot of people into test first systems. I.e. write the test first then 
> write the code and check if it passes the test. (Never done this).

I can honestly say that I have never seen this done in a commercial 
production environment...great methodology idea though... ;-)

> I guess a home page for the tracker is needed. IE a page where
> new users first come to the tracker and public users can either
> add a "feature request" or a "bug", but not a "task" or a "regression 
> test".

Not sure what you mean by 'public users'.
Anonymous users can only view existing issues - to create an issue of 
any type, one will have to register as a named user.
User name of issue creator is automatically logged in the issue history.
So if anyone abuses their registration by creating inappropriate issues, 
that user will suffer the consequences...

> I think I'd recomend changing the "suggestion" task to "feature 
> request", its a name which has more resonance for me.

I just want to keep it short... :-)
I see 'feature request' as a subset of 'suggestion' - suggestions might 
include things besides program features.

> Don't really know what "Know issue" is about.

Known issue is shorthand for "we know about this and that's how it 
is/works, love it or leave it, don't expect us to do anything about this."

Sometimes it would be applied to bugs or suggestions people submit that 
we don't think are bugs or valid suggestions.

Sometimes it is applied to valid bugs that cannot reasonably be 'fixed' 
for whatever reason (system constraints, design flaws, whatever).

An alternate phrase some systems use is 'as designed' - I put 'known 
issue' because it seems more open and less arrogant...

Thanks for all these questions...I can use my above responses almost 
directly in some of the docs I need to put together.  Keep 'em coming!

cheers,
John S.

--

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net