[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John Sullivan
Subject: Re: [Libreplanet-dev] Recent and future updates to libreplanet mediawiki
Date: Wed, 20 May 2009 11:00:27 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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

>> >> 2. Installing OpenID support -
>> >>
>> >
>> > 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:
>> Then we can use SMW's 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]