Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] [mini-synthesis][36][5.17.05]

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: John Schinnerer <john@eco-living.net>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] [mini-synthesis][36][5.17.05]
  • Date: Thu, 19 May 2005 23:08:47 +0000

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




Archive powered by MHonArc 2.6.24.

Top of Page