Re: [Libreplanet-dev] Fwd: fsf groups extension patch

[John Sullivan]

(Adding list back to CC)

Peter <address@hidden> writes:

> Hi John,
>
> On Thursday 26 March 2009 19:40, you wrote:
>> Peter <address@hidden> writes:
>> > On Thursday 05 March 2009 21:32, you wrote:
>> >> Hi Peter,
>> >>
>> >> And which change out of all the ones you suggested do you think is most
>> >> important right now?
>> >
>> > Unquestionably enabling the parser and string functions. Adding my
>> > patches will allow all the rest to follow. The calendar extension at
>> > http://www.mediawiki.org/wiki/Extension:Calendar_(Kenyu73) , is awesome.
>> >
>> > I don't think the semantic web extensions or forms are what we're aiming
>> > for. The problem is that they structure pages. We want form functions,
>> > like add user, register member to group, join/leave project, and similar.
>> > I think we can use the special pages to do that.
>> >
>> > The most critical is to get the parser and extension functions working.
>> > These are essential for naming pages and navigating subpages and central
>> > to the whole design. Without them, we can't move forward.
>>
>> So, good news on this front. We hope to be upgrading the Mediawiki
>> instance to the current version in the very near future (the last
>> blocker to that is our custom authentication code, which is being sorted
>> out today if all goes according to plan).
>
> That is excellent news! While at the auth code, would it be possible to 
> require the email, too? Not a big deal if a bit of work. Ultimately, I am 
> thinking registration will be something like the user profile template.
>
> btw, the php and possibly mysql will have to be upgraded as well. (Can I dare 
> hope for postgresql, instead?)
>

What do you mean by requiring the email? People have to provide an email
when they register now.

I don't think we'll be switching to postgres right now, it'll probably
continue to be what it is now. Upgrading PHP won't be a problem.

>>
>> Can you explain the parser and string functions a little more? Will we
>> still need these after upgrading? Are they custom code or part of some
>> standard Mediawiki bit/extension upstream?
>
> They are custom code that will be needed, iff we continue with the existing 
> wiki structure and templates. 
>

Hm, okay. I'll have to think about this more; part of what we are trying
very hard to avoid here is custom code. We want to stick as closely as
possible to the Mediawiki upstream, so that we can continue to be
current and take advantage of all the extensions that are out there. Is
there any possibility of getting these functions added upstream? 

I'm not certain any more that we should be using subpages that rely on /
to create namespaces. From what I'm being told that's not really the
Mediawiki way of doing things.

> The critical {{subpages:}} function provides automatic subpage links, which 
> complements the parent links provided by mediawiki. This works like category, 
> when you link a page to the category, it automatically appears in there. 
> Similarly, when you create a subpage, it will automatically appear as a link 
> in the parent page. This means a sub page is always linked to and therefore 
> accessible.
>

This much at least I know we could achieve with SMW -- because you can
embed queries in pages that will then automatically list information or
links from pages that match the query. I used this already in a demo to
generate a nice table list of groups.

> I do want to add coords for Regions and I would like to discuss this further. 
> These pages take up a lot of space and do very little. I suspect they were 
> used to route visitors to actual groups, but I prefer groups being root pages 
> with more direct navigation. I'd like to move the region pages into the 
> category namespace, so we have a single Continent category with 7 region 
> sub-categories and many area sub-sub-categories. The group template will then 
> be able to calculate the correct area category for the group. 
>
> So, we will have the same region setup we now have, except it will be in the 
> category namespace, and groups need only define their region and area to be 
> categorized. The main menubar already has the Region category, so browsing 
> will eventually arrive at group links, which is a similar user experience. 
> For maintainers, we don't have to worry about linking, just check the group's 
> region and area. This, I hope, will also avoid people messing with these 
> pages and we can free up the main page for more promo material. Plus, our 
> article namespace is cluttered with these pages.
>
> This is a mamoth task, which I am working on automating, but not finished, 
> yet.
>

I agree with this completely and it would be excellent if you would take
it on.

-- 
John Sullivan
Manager of Operations
GPG Key: AE8600B6