pcplantdb

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

Aloha,

> Just want to clarify what you have written. Flow diagrams
> for passage of issues
>
> (bug,new) -> (bug, open) -> (bug,resolved) -> (bug,closed)
>                 ^                 |
>                 |-   new build  <--

I will add making a simple visual flowchart for this for the testing 
docs to my to-do list...

The path from resolved to closed would also go through 'new build', if 
by 'new build' you mean the bug is regressed against the new build.

1. A developer makes a fix in code that will be part of the next 
release, sets status to 'resolved' and assigns bug back to the tester.
2. When that code is released, the tester regresses (tries to reproduce) 
the bug in the new release.
3a. If the bug is fixed, *then* status goes to 'closed'.
3b. If the bug is not fixed, *then* status goes back to 'open' and bug 
is assigned back to the developer.

> (task,new) -> (task,open) -> (task,completed) -> (task,closed)

Yeah - and if there is disagreement or misunderstanding or whatever 
about what 'completed' really means/meant, then there might be an 
alternate path from 'completed' to 'open'.

Example:
I have a task assigned to me.
I complete what I think the task entails ("do X") and set it to 
'completed' and assign it to whoever is managing that task.
Whoever is managing that task checks on task completion and says "no, 
that task also includes doing Y and Z, not just X" and sets it back to 
'open' and assigns it back to me.

> I suppose I'm thinking we need something like:
>
> (bug,new) -> (bug, open) -> (bug,resolved) -> (bug,closed)
>                 ^                                  |
>                 |-   new build  <-------------------
>
> In that the the developer fixes bug, then the tester verifies
> that the bug really is fixed.

Yeah, words exactly correct; flowchart not however.
A bug is only closed after the tester has regressed it against the new 
build in which it is allegedly fixed and found that it is in fact fixed.

In other words, resolved only goes to closed (or open) by way of 
regression, normally.

There are always a few exceptions now and again - mistakes in entry, 
buggy bugs that suddenly can't be reproduced, etc.  They will get closed 
by admin or appropriate person on a case-by-case basis.

> There does need to be a way (not necessarily in issue tracker)
> for Joe Public to register a bug. Forcing users to log on
> is a "bad thing" as most don't want to go that hassle. This
> could mean that we never get to see a bug at all.

One option would be to set up an e-mail address for anonymous bug reports.
Then a tester can check the mail every so often, try and repro the 
alleged bugs, and if they actually are bugs the tester can enter then in 
the tracker.

IMO why bother?  We don't want random bugs from random Joe Publics. 
They will be more trouble than they're worth.

This is a community project; what we want is bugs from our community of 
users, who will be playing with/using PIW as we develop it and will not 
have an issue registering with the tracker so that they can contribute 
bugs.  In fact it will be part of their 'membership' in or 'buy-in' to 
the project that they are registered.

I definitely don't support anonymous users entering bugs directly into 
the issue tracker.

It's a security risk, a spam-bug risk, and most simply an invitation to 
get tons of really crappy bugs that probably aren't even bugs clogging 
up the tracker, with no way to enact consequences on the offending users.

Also no way to assign it back to them for regression after a fix is made.

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