pcplantdb

[Chad Knepp <pyg@galatea.org>]

Stephanie Gerson writes,
 > Phew, lots of activity in the past 2 days!

Heck ya!  This is the first time ever that pcplantdb postings
outnumberd nafex in my box.

 > Once again, I=E2=80=99m gonna try to round everything up:
 >
 ><snip> 
 > 
 > -Lawrence asked that someone list and define the various licenses.  Which=
 >  =
 > 
 > one(s) would be best for HG and why?  Wonderful idea.  Who wants to take =
 > 
 > this on?  Does anyone already know anything about licenses or have a =
 > 
 > strong preference?  (Please, someone step up.)

Sure.  On July 2nd Richard Morris writes,
 > Chad Knepp wrote:
 > > If we use the PFAF dataset we will probably have to use the BY-NC-SA
 > > unless we can convince PFAF to drop the NC.  The reason I don't think
 > > that the non-commercial clause is important is that if you are already
 > > providing the data in a free form no one needs to purchase commercial
 > > versions to get the information.  If someone wants to publish a book
 > > with the information I think it is a win-win situation.  They may make
 > > a little money on it, but having the information in a format we can't
 > > provide is a good thing for people that want to read a book with their
 > > breakfast and not bang on a keyboard.  The only sticky situation I can
 > > foresee that not having the NC clause could lead to is if someone took
 > > the information and added additional but proprietary information and
 > > then sold it... kind of like the PFAF data with images.  I don't think
 > > this would ever happen because if we have the entire permaculture
 > > community collaborating on it we would have a lock on all the good
 > > sources of information anyway.  This is also why we don't have to buy
 > > the PFAF images, because I'm certain people will start taking pictures
 > > and uploading them as soon as we make it possible.
 > 
 > I think we (pfaf) would like to keep NC in there. If there is a
 > need for a comercial use then its posible for the data set to
 > be licence under a different license say BY-SA.
 > 
 > > I think the GPL is a very good license for code with an excellent
 > > legal track record.  It wasn't really designed to cover other sorts of
 > > information so I think the data should be under either the LGPL or GPL
 > > documentation license or something else.  Since the PFAF dataset is
 > > under a CC license and we are potentially going to incorporate it, it
 > > would be very straight forward to use that.
 > > 
 > > One thing that hasn't been mentioned that I will say for the sake of
 > > thoroughness is the possibility of allowing the authors themselves to
 > > choose the sort of license they would like and offer a selection of
 > > licenses.  This is actually the direction I was going with PCPDB but I
 > > think this is a bad idea because of the amount of internal accounting
 > > it would require in addition to the complexity of having a given
 > > object licensed under multiple licenses.  An appropriate display of
 > > copyright would require us to show each and every license, possibly
 > > having more info about copyright than the plants or whatever.  I also
 > > think that if we pick a reasonable license that folks will have no
 > > problem agreeing to contribute under it.
 > > 
 > Could be good.
 > 
 > > Another thing for the sake of thoroughness is that the GPL isn't
 > > always compatible with non-free libraries and toolsets.  This will not
 > > be a problem for me because I don't intend to use any non-free
 > > products.  It is my understanding that the most everyone was on board
 > > with the idea of only using free software.
 > > 
 > > So I propose that we consense on the following:
 > > 
 > >   Our project [HG] will license the code under the CC-GPL and the
 > >   dataset under the CC-BY-NC-SA.
 > 
 > > So what do you all think?  Now would be a good time to hear any
 > > additional concerns or comments you may have.
 > 
 > Agree completly.

Today, Richard Morris writes,
 > John Schinnerer wrote:
 > > 
 > > Chad:
 > >>I've brought up the issue about what license(s) we are going
 > >>to use twice and I didn't get much of a response except from Richard.
 > > 
 > > 
 > > I replied on this already also - GPL or functional equivalent is fine 
 > > with
 > > me for code, and I defer ("neutral" I take that to mean) to those with
 > > more knowledge of data licenses to make that decision - as long as it's
 > > "free" in the same way the GPL makes the code "free."
 > 
 > I've been looking at quite what the GPL "free" means.
 > 
 > 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)?
 > 
 > so basically GPL "free" means its OK for someone to take the
 > dataset put it on their advertising website and make money off it
 > (with none going back to the project). This has happened already
 > see GardenBed.com.

Well, I did check out gadenbed.com and apart from being a completely
sucky site I'm not sure what I'm supposed to notice.

Yes, people can take and *publish* free/copylefted information and
charge money for the act of publishing (depending on the license).
They can also keep this money for themselves.  If someone writes a
better interface to your data and charges for the interface I don't
see anything wrong with it.  However, if they are modifying the
dataset and not freely publishing the modifications they are probably
in violation... specifically the SA clause of the CC-BY-NC-SA.

I don't think the CC license violates any SF policy.  They are
probably referring to restrictions that would disallow any/reasonable
use by commercial entities.

