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

[John Sullivan]

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:
>
>> >> 2. Subpages enabled in all namespaces, including Main.
>> >
>> > Good. What is the position regarding the subpage extension? I have
>> > updated it and have other extensions pending approval. (more below)
>>
>> I'm fine with including them. I wasn't sure if we needed them given the
>> built-in Subpage stuff. I've passed your list at the bottom on to the
>> sysadmins so that these further things can get done.
>
> Hmm, I don't understand, the built-in subpages just creates and deletes them, 
> but doesn't show them in the parent page. The extension just shows subpages, 
> it doesn't create or delete them. We need both subpages enabled and the 
> extension. Am I missing something?
>

That's fine. I wasn't objecting to installing the extensions, they were
in the request I put in to the sysadmins yesterday.

>> >> 5. Calendar - http://www.mediawiki.org/wiki/Extension:Calendar_(Kenyu73)
>> >
>> > Request the namespace be changed from Calendars to Event (singular) as
>> > this namespace deals with events, the actual calendars can be on any page
>> > in any namespace, iirc. Now we can add a calendar to current events page
>> > and maintain current events automatically for all groups.
>>
>> Agreed.
>
> I see Calendars namespace still exists, is that necessary?
>

Probably not, but is it hurting anything?

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


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

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

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

>> Sure, we can host them at LP. Can you just upload them as files? They
>> aren't big, right?
>
> Thanks, the files are a few kb, but if they're useful, I expect they'll get 
> larger over time. ;)

Feel free to upload them, we can always move them elsewhere and redirect
if they get too big.

-- 
John Sullivan
Manager of Operations
GPG Key: AE8600B6