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

[Peter]

On Tuesday 31 March 2009 18:39, you wrote:
> (Your reply didn't keep the list in -- adding it back again, and leaving
> the full text quoted here so others can see)
>
> Peter <address@hidden> writes:
> > On Friday 27 March 2009 20:19, you wrote:
> >> (Can you make sure when you reply that you keep the list in?)
> >>
> >> Peter <address@hidden> writes:
> >> >> 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?
> >> >
> >> > The custom code fits into the extension system provided by mediawiki.
> >> > So it shouldn't be affected by upgrades. It is a standard wiki with
> >> > custom extensions. I haven't tried to get the extensions 'officially'
> >> > approved (like the calendar) because as you point out, its not really
> >> > the mediawiki way.
> >>
> >> Wouldn't it make more sense to package these up as extensions and get
> >> them distributed along with other extensions? That way, other people
> >> might contribute to maintaining them, and they would at least have a
> >> chance at being part of the upgrade path. I'm sure the extension system
> >> changes from time to time and breaks things?
> >
> > Yes, but so far one one is enthusiastic about them, but if Libre Planet
> > (conditionally) approves them, I will do that. I agree the API may
> > change.
> >
> >> >> 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.
> >> >
> >> > 'subpages that rely on / to create namespaces' <-- I don't understand.
> >> > Namespaces are created statically by the webmaster and are not
> >> > influenced by page creation.
> >> >
> >> > To back up a bit: mediawiki _developers_ created a wiki that can
> >> > construct pages as a tree data structure. This is a typical and
> >> > efficient software data structure for both storing and accessing
> >> > _related_ information. However, the developers did not provide all the
> >> > functions necessary to manipulate the structure efficiently.
> >> > Consequently, mediawiki users seldom create related pages in a tree
> >> > structure because it is hard to maintain, so there is an existing
> >> > culture to avoid subpages.
> >> >
> >> > I have (hopefully) added the missing functions, so using subpages is
> >> > as easy to use as single pages. Now people can add related pages as a
> >> > tree structure, so the content can be navigated in a relational way.
> >> > In this sense, it is _more_ consistent with the _developers_ idea of
> >> > the wiki, than the culture. The page content and page relationship are
> >> > merged and the wiki has a consistent look-and-feel to it.
> >>
> >> Okay, I'm sorry to continue being dense about this, but I need a *short*
> >> example that demonstrates what these functions do. It would help a lot
> >> to see a concrete example of something that is hard to do with default
> >> Mediawiki that these functions solve. I am getting closer to
> >> understanding I think, but not quite there :).
> >
> > whew, examples are hard to explain, but I'll try. A visual demo is far
> > easier.
> >
> > Take the SessionSchedule page as an example. The schedule provides
> > several events which are subpages to SessionSchedule, such as
> > SessionSchedule/LFP, SessionSchedule/SchoolsAndLibraries, and many
> > others.
> >
> > Now we see mysql can't cope with long names so we want to shorten
> > SessionSchedule to LP09Events. The problem is that the current mediawiki
> > will allow us to move SessionSchedule to LP09Events, but all the subpages
> > will still be 'subpages' of SessionSchedule. The only solution is to move
> > each page individually without typing errors.
> >
> > What we really want to do is move SessionSchedule _and all its subpages_
> > to LP09Events. My functions will allow you to move SessionSechdule to
> > LP09Events and SessionSchedule/LFP and
> > SessionSchedule/SchoolsAndLibraries and all pages starting with
> > SessionSchedule. So in one move we have renamed many pages and can now
> > access LP09Events/LFP, LP09Events/SchoolsAndLibraries.
> >
> > If at some later point we decide to merge LP09Events into LibrePlanet, we
> > can simply multi-move LP09Events to LibrePlanet/LP09Events - and all
> > LP09Events subpages will be moved too. Now we can access
> > LibrePlanet/LP09Events/SchoolsAndLibraries.
> >
> > Again, if we decide we no longer want LP09Events pages, we can
> > multi-delete LibrePlanet/LP09Events - and all its subpages. So not only
> > will
> > LibrePlanet/LP09Events be deleted but so will LibrePlanet/LP09Events/LFP
> > and all the others, such as LibrePlanet/LP09/LFP/Comments/...,
> > LibrePlanet/LP09Events/SchoolsAndLibraries/...
> >
> > Since we do not know exactly what subpages have been created for
> > SessionSchedule, it is currently hard to know whether we've moved them
> > all. My functions simply get the wiki to find and move/delete matching
> > pages.
> >
> > More examples, if we decide that we want to move LP09Events/LFP from the
> > schedule into current_events and call it LibreFilePermissions instead, we
> > can move LP09Events/LFP to current_events/LIbreFilePermissions  - and all
> > LFP's subpages will move too. Now we can find
> > current_events/LibreFilePermissions/Comments.
> >
> > We may decide a group's page name is inappropriate, such as DownWithLP,
> > so we can multi-move DownWithLP to LPForever, and _all_ the subpages will
> > be renamed, too. With one function we have renamed many pages.
> >
> > The point is that standard mediawiki only handles single pages, but
> > provides subpages which should stay connected to the parent page. My
> > functions recognize the relationship between pages and handles them along
> > with the parent page. We assume that if you move SeesionSchedule, you
> > also want its subpages to be moved too and remain subpages.
>
> Okay, the example did help and I understand now what the extension does.
>
> But, I think we want to be moving away from using subpages separated by
> slashes. I know we started out going in that direction.
>
> I think we can accomplish what we need to accomplish using categories,
> subcategories, and namespaces (in the standard mediawiki way of
> Help:Foo). So we wouldn't need to install custom software and wouldn't
> be swimming upstream.
>
> What do you think?

