permaculture

[Niels Corfield <mudguard@gmail.com>]

Lawrence and others,

I agree with your sentiments on urgency, whole-heartedly and it is good 
to hear folk using this language.

I have deleted all content of previous post and should probably 
summarise all previous comments but for now I will add Rich's mail at 
the foot, seeing as it is so thorough.

But for now try to summarize and start a new thread.
And ask some questions of the group/list.

*Aggenda Setting *

   * What are goals?
   * Do we share any common goals?
   * If so perhaps we could brainstorm these and compile to a list, as
     a precursor to a "public/permacommunity consultation"
   * Where and how to have this consultation? When are we satisfied it
     is complete? Magazines, gatherings, lists, wiki etc.
   * How to collate potentially disparate findings from differnt sources?

*Development Skills, Team *

   * are there people wanting/prepared to offer development skills for
     the job?
   * Of those people who has time, who doesn't but could if funds were
     found?

*Funding*

   * how to fund/support project/team?
   * Is this an issue?
   * Should we make it a goal to have set-up a semi-permanent team for
     develoment?

*Project Management*

   * should this be handled separately from the development?


Any additions, perhaps folk could reformat same body text when replying?

BTW, who is Diana?

ATB,
N*




A lot is going to depend on the level of coding you want to engage with
you could
a. Write everything yourself using php/mysql.
   +ve very configurable
   -ve lots of development time needed, in depth knowledge required
b. Use a framework or Content Management ssystem like Plone, Ruby on Rails
   +ve configurable, stable code base for things like user login
   -ve needs some study to get to grips with the framework
c. Use and modify mature programs like mediawiki
   +ve easy to get up and running fast
   -ve may limit methods of contribution/look and feel

Personally I've always gone with a. as its most fun, although I've been
tempted by Ruby on Rails.

See
http://en.wikipedia.org/wiki/Category:Web_application_frameworks
http://en.wikipedia.org/wiki/Category:Open_source_content_management_systems

Interaction
-----------

Its worth thinking about how people want to contribute

a) Adding comments.
   This is what I've used on the pfaf site. Basically people can add a
short comment to any page on the site. I've found this to be very
successful and we are getting about 10 contributions a day. Its the
simplest way for people to interact and does not have any learning
curve. It may be necessary to moderate comments to prevent spam.

b) Adding images.
   This should not be too difficult to implement. Basically all you need
to do is handle a file upload, save the image in a file and use a table
to store the file location and meta data. Some checking of images may be
necessary.

c) Adding other documents. (PD F's, word docs)
   Much like images. May work well for PC designers who are likely to be
producing documents in other formats.

d) Adding links.
   I guess this would be popular: I'm always getting email requests for
links to be added. Works much like a comment although you need to check
for valid URL's and spam prevention measures.
I've a quasi released link submission system at
   http://www.pfaf.org/links/addlink.php
which has some form of tagging. I'm hoping to build a distruted links
system whenever I get the time.

e) Discussion forum.
   Actually integrating a discussion forum into the association website,
rather than as an external site would be a good step. The most popular
system is PHP-BB which I personally dislike. I don't like to look and
feel, all the silly emoticons, the administrative interface and the way
email notification works.

f) tagging
   In some ways this is very simple to do. All that is needed is a table
to hold the tags and the objects they relate to in. I'm not a big fan of
delicious and flicker, they seem to me to be rather closed systems. By
that I mean there is a community of taggers working in the same
environment, to get the most out of it you need to become part of that
comunity. For permaculture we all ready have a community and I feel
overall we should work towards strengthening that community and not
create a separated sub community. Hence more distributed systems feal
more appropriate to me.

g) blogs
   Content is king and I'd love to see some permaculture blogs. There is
plenty of scope for a space for opinion pieces and regular new content
could help gain repeated visitors and get some debates going. It would
be great to see something like a "permaculture site of the week" similar
to Scott's Botanical Links of the day
     http://www.ou.edu/cas/botany-micro/bot-linx/
A bit of work to find people willing to write some quasi-regular pieces,
install and configure the latest software and your away.

h) Wiki's.
   A very big conceptual jump to the rest. To make a wiki work you need at
least 5 active contributers. There is a small learning curve for use the
system, both technologically and sociologically which way deter some
participants. There are only a handful of permaculturalists who have a
fair understanding of the wiki concept, although this could grow.

The following is from an old post of mine to the pcplantdb mailing list,
when in my hyper enthusiastic wiki phase.

MediaWiki
---------

In a wiki each page consists of a simplified form of html with an easier
syntax. It allows headings
== A heading ==
=== A second level heading ===
paragraphs are just made with empty lines. Italic and bold
''italic'', '''bold'''. Lists are marked by a *
* First level list item
** Second level list item

This is all the basic formatting needed for most documents. The syntax
is easier than html so its easier for new users to get involved. A low
barrier  to entry and a shallow learning curve are both very desirable
features.

Fundamental to the wiki philosophy is the idea that anyone can edit the
whole text. This can, and does work well. People have probably noticed
that my posts have a high number of spelling and grammar mistakes, a
wiki is ideal here as others with a better grasp of English than I
can correct all my mistakes. It allows the whole text to improve with
time. On the other hand I tend to be better at things like categorizing
articles, seeking out references etc. In general the process will tend
to improve the article, each new edit tends to make the article better.
If an edit detracts from the article then it is easy for some other
editor to change the article back.

There are several features which help with the process.
(A bit of wiki slang an editor is anyone who edits a page)

Each article also has a talk-page. Here editors can discuss the article
and propose changes, this allows consensus to occur without having the
discussion on the main article. A recent discussion I had on a talk page
led to the construction of a new article.

