pcplantdb

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

Aloha,

Hitting a variety of stuff here...

>  > I'm halfway through trying the register with sourceforge
>  > and one their admin replied
>  >  > 2. What is the license text being used for the content (do
>  >  > note that if the license restricts commercial use, it will
>  >  > not meet our hosting standards)?

Sourceforge is one option - we don't *have* to put our codebase there.  If
ibiblio doesn't already have a CVS running perhaps they could add it to
their portfolio with us as the first users.

>  > Atribution - basically means we have to record who has contributed.
>  > Could become tricky if lots of people start contributing. How do we
>  > record who did what? An easy solution is to put a list of contributors
>  > at the end of each page.
>
> Yes, I've discussed this issue before and the tradeoffs of doing it
> the easy way or recording individual edits.  I currently lean in favor
> of the easy way.

Tracking might be easy.  Zope already does this in its undo feature -
every change to an object (including programmatic changes, not just TTW
via the zope web mgmt. UI changes) is tracked for undo purposes (until the
DB is 'packed' or the undos manually purged etc.) and the tracking
includes info on which user made the change and when.
So if only logged-in registered users are allowed to add and edit and etc.
the undo info will already provide change tracking info (object changed,
user name and date+time).  This data is presumably available to grab from
the undo mechanism and stash in/with the object, if we wanted to.

> Totally, except that HG will not be in a relational database format
> which will make back porting the data interesting.  In Eden, I've kept
> what I call PFAF_legacy_names, the original primary keys of PFAF,
> specifically for the possibility of importing new data from PFAF.
> Eden uses a numerical primary key and the family, genus, species, and
> var/ssp are all atomic elements.  Anyway, I think we can easily retain
> a common key to make cross porting easier.

I was also wondering about exactly what the "data set" will be in our
project.  It will be the data stored in object attributes...as Chad says,
not at all like RDB tables, neither conceptually nor in practice.
An object DB query and some scripting could produce RDB-like output of
"everything" (all attributes from all objects in the DB) though, or so I
imagine...?

License stuff...ahhh, my head hurts...what about the No Derivative option?
Does that fit in somehow?

> I've had some more thoughts about our process based on comments people
> have been making about keeping parts of the list open or closed.  My
> personal preference is that all elements of the list should be open.

Agree.

> That said I think that the group that makes decisions about the
> project should be defined and closed although I think it should be
> open to input from the list and the larger permaculture community.

Agree.  The few open source projects I've lurked on, that's how it seems
to work in practice anyhow.  There may be lots of input and even
discussion, and ultimately the people most involved and knowledgeable make
the "final" decisions.

> Community, diversity, and consensus is a very
> *up* issue for me personally and I've been planning to write an
> article for Communities Mag. about diversity and community including a
> new social model for community structure that specifically addresses
> and embraces/accommodates the aspects of difference within a
> community... ok, now I'm off topic.

Maybe, and please do write that article, I'd look forward to reading it.

> Not just Lawrence.  I'm in this because I think it can go a lot
> farther than plants.

Me too - and, I support staying focused on plants as
1) a good place to start
2) what newbie permies (and old-timers too) always want "the book that
doesn't yet exist" about - in other words, the info we're intending to
provide.


> Because of this I think that using plants in the
> name is a bit short sited.  Why choose a name that when in a year from
> now we will (generous foundations willing) be adding animals,
> articles, and garden logs or whatever.  Sure we are starting small but
> let's keep thinking big.

OTOH we can always change the name and/or switch domains and/or add
subdomains - a variety of options for modular expansion I think...let's
just not get stuck on finding the "perfect" name; that will probably be as
elusive as finding the "perfect" plant object design right from the start!

> I've also said before that I would be interested in adding features
> that I want but aren't in the written in grant or the will of the
> whole group on my own time.  It would be pretty easy to add animals
> and insects to the initial database and it would look pretty neat in
> the GBI to see lettuce --> slug --> duck or something.

Yeah!

> I was assuming
> people weren't opposed to me doing more than the grant specified on my
> own?

Not me!


>  > Project Calendar

I'm snipping all but a few parts I comment on...

>  > Week 2: August 1-7
>  >
>  >     . Whoever is in charge of shared web workspace (as determined Week
> 1)
>  >       creates it
>
> Sounds like this is done.

The wiki you mean?
Or does "shared web workspace" include more than that?

> I really think it makes more sense to switch this with the week of Aug
> 8-14.  Creating dummy data is for testing is just wasted time when you
> have real data available.

Except for testing "create new," which has to be stuff not already in the
DB.  And of course I can use some "real" data from PFAF or wherever.  I
will also use some specific "dummy" data for bounds checking tests and
stuff like that.

>  >     . Chad and Rich
>  >          o Testing, re-iterating
>
> This is John actually.  I will gladly fix all the bugs though.

Oh good!  ;-)
As I said, I will start testing as soon as there's something to test.
Not sure if unit testing even applies here...we'll see, and I'd leave that
to Chad and Rich, if there are in fact any bits of the first alpha code
that can be tested separately from other bits.

>  >          o  agreement/design of server-client interface
>
> This needs to be done way earlier unless you mean agreement/design of
> *non-trivial* server-client interface.

I think we're talking about the API design here, right?  If so, yes, needs
to be part of designing from the beginning.

>  >     . John
>  >          o Manage test/QA process and issue tracker
>  >          o Test HG releases and coordinate efforts of
> community/volunteer testers

Community/volunteer testing will start when we have some version of
something that we deem "ready" for others besides ourselves to poke at.
I hereby appoint myself primary judge of that, since besides lotsa testing
work, I've done lots of user support/handholding work.
Before that it will be just "we few, we lucky few..." testing.
Once we have something user-friendly and non-fragile enough we can let the
larger community poke at it...

>  > Week 7: September 5-11
>  >
>  >     . John
>  >          o Compiles results from user testing, sends to group
>  >     . Chad and Rich

The issue tracker will be available to any of us who wants to run some
queries to see what's going well and what needs more work, etc.
What the above means will become more obvious once we have the tracker up
and a bunch of issues in it, especially for those who've never used one
before.
And of course I can provide some summaries from time to time or at
whatever we deem to be "critial" points.

I'm guessing by "user testing" you mean either "users testing
functionality" (a.k.a. functional testing) or "usability testing," which
means "real users" feeding back to us on how *usable* it is for *them* -
which is *not* the same as whether it works at all or not or how usable
*we* think it is!
Which do you mean in this case?



John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net