pcplantdb

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

Aloha,

> Agreed, but how to build that spec?

Just get on with it.
Start a draft document in a CVS and take group input/edits and hash 
through it.
So far the only reason I haven't done a draft is I don't have time to 
make it a priority.  Won't any time soon either. I could contribute but 
can't drive it at present.

> The way I'd like to do it is:
>     Have a "feature request" Type in issue tracker.

I put 'suggestion' type in for that purpose, basically - an 'all comers' 
opportunity to make suggestions (which would in some cases equal a 
feature request).

I can add 'feature request' - *and* there's no way to prevent our 
general public (when tracker is available to them) from flooding us with 
"feature requests" that we would then have to deal with as you suggest:

>     Submit all the things we want.
>
>     Have pissing matches over priorities. Hopefully the
>     Severity/Priority fields will rapidly change until
>     we arive at group consensus.

And if they don't?  What's our process then?

>     When happy could promote the Type to "Accepted Feature Request"

Who is in charge of this promotion?  Pissing match consensus again?

And, there's no way to prevent someone entering something brand new and 
selecting type 'accepted feature request' right from the start. Then what?

>     These "Accepted Feature Requests" form the spec!

As a pre-development process in a core-group issue tracker space it 
might work out OK.

As an in-development process in what is intended to be a public issue 
tracker space, I don't favor it.

>     This is an effective way to negotiate among the members.

I disagree.  On this list, I get everyone's messages and when I reply 
everyone gets that.

In the tracker, if I'm not on the notify list for a particular issue I 
don't get any messages about it, and I have to constantly browse through 
issues manually to see what's going on.  Once there are lots of issues 
that is highly inefficient.

If everyone here is on the notify list for every 'feature request', in 
order to form some kind of consensus, the issue tracker becomes an 
inefficient and clumsy downgrade from a simple and elegant listserv like 
this.

> True we do lack formal project management or spec.

I would like to hear from Stephanie on this, and, I would guess that at 
some point this will bite us in the backside when some promising and 
otherwise supportive funder(s) see that we really haven't done our most 
basic groundwork/homework and can't even provide documents clearly 
indicating what the heck we're actually planning to do, or when, or how.

If this were a business venture, we wouldn't have a snowball's chance in 
hell of getting any investors with no specs, no organizational 
structure, no nothing formal to present.

Why would grantors accept less?

> Nice explenation of typical design process. Seems like its whats
> happening.

No - I entered a bug and then Chad arbitrarily changed it based on his 
opinion and now you've done the same.  There is no design process, just 
anarchy.  Not that I have anything against anarchy in appropriate 
contexts.  However I don't think this is such a context so I don't think 
it will work very well.

> Personally I've a tendancy towards consensus.
> Unsure about a hierarcal system.

Consensus is a fine option, and, we'd need to formalize it.  Tossing 
around some ideas etc. etc. is not consensus.

> So far there are 5 users. Does it require greater structure?

I think so.

> (Steph/Lawerence have you signed up yet?)

Not yet they haven't.  Stehphanie had some kind of problem, not sure 
what - she sent me an error traceback which I forwarded to John H - need 
to talk with her about what she did and what happened when/where/how. 
Can't tell from just the traceback.

> Really do think alot of these discussions can should be taking place on 
> issue traker. It will help keep us focused. Which is one advantage over
> mailing list.

See comments above.  Unless everyone is on notify list for every 
relevant issue it's not a group discussion unless everyone constantly 
browses issues manually to read comments, which is not nearly as 
efficient as a listserv.
If everyone *is* on notify list, it's more or less like this venue but 
also a bunch of extra overhead in the tracker.

As I already mentioned, I think a good threaded online forum would be 
better than listserv or tracker for these kinds of discussions.

Better than listserv because threaded forum front end is easier to 
navigate than list archives.

Better than tracker because, in case I haven't said this enough times 
already, an issue tracker is neither a listserv nor a discussion forum - 
it is a mechanism for tracking relatively formalized and structured bits 
of information such as 'bugs', 'suggestions', 'tasks' and so on.

> As to formal spec, I don't think were there yet. I see the stuff
> Chad's doing as more R&D which needs to be a bit more open ended.

I think we've already tossed out most of a basic func spec here over the 
months; it's just never been collated in one place/document so it could 
be prioritized and worked from.

Chad's search engine innards/optimizations and the like may well be R&D.
And there's always multiple ways to implement a particular function as well.
I'm not talking about the 'how,' I'm talking about the basic 'what'.

Chad may want to experiment (R&D) with various ways to implement user 
registration and management.
That doesn't change the fact that a basic function we will implement is 
user registration and management.
So the spec says there will be user registration and management - that 
doesn't tie us to a particular way of doing it, it just says clearly 
that we will do it.
And so on for all other functionality.

One most basic reason for a spec is so there is some basis for 
structured testing.  With no func spec, all testing is ad 
hoc/unstructured.  Ad hoc testing is valuable and has its place, but 
when 100% of testing is ad hoc a project has some serious problems in my 
experience.

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