pcplantdb

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

Aloha,

> My worry is that time is begining to tick very fast. We have until end 
> of sept to get something up and running.

Time isn't ticking any faster than it has been all along.

And it appears to me we do have something up and running...it may not 
impress us, since we've seen it for quite a while, but even what we have 
now might be a fairly big deal to those who've barely or never seen it.

> I'm just offering my experience from two other projects, and a
> worry that requiring registration will limit input.

I'm looking at projects like Mozilla, and Apache, major long-running and 
apparently well-supported projects where user registration is required 
for bug entry and considerable guidance is supplied (and emphasized) to 
user/community members who want to support QA/test efforts. See:

http://www.mozilla.org/quality/bug-writing-guidelines.html

and

http://httpd.apache.org/bug_report.html

...for more details.

This is in general what I have been envisioning, and assuming we were 
implementing, for the user/community QA/test effort for PIW as well.

I am also advocating this because I have years of experience in QA/test 
in commercial software biz and I am wanting 'best practices' that I am 
familiar with to be available for and applied to this project.

> I must say I'm confused here. I'm picking up from other post
> some reluctance to having bug submission from the general public.

I welcome submissions from any interested users who want to contribute 
to QA/test, as long as they are willing to be a registered user of the 
issue tracker.

What I do *not* support is *anonymous* bug entry in the issue tracker.

> My sugestion about the forum was intended as a why round this perceived 
> problem.

Fine with me as long as someone is going to deal with the extra overhead 
of extracting bug reports from forum posts, verifying them as legit 
reproducible bugs, and getting them into the tracker.  I am not 
interested in doing that.

> Maybe we need to start the detailed spec with the issue tracker.
> This could be a good example to other branches of the project to follow.
>
> Questions like
>
> 1) Audience, who can submit a bug or a feature request/suggestion.
>
> Either:
>     a) anonymous users
>     b) anyone who chooses to register
>     c) only those aproved

My choice is b)

> 2) Who can have read access to the bugs.

Everyone, e.g. registered and anonymous users (that's how it is currently).
This enables someone to see if a bug they found is already entered 
*without* having to register.

> 3) Who can modify bugs, change atributes, etc.

At this point, any registered user can add a comment, change status, 
type, priority, etc.

My plan at present would be to leave it this way, on the honor system 
for registered users.
The issue tracker user docs/FAQ will clearly indicate that messing with 
other's bugs or any other spam/hacking/abuse in the tracker is grounds 
for banishment.


> 4) What can issue tracker be used for:
>
>     a) Requests for new features
>     b) Reporting of a bug in production system
>     c) sceduling of tasks - i.e. project mangment
>     d) testing of pre release development (i.e. experimental builds)
>     e) testing of beta releases

All of the above.

>     f) compiling a list of persistant checks/tests which need
>         to be carried out for each release.

These are the test suites and test cases for PIW as a software product.
They would be documents, not tracker items - typically word-processing 
and/or spreadsheet docs viewable and/or downloadable from somewhere 
appropriate (QA/test section of the wiki for example).

If we have a well-fleshed-out spec, the purely funcitonal test suites 
and test cases usually follow readily from that.

Browser compatibility is typcially a matrix of OS and browser combos 
combined with test cases relevant to compatibility issues.

> If its not to be used for one of the above, what alternative system 
> should be used.
>
> 4a) What should the tracker not be used for.

See above on test suites/cases.

> 5) For each of the above what are the typical life cycle of an issue.

Flow diagrams with accompanying text description would be created for these.

> 6) Does the issue tracker represent all the stage in development.

I don't follow that...?

> 7) What needs to be recorded:
>     Browser version
>     Any error message generated

Yep...

>     Version of the system being used

This is the build field.

>     Milestone or release task/suggestion/bug should be compleated by.

For bugs and suggestions, the relative urgency of the issue is indicated 
by the priority field.

For tasks, could be a date, release or milestone, depending on nature of 
task - would go in title and/or comment.

>     URL of page
>
> (Thought, having seperate fields for some of these might be good).

Some already are, as mentioned above (build; priority).

Others could be, or could simply be part of the description field text 
entry.

> 8) Guidlines for alowable usage. Thinking of something along the lines 
> of the bugzilla etiquete
>     http://bugzilla.mozilla.org/page.cgi?id=etiquette.html
>     https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html
> Might even be able to use these direct with a few changes.
>
> 9) At what milestone will issue tracker move from development to 
> production.

Don't follow...?
Tracker can be used for both development and production builds, as long 
as there are distinct build IDs for each available in the 'build' field 
selections.

> 10) How does it cope with duplicate bug reports?

It's up to us humans to spot the dupes. When someone spots a duplicate 
they verify it's a dupe, note it as such in 'superseder' field and 
possibly in comment field, and close it.

Main question for me is:

Do we tell our user-community that bugs go in the tracker and so please 
register and contribute (as with Mozilla, Apache, etc. projects), or do 
we do something else?

If the former, then I am prepared to continue with testing/tracker 
documentation; otherwise not.

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