Re: [Libreplanet-dev] elgg site for testing

[Peter]

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