Restructuring techbase and userbase

[Stephen Kelly]

Dominik Haumann wrote:

> Hi,
> 
> -> Trailing slashes
> We have a patch for mediawiki we usually applied on techbase so that it is
> automatically removed. I'm in favour of applying it again, and am strongly
> agains doing it manually!
> 
> -> More toplevel items
> Meanwhile I'd agree to open techbase a bit more like we have on userbase.
> I think it's ok if an app has its own toplevel item. But then, all the
> content (tutorials, irc logs, contact infos, whatever) should still use
> subpages in my opinion. Having this kind of structure later (i.e. when
> maintaining it) helps a *lot* to decide what a page is about.
> You mentioned below [[porting kjots to kde4 pillars]]. This is definitely
> something I'd like to avoid.

Yeah, that was an unfortunate typo. Should be [[Projects/porting kjots to
kde4 pillars]] as described in the text.

> 
> -> Overview pages
> In usebase we have something like [[Applications/Multimedia]] which works
> very well as far as I can see. So I imagine it'll also work for techbase.
> Another idea would be to introduce the concepts of portals again:
> Portal:Applications. For those who are not familiar with this, the
> prefix "Portal:" is kind of a namespace. Afaik this has to be enabled in
> the localsettings.php file (http://meta.wikimedia.org/wiki/Portal)

Mediawiki namespaces are nothing special. They only take content out of
the 'main' namespace. See the existing namespaces here:
http://techbase.kde.org/Special:Search

If we enable the Portal namespace in the localsettings.php, all we get is
another namespace. We still have to do our own templates, our own tutorial
of the day, or whatever else typically goes into portal pages. There's no
value in enabling and using it. In fact, it's harmful, as those pages
wouldn't be show up in search results unless you use advanced search and
tick the right box.

That brings me to another point you brought up about duplicate search
results. You can create arbitrary namespaces, so we could create one
for 'TipsTemplates' and then use {{TipsTemplates:Kjots}} etc to include
tips instead of {{:Kjots/Tips}}. That way the 'internal' pages wouldn't
show up in searches, but say, [[KJots]] and [[Tutorials]] would show up
because they include the content. Also I don't see any problem with both
pages showing up in search results.

> 
> -> {{:syntax}} usage
> This kind of usage makes sense only in very few cases. As example, I'd
> like to mention e.g. Plasma/Tutorials which is then included in
> [[Development/Tutorials]]. But I don't see the real benefit to include the
> tip of an app by using this semantic, in contrary: Searching for content
> will deliver duplicates.

I'm not certain I understand this paragraph. Could you rephrase? 

> 
> Flashback of the last two years:
> I've reviewed almost every change in techbase for the last two years now
> and I don't have to change lots of stuff, so maintaining works quite ok
> this way. I'd like to stress that maintainability is one of the most
> important issues, otherwise we'll end with wiki.kde.org. That said, I also
> have to say that I don't have the holy grail either, so: Who Codes
> Decides.

Right, well I would like to proceed with planning top level application name
urls and top level 'team' pages (modules etc) and reorganizing tutorials
and projects with the {{include}} technique. 

I would like concensus on this being a good idea though. If I want to create
a techbase.kde.org/kjots page with info on how to get started contributing,
and projects that are going on, I'd have to duplicate a list of projects
manually. Scale this up to many applications and modules doing the same
thing and it gets unmaintainable IMO. A way to share such lists makes it
easier.

Stephen


> 
> Dominik
>