Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] Progress report and stuff

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Stephanie Gerson <sgerson@stanfordalumni.org>
  • To: <john@eco-living.net>, Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Cc:
  • Subject: Re: [pcplantdb] Progress report and stuff
  • Date: Sun, 06 Feb 2005 19:57:14 -0800

I COMPLETELY agree, thank you Johns!

FYI I am working on the Phase 1 spec, Progress Report for Threshold, and
current list of tasks. Will (hopefully) send them out tomorrow night.
But please pick up on this discussion...

peace
*Stephanie

------ Original Message ------
Received: 12:20 AM PST, 02/05/2005
From: John Schinnerer <john@eco-living.net>
To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
Subject: Re: [pcplantdb] Progress report and stuff

Aloha,

I repeat - we still don't have even a rudimentary formal spec and/or
requirements definition of any kind whatsoever nohow nowhere no siree.

IMO this is most current task #1, #2 and #3 at the moment.

Otherwise we are just hacking and kludging and winging it, not designing.

That would be a class one permaculture error, would it not?

So to keep the medium from eating the message, how about some serious
observation and assessment here before we start implementing any more?

A little protracted and thoughtful observation instead of thoughtless
and protracted labor?

I'm not a raging fan of formal documentation either, but given the
relentless onslaught of wishlisting and feature-creeping and spin-offing
and kitchen-sinking I keep seeing here, if we don't nail down an
achievable "phase 1" in reasonably excruciating detail RSN we'll have
little chance of ever completing it (maybe never even starting it...a
constantly moving target is harder to hit...).

Can start by fleshing out some of the following with details.
Helps to start with a functional description.
Element A requires F and G and results in R, etc.
Some off-cuff examples (in a real doc they'd all be multi-level outline
type format, bullet points, lists etc. etc.):

> User input. Getting the system running so that we can start
> accepting contributions. Can break this down into:
> Some form of login/account managment

User interface will provide ability for user to creat an account.
Account creation requires a user name consisting of min. X max. Y
alphanumeric characters from sets [A-Z][a-z][0-9]
Account creation requires a user password consisting of min. X max. Y
alphanumeric character from sets [A-Z][a-z][0-9][!@#$%&*_-=+]
Account creation is accomplished using a GUI form with a field for
user name entry, a field for password entry, a field for password
verification and a form submission button.
Submission step one includes validating the user name, validating the
password, validating that password matches password confiramtion field.
Submission step two passes the valid user name and password to the
user account creation function/method/routine and verifies no errors
were raised in creation.
Yada yada....

> Working out database schema to allow user input.

Working out database schema, period, at this point.
DB schema not my table, someone with chops there please give an
example...

User input provides ability for registered user with adequate
permissions [there's another whole section, permission levels for
users...which depends on scheme for data vetting/validation, moderation,
'hard' data vs. anecdotes and comments being nailed down] to add to
and/or modify information in the database.
Adding data is done using a GUI form providing text fields,
drop-lists, selection lists, etc. as required for type of data to be
added.
Selecting the "add data" function validates user permissions and
requests login/registration if user is anonymous.
If user is not authorized to add they are notified of this and no
action is taken.
If user is authorized to add, the intial "add data"
method/function/routine is called.
Next level of "add data" spec goes here...
Selecting the "edit data" function validates user permissions and
requests login/registration if user is anonymous.
If user is not authorized to edit they are notified of this and no
action is taken.
If user is authorized to edidt the intial "edit data"
method/function/routine is called.
Next level of "edit data" spec goes here...

There is a lot to do here. Good news is that with a good spec/req. def.
the coding suddenly gets easier because "what to do" is laid out and
mostly it's down to "how to do it" rather than both at once.

Of course this is a recursive/cyclical process and some "how to do it"
may lead us back to "what to do," that's fine.
We have to start somewhere though, and that's with the alpha of "what to
do."

> Decide on what we do, and stick with it.

VERY *VERY* MUCH AGREE.

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
_______________________________________________
pcplantdb mailing list
pcplantdb@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/pcplantdb




+++++++++++++++
Stephanie Gerson
sgerson@stanfordalumni.org
(c) 415.871.5683


____________________________________________________________________






Archive powered by MHonArc 2.6.24.

Top of Page