Registered users can have a watch list. Here changes to any pages which
you have a particular interest in can be recorded. This allows
the user to quickly see what articles have changed and review the
changes. Watchlists are one of the reasons why vandalism is quickly
fixed as the vandalism can be quickly spotted and corrected.

Linking
-------

The wiki model allows easy linking, just include the name of an article
in square brackets: [[Salix alba]] and the article will be linked. Very
easy and probably better than the WikiWord syntax which required
composition of two words with a capital in the middle. Such links are
one directional.

There is also the concept of a category, categories allow a form of
bi-directional links. For example the Permaculture article is a member
of the Sustainable Agriculture category. This is indicated by adding a
link [[Category:Sustainable agriculture]] to the Permaculture article.
Visiting the Sustainable Agriculture category will show all article in
that category. The category system is very flexible, its not a
hierarchal tree more a web of links, as time progresses the set of
categories can alter as more articles are added and categories fill up.
When they get too full a category can usually be split into two or more
sub categories and the articles divided appropriately. Categories can be
members of other categories which allows a topical map to be constructed.

Another mechanism templates is also very powerful. Templates work by a
simple inclusion system, the code in template is just included in the
article using the syntax {{templatename}}. These allow standard messages
to be included. Templates can also have parameters, written as
{{templatename|parameter}} or {{templatename|paramname = value}}.
The templates themselves have a limited programing facility with if and
foreach statements.

Templats allow a common format to be used. All plants use a taxobox to
record names and classifications of plants, for example ragwort
has
{{Taxobox_begin | name = Ragwort}}
{{Taxobox_begin_placement }}
{{Taxobox_regnum_entry | taxon = [[Plant]]ae}}
{{Taxobox_divisio_entry | taxon = [[Flowering plant|Magnoliophyta]]}}
{{Taxobox_classis_entry | taxon = [[Dicotyledon|Magnoliopsida]]}}
{{Taxobox_ordo_entry | taxon = [[Asterales]]}}
{{Taxobox_familia_entry | taxon = [[Asteraceae]]}}
{{Taxobox subfamilia entry | taxon = [[Asteroideae]]}}
{{Taxobox tribus entry | taxon = Senecioneae}}
{{Taxobox_genus_entry | taxon = ''[[Senecio]]''}}
{{Taxobox_species_entry | taxon = '''''S. jacobea'''''}}
{{Taxobox_end_placement}}
{{Taxobox_section_binomial_botany| binomial_name = Senecio jacobaea|
author =[[Carolus Linnaeus|L.]]}}
{{Taxobox_end}}
this will cause the information to be displayed as a nice table see
http://en.wikipedia.org/w/index.php?title=Ragwort
http://en.wikipedia.org/wiki/Wikipedia:How_to_read_a_taxobox

Templates also work well with categories. For example a 'flora of'
template could be defined to list a plant as part of the native flora of
a particular country. For example we could used {{flora of|China}}
which would automatically place the plant in the category 'flora of
China'. Most of the fields we are interested in could be represented as
such templates {{Height|10}} {{Edible uses|bread}}.

There are some limitations of the template/category system. It is not
possible to include additional info in a category link, for example any
reference to why it is included or a rating as to how good a particular
uses is. It works less well for numeric fields like height.

In RDF terms it does not allow a full triple
[object|relationship|subject] [Budlia|food plant for|butterflies], but
does come close.

In conclusion
-------------

The wiki model, in particular the MediaWiki implementation, covers
many of the features we need. It allows for extensible pages so new
sections could easily be added without being limited by the underlying
data structure. It has a powerful, flexible and extensible linking
system which nearly meets our needs. Its also an out of the box system
so little work to get it running. Out of interest there is a
permaculture wiki city http://permawiki.wikicities.com/
but its rather empty at the moment.

--

Disadvantages of MediaWiki
--------------------------

It is a big system, at each run about 30 php files need to be included
and a whole bunch of SQL queries executed. The end result of this is
that it takes 2 seconds on my computer to deliver a page. Not a critical
 lag though.

It requires that all participants are happy to work towards consensus on
the articles. Often this works well and the permaculture page
   http://en.wikipedia.org/wiki/Permaculture
has seen numerous small improvements gradually making a better article.
 The more controversial a topic the higher the likelihood of
disagreements and some articles like homeopathy have had endless
discussion never really reaching consensus. Coupled with this is a large
dispute resolution system and Byzantium beauracracy needed when a
million people work together.

Wiki do require eternal vigilance. There will always be some form of
vandalism/spam and "POV" pushers - people with a very strong point of
view on an issue willing to fight to the bitter end, which can skew
articles. Some parts of the wikipedia system to tend to encourage
polarized debates. ALL human life is in a wiki community!

Whilst mediawiki can be adapted to allow question and answer systems and
are passable as a discussion forum it is not the best system for these
uses. I'd only recommend it when there is central need for collaborative
documents. If the focus is elsewhere use a different system.

  
Enough for now. Feel free to email me and I may also be able to comeup
to Leeds for expenses, if you want a more extensive chat meeting.

End of the day, its a case of applying some permaculture principles.
Observe what the permaculture online community is like, what are the
resources what are the needs, then engage in the design.

   Rich
--
Plants for a Future: 7000 useful plants
Web:   http://www.pfaf.org/
Post:  1 Lerryn View, Lerryn, Lostwithiel, Cornwall, PL22 0QJ
Tel:     01208 872 963
Email: webweaver@pfaf.org
PFAF electronic mailing list http://groups.yahoo.com/group/pfaf