[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libreplanet-dev] elgg site for testing
From: |
Peter |
Subject: |
Re: [Libreplanet-dev] elgg site for testing |
Date: |
Fri, 6 Mar 2009 17:54:18 +0000 |
User-agent: |
KMail/1.8.2 |
On Thursday 05 March 2009 21:38, John Sullivan wrote:
> Graziano has been kind enough to put up a test Elgg site for us to look
> at.
>
> http://www.sorbaioli.org/gnubook/
>
> Check it out and see what you think.
Its a start, but not what I expected.
Not sure what you're aiming at for FSF Groups. My view of FSF groups is an
internal network that tunnels through the internet. Each group has irc, news,
mail, ftp, http, and admin servers. Local members access their group servers
which transfers info throughout the network. The admin server handles
membership, projects, activities, donations, etc. - like a ngo. Members
belong to two groups, a member of a parent group, and an associate of a child
group. Thus a member can access the group's parent server (as a member), and
the group's server (as associate member). This creates a member tree
structure rooted at FSF's group members. All this is designed to achieve the
following objectives:
1- Market the FSF movement.
2- Change software legislation.
3- Recruit new members.
4- Create groups.
5- Teach members how to do 1 - 5.
The LibrePlanet website is intended to achieve the first three objectives. It
acts as the FSF groups' public relations, news media, and recruiting centre.
The last two objectives are handled by 'internal' servers and admin software.
Local groups may have their own website (rather than a central LibrePlanet),
with 'redirects' to parent and child websites. This will reduce the burden on
the central site and ensure they function when the network fragments.
So, my criteria for finding a suitable marketing website application are:
1- Has a website look-n-feel.
2- Has copyright consistent with FSF (i.e. no open source)
3- Has little or no project dependencies.
4- Uses homogeneous program languages (i.e one or maybe two).
5- The program developers are pro FSF.
My rationale here is that people will be looking to 'bad press' the movement
and using non-GPL software may be enough to get them started. We also should
take care we practice what we preach, so python (imo) is a dubious language
choice, and so is php. Most of the network programs are pro open source,
including elgg and pinax. Fortunately, mediawiki developers are FSF aware, so
that is a possibility. The down side is it uses php and the zend license may
be difficult for us to justify. The only GPL script I know is scheme (guile).
Normally, I have no objections to using open source, but here we are really
focusing on free software, so any hint of reliance or association with open
source will reduce our message. If ever we want to separate ourselves from
the open source objectives, it is in the software we use.
Back to elgg, I think it can work as an internal server to foster member
relations, and perhaps personal guidance wrt the objectives. I don't think it
will work well for assigning members to activities and monitoring their
progress. It may be a source of intelligence gathering in terms of compiling
a training guide for new members, though. I'm not sure how well it will
transfer from a social to political activist network, either.
To expand elgg, my suggestion is to split it into three sections and try to
turn it into a transaction based system. Here is my thinking:
1- Three account types: Member, project, activity
2- Projects are opened and closed.
3- Projects assign and transfer members between activities
4- An activity associates a member with a project.
5- Each member records their progress on each activity.
5- Each of 2- 3 generates a transaction on a project.
With this we can report by project, member, or activity and get a history, or
find the other two accounts. We need to drill down throughout the network on
multi-group projects and activities, so the reporting functions will need to
include network searches, too. Regular reports can be pushed (from child to
parent) or pulled (by parent from children). The reports only access the
group and all its children, so parent groups should make them available to
their child groups.
If elgg it is relatively easy to code these changes, it will make it a good
candidate, but atm my money is on mediawiki. Unfortunately, what I am looking
for is a merge between elgg/pinax (for their functionality) and mediawiki
(for its presentation). One major advantage mediawiki has is that it is
network aware and might be less work to use as distributed websites, rather
than a central one. I have no idea what backup capabilities we require or is
supported by any of these programs, though.
If we use both elgg for internal use, and mediwiki for public, then perhaps we
can do some backend magic to integrate the two programs and provide a simple
interface for members. The downside is they use different languages, which I
am not geek enough to be enthusiastic about ;).
Peter