Today, Richard Morris writes,
 ><snip>
 > !! Implications for pcplantdb
 > 
 > 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.
 
 > No-Commercial - not a "free" license as we place a restriction on use. 
 > But it would restrict practices such as taking the dataset
 > and putting it on an advertising driven website.
 > 
 > If we do not go with NC then pfaf will very likely incorperate
 > additional data back into main pfaf dataset and distribute it on CD
 > for profit. Might actually prevent forking of dataset.

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.

 > Share-Alike - derivative work must be under same license,
 > i.e. if we go with CC-BY-NC-SA then derivative work must be released 
 > under CC-BY-NC-SA. If we go with CC-BY-SA then derivative work much be 
 > CC-BY-SA. Can't really mix the two.
 > 
 > A lot has to do with how pfaf decide to release its dataset as
 > pcplantdb could be considered a derivative work and the CC-SA clause
 > means pcplantdb HAS to use the same license.

Not exactly, the copyright holder decides what license to release
under and can change licenses at will (not retroactively though).
This only becomes an issue when the copyright holder is multiple
entities.  From this another implication about HG is that with
multiple authors/copyright holders, a change in the license would
require everyones agreement... or if we did actually keep record of
every specific edit/contribution by everyone if we did feel we needed
to change the license we could remove the contributions of resistant
authors.  The possibility of needing a license change are so small I
don't feel the effort is worth it.  It does mean that we need to think
carefully about the choice of license though.  There are two possible
scenarios where I can envision a need to change the license.  One, we
decide to try and sell a non-free product... over my dead body.  Two,
the license we choose encounters legal problems in the future.  I feel
great about the GPL in terms of legal stability and good about the
CC-BY-NC-SA (it's just really new).

 > -Thanks for your comments on the group process, Chad.  Lawrence suggested=
 >  =
 > 
 > that others on the list introduce themselves and let us know how they =
 > 
 > want to be involved with the project over time.  So this is to all yalls =
 > 
 > we haven=E2=80=99t heard much from =E2=80=93 can you please introduce you=
 > rselves?  =
 > 
 > (Umm...are you even reading this?  Maybe I'll post a separate message =
 > 
 > with "hey YOU" as the subject...)

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.
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.
I've spent the last four years living in various consensus decision
making communities and although I personally believe in the process, I
think its effectiveness is limited to small relatively homogeneous
groups or larger diverse groups with gobs of time and an insatiable
lust for meetings;-) 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.

 > -Thanks for the name suggestions, Lawrence =E2=80=93 did you add them to =
 > the =
 > 
 > wiki?  To me, this project is about relationships between plants (how =
 > 
 > many times have I said this) - so I would like to incorporate that in the=
 >  =
 > 
 > name.  And not to be bratty, but all the names suggested so far are =
 > 
 > pretty boring. It can be straightforward, but clever, n'est ce pas?  I=E2=
 > =80=99ll =
 > 
 > think about it. =
 > 
 > 
 > -Someone asked, =E2=80=9CBut is a comprehensive permaculture database the=
 >  goal of =
 > 
 > this project? Stephanie?=E2=80=9D  Not what we got funded to do.  This so=
 > unds =
 > 
 > like Lawrence=E2=80=99s ultimate goal.  HG is specifically about creating=
 >  a =
 > 
 > database of information regarding relationships between flora.  If it =
 > 
 > grows to be a comprehensive permaculture database (as part of Lawrence=E2=
 > =80=99s =
 > 
 > larger intents), that would be ideal!  But that=E2=80=99s not the goal of=
 >  this =
 > 
 > particular project, at least not at this point.

