[Top][All Lists]

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

Re: [Libreplanet-dev] A wrong link in the menubar?

From: Peter
Subject: Re: [Libreplanet-dev] A wrong link in the menubar?
Date: Sun, 19 Apr 2009 23:28:45 +0000
User-agent: KMail/1.8.2

On Sunday 19 April 2009 10:54, you wrote:
> Il giorno dom, 19/04/2009 alle 02.57 +0000, Peter ha scritto:
> [...]
> >
> > Project:LibrePlanetItalia is the main project for all projects and the
> > whole group. All other projects should meet at least one goal of this
> > project.
> Good!
> Just a question about URIs.
> In the menubar of the "main" LibrePlanetItalia page
> the 'PROJECT' link points to this URI:
> If I have well understood, this should be the main project page for
> LibrePlanetItalia... but you say that:
> "Project:LibrePlanetItalia is the main project"
> and taht:
> "Every project page should have a group page:
> Project:LibrePlanetItalia/Project1
> Article:LibrePlanetItalia/Project1"
> So the questions:
> Which should be the right URI for the main (the group) project?

FSF_Groups:LibrePlanetItalia _is_ the page Project:LibrePlanetItalia. Both 
FSF_Groups and Project identify the same namespace. I prefer Project: for its 
meaning, but FSF_Groups: might be better because the wiki uses it in urls.

> Which should be the right URI(s) for each ProjectX (sub)page?

There is no right uri for a project subpage. It should be the project name, 
but can be anything because the editor must create the subpage and give it a 
name. Your main project should explain how the group creates and runs its own 
projects. You may create Project:LibrePlanetItalia/Project to explain the 
project schema and approval method. Then, Article:LibrePlanetItalia/Project 
(the website) may advertise its activities (projects) and how other LP groups 
or partners (GLUGS, LUGS etc.) can work with your group.

You can now create Project:LibrePlanetItalia/Project/Speaker, which explains 
how people can invite your members to talk on Libre Planet and how the group 
will help speakers prepare their talk, transport, accommodation, and any 
required fundraising to cover expenses. It will also explain how to create a 
speaker project and measure its success.

The Article:LibrePlanetItalia/Project/Speaker page can advertise speakers, 
topics, and the booking procedure. Obviously, you want venues in your local 
area, not in another country, or maybe not ;).

Another project Project:LibrePlanetItalia/Fundraising explains how the group 
handles raising money to fund projects, sponsor groups, or donate. The 
Article:LibrePlanetItalia/Fundraising asks for donations and offers to raise 
funds for worthy (LP related) causes.

For something different, you may have Project:LibrePlanetItalia/Media which 
explains how the group makes music, adverts, videos, etc. for marketing LP 
and advertising free software. Article:LibrePlanetItalia/Media explains the 
group's activities in media, what's available for downloading, and the 
procedure to request a media project.

> This will help us to create new pages in the right way, with consistent
> URIs... So, please, can you also provide us some examples using full
> URIs? Maybe something like a URI tree, with the main projet URI as the
> root...

The uri tree should be developed by your group. If the group and project share 
the same tree (page names), that's correct. Groups have different interests 
in LP, so their uri trees will be different. The top menubars give an idea of 
what other pages should be created.

You will notice that the About, FAQ, and News links are not 
LibrePlanetItalia/About .. , but About/LibrePlanetItalia. These are thread 
pages that apply to all groups. This means the FAQ thread is created by the 
groups themselves, but has its own uri tree. Users may navigate the FAQ 
thread without accessing any group pages, but each FAQ page has a link back 
to the group page. The menubar is used to move between threads (uri trees), 
namespaces (article, project, and help) and special pages (attendance, 

What we're looking for is consistent navigation in all Groups (menu links), so 
the page names are not important like wikipedia. However, short names are 
better (Speaker, not Project_to_describe_how_to_be_a_speaker) and singular 
(speaker) not plural (speakers). With a feature rich mediawiki, editors can 
set their own title (Project to describe how to be a speaker) no matter what 
the real page name is (Project:LibrePlanetItalia/Project/Speaker).

Also, we want to categorize important group pages, so these pages should 
exist. However, Libre Planet has not defined what categories groups must use, 
nor what pages must be categorized, so there is no right way to create pages 
and categorize them. As we get more groups, we will see what categories work 
best and help groups categorize their pages.
Right now, I think you can ask your group to work out a uri tree and put it on 
your project page (or subpage) as a proposal. Then you can put the project 
link on the Community portal under Proposals asking for comment. You may also 
use the Category:InputNeeded. Wait about 7 days for objections, and if you 
don't get any, remove the links, and build your group.

If you need menubars for your uri tree, 7 days should be enough time to create 
the templates and test them, so they should be ready when you start creating 
your pages.

The current wiki version does not provide parent and subpage links, so it is 
important editors provide these links in every page. The parent links should 
be a the top of the page, and subpage links at the bottom. There should be no 
content links to subpages or parent pages. I have not found a way to get the 
wiki to provide parent and subpage links using templates.

for an example of parent links and for an example 
of subpage links.

Another point to consider is people joining projects, meetings, campaigns, and 
the group. Whenever you need a list of users, make it a separate page and 
create a menu link. When we get a feature rich mediawiki, we can use forms to 
control and manage users joining and leaving. This will keep the main event 
page focused on the event and avoid it being edited by people wanting to 
attend. The attendance pages can be categorized, so we can see which events 
are popular and also generate mailing lists from the pages, so we can keep 
users informed about their events.

For a real example see



reply via email to

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