Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] Bug DB, specs, project management

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] Bug DB, specs, project management
  • Date: Fri, 15 Apr 2005 20:44:48 +0000

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




Archive powered by MHonArc 2.6.24.

Top of Page