Not just Lawrence.  I'm in this because I think it can go a lot
farther than plants.  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.

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.  I was assuming
people weren't opposed to me doing more than the grant specified on my
own?

 > <snip>

 > Project Calendar
 > 
 > 
 > Notes:
 >     . Tasks are listed by week (the week during which they should be
 >       completed)
 >     . Tasks are "due" on the Sunday at the end of the week (i.e. tasks for
 >       week of July 25-31 are due Sunday, August 1st) - this is not fixed, I
 >       understand that there is contingency involved
 >     . Every Sunday, everyone involved in the project should send an update
 >       to the group, describing task status and sending any completed work 
 > to
 >       share
 >     . Every Monday, everyone should respond (if necessary) to whatever team
 >       members sent out on Sunday (the day before)
 >     . This calendar is simply a tool to assist with our project process, 
 > and
 >       it is flexible!
 >     . Please notify me if you need to shift deadlines around
 >     . If team member is not specified in task, then the task is the
 >       responsibility of all team members (i.e. respond to project plan is a
 >       task for everyone)
 >     . I will send reminder emails each week (or, more frequently if
 >       necessary) reminding everyone of their tasks
 > 
 > 
 > Until July 24
 > 
 >     . Stephanie - create initial project plan
 >     . All participants respond to project plan, making
 >       comments/edits/suggestions
 > 
 > Week 1: July 25-31
 >     . Agree on common vision (clarify importance of user-interface) - I 
 > will
 >       initiate a dialogue about this and all should respond
 >     . Learn about SCRUM
 >       (http://dotnetjunkies.com/WebLog/darrell.norton/articles/3910.aspx)
 >       and respond if you are interested in using it

There are lots of ways to manage projects.  Something else that is
currently popular is called Extreme Prgraming
<http://www.extremeprogramming.org/>.  I'm down with just about
anything that really is a net gain in productivity.  We are such a
small project though, I'm not sure about this.

 >     . Use wiki to make decisions (including type of license, name, non-
 >       profit status, plant attributes, logistics of shared web workspace) -
 >       I will post decisions that need to be made
 >     . Stephanie
 >          o look into project management software and learn one if need be

As above.  I don't think it's worth your time, although it may be a
valuable skill to acquire.

 >          o initiate dialogue about common vision regarding user-interface
 >          o post decisions that need to be made on wiki
 > 
 > 
 > Week 2: August 1-7
 > 
 >     . Whoever is in charge of shared web workspace (as determined Week 1)
 >       creates it

Sounds like this is done.

 >     . Chad and Rich
 >          o a working database (with no real data) with php connection and
 >            simple front end (basically just checking that the different
 >            bits can work together)

This sounds like 1 of my plan.  I think this is all me.

 >          o issue tracker working, cvs working, zope working
 >     . Stephanie
 >          o write first draft of email describing project to PC lists, sends
 >            to team for feedback
 >          o write up description user interface/experience, send to list
 >          o re-create project plan with new project management software, if
 >            need be
 >     . Lawrence
 >          o write a clear description of relationship between
 >            PCKnowledgebase and HG (if separate entities)
 >     . John
 >          o set up issue tracking system and whatever
 >            data/parameters/customizations are necessary to start using it
 >            on our project
 >     . Paula
 >          o Send info about her work to the list
 > 
 > 
 > Week 3: August 8-14
 > 
 >     . Respond to Stephanie's draft of PC email
 >     . Respond to Stephanie's description of user interface/experience
 >     . Respond to Stephanie's vision for user interface
 >     . Chad and Rich
 >          o Sample plant info added to database, simple query (maybe just
 >            query by Latin name) and simple plant report
 >          o Facility to append info to plant, and add a new plant
 >          o Go back to rethink/evaluate former 2 steps, come up with some
 >            sort of DB-schema
 >          o communicate with Paula about how to get database information in
 >            usable form
 >     . Stephanie
 >          o Edit email to PC lists and send
 >          o Edit user interface/experience incorporating feedback from team,
 >            send back out
 >     . John
 >          o prepares and posts FAQs and other documentation on use of issue
 >            tracker and general software test/QA procedures and guidelines
 > 
 > 
 > Week 4: August 15-21
 > 
 >     . Chad and Rich
 >          o import PFAF dataset
 >          o Import Paula's dataset
 >          o work on queries/frontend

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.  If you are worried about the 40 hour
estimate for importing I think it could be a lot less.  

So this pretty much approximates 1, 2, and 3 of my plan.  The
complicated part is that I estimated 200 hours for them combined.  I
have also stated I would only be able to put in 20-30 hours a week for
the next couple of months.  Although in my head this estimate was
formulated as not more than 200 hours, I don't think it could possibly
be less 100 hours.  Also Paula's data wasn't in this estimate.
Hmmmm.... I think this is where I head for the phone both.

 >     . Stephanie
 >          o Compiling and keeping track of feedback from PC lists
 >          o Incorporating feedback into description of user
 >            interface/experience
 > 
 > 
 > Week 5: August 22-28
 > 
 >     . Chad and Rich
 >          o Testing, re-iterating

This is John actually.  I will gladly fix all the bugs though.

 >          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.

 >     . Stephanie
 >          o synthesizes feedback from PC lists, sends to group
 >          o if necessary, drafts another email for PC lists, asking more
 >            specific questions
 >     . John
 >          o Manage test/QA process and issue tracker
 >          o Test HG releases and coordinate efforts of community/volunteer
 >            testers
 > 
 > 
 > Week 6: August 29-September 4
 > 
 >     . Chad and Rich
 >          o Testing, re-iterating

John.

 > 
 > Week 7: September 5-11
 > 
 >     . John
 >          o Compiles results from user testing, sends to group
 >     . Chad and Rich
 >          o Incorporate results from user testing, re-iteration
 > 
 > Week 8: September 12-18
 > 
 > Week 9: September 19-25
 > 
 > Week 10: September 26-October 2

Pretty much a month of slop time.

 > Week 11: October 3-9
 >     . Stephanie
 >          o Write proposal to Whole Systems Foundation (include functioning
 >            component)

I think it would be good to start talking about this well ahead of
time to get a good sense of the groups goals and direction.

 > Week 12: October 10-16
 > 
 >    . Whole Systems Foundation grant proposal due October 15

I'm sure we can have something neat up by the time they look at it.  I
doubt anyone will actually read the proposal before November.

Coolness!

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'