Re: [Libreplanet-dev] Recent and future updates to libreplanet mediawiki

[Peter]

On Wednesday 20 May 2009 15:00, you wrote:

> Peter <address@hidden> writes:

> > On Tuesday 19 May 2009 16:20, you wrote:

> >> Peter <address@hidden> writes:

> >> > On Tuesday 12 May 2009 15:27, Danny Clark wrote:

> >

> > I see Calendars namespace still exists, is that necessary?

>

> Probably not, but is it hurting anything?

>

It takes about 60 seconds to remove and part of housekeeping. If it's not there people won't try to use it.

> >> >> Other than that and technical doc for that I'm planning on:

> >> >>

> >> >> 1. Installing a better search extension - I've used

> >> >> http://www.mediawiki.org/wiki/Extension:SphinxSearch and it seems

> >> >> nice, but I'd welcome feedback/suggestions on this topic.

> >> >

> >> > Current searching targets the page name, but ignores any displaytitle

> >> > the page may have. Would like the search to first match displaytitle

> >> > and then page name. Unlike wikipedia, we're free to use the page name

> >> > as an organisation tool (subpages) and create our own page title that

> >> > may not change when the page is moved. This also means we can use

> >> > shortened page names, without having a cryptic title. Searching a

> >> > short page name makes little sense, while searching the display title

> >> > does. Other than that, any search tool will do.

> >>

> >> I agree I think, but what needs to happen to fix it?

> >

> > I was responding to Danny's rfc on a search tool, but I have no idea

> > what's available.

>

> Okay, maybe test the one he was suggesting and see if it does what you

> need?

I thought he wanted 'feedback/suggestions on this topic' from people, so that's what I gave.

>

> >> >> 2. Installing OpenID support -

> >> >> http://www.mediawiki.org/wiki/Extension:OpenID

> >> >

> >> > I see LP as a large network of websites, where many groups have their

> >> > own wiki/website syndicated together into a single large web space

> >> > (the LibrePlanet network). In this context, openid might be more

> >> > practical. OpenID login with third party websites, however, probably

> >> > won't benefit LP. If we're going to have a singe mammoth website, how

> >> > would openid help?

> >>

> >> OpenID means that people can more easily import their profile

> >> information from other places, which might include their contact details

> >> and info about what projects they work on. It's also a nice thing to do

> >> from a freedom perspective because it puts individual users in control

> >> of their authentication if they want to be -- they can run their own

> >> OpenID server, for example.

> >

> > I think we should scrap user registration entirely, and replace the login

> > page with group and member registrations. :) Since most people will be

> > focused on their local group, I really don't see the need to store

> > personal data.

> >

> > The group profile, however, can be quite detailed because groups will

> > need to colaborate and network. Groups could run their own OpenID server,

> > in which case, it would be limited to LP's network, rather than the rest

> > of the world.

>

> Individuals will need to find each other at the very minimum in cases

> where groups are not yet formed.

I agree, but individuals must be trained in running an LP group, so must join their nearest group first. This does not require LP registration, nor swaping personal profiles, only accessing group profiles to find contact info.

> Plus, I think geographic groups will

> not be the only kinds of groups -- there will also be project and

> campaign groups. So it's useful for individuals to be able to advertise

> some profile information about themselves.

I disagree, projects and campaigns etc. are group collaboration tools. Groups participate in projects through appointed members. Members are expected to spend their time on local advocacy, projects that don't do that are counter productive. So, no, user profiles are not necessary, but group profiles definitely are. The whole of LP is the local group.

The problem is one of scale. We can end up with 6 million members and a billion non-grouped users looking to form groups. Clearly the users are not achieving LP's goal, but comsume most of LP's resources and certainly consist of open source and proprietary advocates. So, no users without groups. It isn't neccessary nor practical at a global level.

>

> >> So maybe we should start with:

> >>

> >> [[based in::Italy]]

> >>

> >> as the way to initializing categorize group pages?

> >

> > You mean when the script generates the category page, it includes, the

> > smw stuff? Sure, I wanted the script to generate a full page.

>

> Which script do you mean? I'm suggesting that now we don't need to build

> static pages of group listings -- if we tag all the groups with where

> they are based, then the lists can be made using inline queries, which

> are dynamic. And we can have a nice map that people can click on to find

> groups in their area.

That sounds like what I have in mind. However, LP should store all the location data itself, so users can't enter rubbish, or strange variations.

>

> >> The coordinates property might be useful here as well:

> >> http://semantic-mediawiki.org/wiki/Property:Coordinates.

> >>

> >> Then we can use SMW's inline queries:

> >>

> >> http://semantic-mediawiki.org/wiki/Help:Inline_queries

> >>

> >> to generate the groups-by-country list.

> >>

> >> Sound good?

> >

> > Yes, the data mining bit (groups-by-country) sounds good, but are the

> > region pages still going to be moved to categories, or will they be

> > deleted from the Main namespace and smw create categories dynamically?

>

> I think the latter -- dynamically.

That's fine, but we still have to create the regional database and link the registration page to the map?

Regards,

Peter