I stunned, want me to say more? 

*Admins* don't want subpages, but *users* do. *Admins* think the page name 
must be the title, but *users* don't. *Admins* don't want extensions, *users* 
do. Admins are swimming upstream, not the users. I think the Manchester group 
will be *really* upset because they have been successfully using subpages for 
their meetings for years.

I will go through the Libre Planet conference pages created by FSF staff, as 
an example of what I mean.

The use of subpages is not my idea, mediawiki developed it, the Manchester 
group use it, so did whoever created the libreplanet2009 schedule, and the 
OpenConference page! 

The three tracks (HPP, NFS, and Active) are all subpages hard linked into the 
OpenConference subpage. Someone else, during the course of the meeting, moved 
the speaker list to another subpage and added another hard-link. Some of 
these people show more wiki skills than I have and, I assume, grew up in wiki 
culture.

So, the first time Libre Planet used this wiki to organize a meeting, there 
were people who instinctively used subpages because the content suggested it. 
When you look at the LibrePlanet2009 pages, you see an organized arrangement 
of content and a flow of information from the most general at the top page, 
to specific detail at the bottom subpages.

I never did that, but its how rational people work. My proposal helps them 
work this way more easily. For example, at the bottom of the OpenConference 
page, you'll see a 'sub-pages' section. This does the same job as the hard 
links, but avoids editing the page each time subpages are added, deleted, or 
renamed/moved. They change nothing other than save work and look ugly ;).

Whoever created the schedule page clearly understood this was related to 
LibrePlanet2009 and therefore made it a sibling subpage of OpenConference. So 
now you have the conference guidelines in OpenConference and the actual 
activities in OpenConferenceSchedule as sibling subpages of LibrePlanet2009.

Initial LP page structure:

LibrePlanet2009
LibrePlanet2009/OpenConference
LibrePlanet2009/OpenConference/Track1..N
LibrePlanet2009/OpenConferenceSchedule
LibrePlanet2009/OpenConferenceSchedule/user1..X
LibrePlanet2009/OpenConferenceSchedule/speaker1..Y

Anyone who arrived at LibrePlanet2009 would now be given a choice of info - 
guidelines or events. The schedule first presents an overview and then links 
to more specific subpage events. These in turn direct the visitor to 
individual comments. The visitor can now travel back up the parent links to 
LibrePlanet2009 and select OpenConference.

[aside remark]
PROBLEM: The visitor cannot travel down subpages, but only up to parent ones 
because the wiki only provides parent links. It shows page linking is a wiki 
function, not an editor's.

SOLUTION: Add the subpage link function to the wiki, so it will now provide 
both links to parents and subpages.

WORKAROUND: Let editors do this manually, or try and categorize the pages. 
This will lead to link rot, category overload, and inconsistent browsing.
[/aside remark]

Again, this was not my idea, no-one asked me about this, it just happened. The 
problem with OpenConferenceSchedule is that it has been moved to a root page 
and doesn't explain anything about the schedule. Frankly, whether the page is 
called 

LibrePlanet2009/OpenConferenceSchedule,
LibrePlanet2009/OpenConference/Schedule, or 
OpenConferenceSchedule(LP09) 

it has not changed the content one bit. It is still the LP09 schedule. 

What the move did is brake the relationship between itself and all other LP09 
pages, prevented the wiki from linking up the pages for the user to browse, 
and, worst of all, failed to show admins where the other pages are. I see no 
advantage in doing that.

Instead of going into further detail (I did, but deleted it), I will simply 
say that the content of the FSF Groups wiki is structured and will benefit 
users and admins when they are allowed to subpage as the content demands it. 
This is particularly true for meetings, but also for High Priority Projects, 
and several other subjects.

When the LP pages were created, I expected to see root pages scattered 
everywhere, but the use of subpages reassures me that we're going in the 
right direction and the only restrictions I see are technical ones. However, 
the wiki should work for users, not users for the wiki. Perhaps on other 
sites, using subpages and extension features is swimming upstream, but here, 
I see it as going with the flow and I hope you now do, too.

We can categorize and use namespaces equally well with or without subpages and 
extensions. However, neither the Manchester group, nor Libre Planet staff, 
have thought to avoid subpages, probably because it is harder to figure out 
how to do it. They did so without any extensions whatsoever. The extensions I 
propose only automates the tasks editors and admins are already doing with 
subpages.

The extensions do not fundamentally alter the standard wiki's behaviour, but 
complement the existing subpage features. Using the extensions are optional, 
they are not embedded into every page, so installing them won't automatically 
change all the pages. Users need to learn about them and decide if they like 
them, and if not, simply not use them. The only reason I am proposing them is 
because I found the need when I came to manage my own subpages.

While we can live (for a short time) without the extensions, I believe the 
wiki will become unmaintainable if we ban using subpages. We use subpages 
because it enables us to connect related pages together without burdening 
either the user or webmaster with trivial link edits. Categories index pages, 
namespaces reuse page names, subpages relate page *content*, and links 
connect pages. They all have a purpose and using one feature to replace 
another will, imho, lead to missuse, abuse, and ultimately confusion.

wikipedia is using dozens of bots to control link rot, and similar things, and 
still has many admins doing nothing but page cleanups. They're involved in 
name page disputes on a regular basis, edit wars, and the like. We, however, 
are running a well defined wiki for LP members to promote free software, not 
for the public to edit and link to with complete abandon.

Other group packages provide specific functions and nothing else. Just because 
our wiki is not so constraining simply means we have to impose the 
constraints for the benefit of all members. But making arbitrary decisions, 
that go against what users see as useful, doesn't work for me.

Regards,

Peter