pcplantdb

[Richard Morris <webmaster@pfaf.org>]

John Schinnerer wrote:
> Aloha,
>
> > -Johns wrote, "Re 2), until we know more precisely what we are 
> > building and how it is supposed to work, opening testing up to others 
> > is most likely to result in a lot of static and clutter in the 
> > tracker."  Is this becoming clearer with the Wiki?  Or is there some 
> > other process we should engage in, doc we should create?  Or just meet 
> > up at Chad's ;)
>
>
> I will momentarily post an example of what looks like a well-structured, 
> well-organized and prioritized open source project launch announcement. 
>  Their primary first steps after general goals and ideas discussions 
> such as we have already had are to design an architecture, write specs, 
> and validate their specs...before even worrying about a single line of 
> code.

My worry is that time is begining to tick very fast. We have until end 
of sept to get something up and running.
> I think perhaps I am simply too structure-oriented for the PIW project.
>
> > -Speaking of tasks, would you like me to send out a task list or do 
> > you feel comfortable with what you're currently working on?  PLEASE 
> > RESPOND.
>
>
> How about using the issue tracker to track tasks?
> I specifically supplied an issue type of 'task' for this purpose, as 
> requested.
>
> > And send me individual updates por favor.
>
>
> I was planning to start doing some docs for testing and the issue 
> tracker (actually made a small start on some flow diagrams Tuesday).
>
> At this point I first want some group sorting-out of the disagreements 
> between myself and Rich about user community/testing/tracker issues.
>
> I personally want a well-structured testing and issue-tracking 
> environment for this project, and I want user/project community input 
> for QA and testing to make maximum use of same.
>
> A web forum, wiki, blog or similar free-form text entry environment does 
> not meet this criteria for me.
>
> I am hearing Rich say that most likely few in our user/project community 
> will use the tracker if they have to register, and that we should 
> provide some anonymous way for any and all comers to submit 'bugs', and 
> that this might be through a web forum, wiki, blog or similar.

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

> As I have put a lot of effort into generating the issue tracker, I am 
> frankly pissed to hear that we ought not require user/community members 
> to use it for what I thought it was intended for.
I must say I'm confused here. I'm picking up from other post
some reluctance to having bug submission from the general public.

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

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

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

2) Who can have read access to the bugs.
3) Who can modify bugs, change atributes, etc.

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
        f) compiling a list of persistant checks/tests which need
                to be carried out for each release.

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.

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

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

7) What needs to be recorded:
        Browser version
        Any error message generated
        Version of the system being used
        Milestone or release task/suggestion/bug should be compleated by.
        URL of page

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

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.

10) How does it cope with duplicate bug reports?

Rich