Restructuring techbase and userbase

Stephen Kelly steveire at
Mon Jan 5 15:17:28 UTC 2009

Cornelius Schumacher wrote:

> On Saturday 03 January 2009 16:17:43 Stephen Kelly wrote:
>> I'm proposing some changes to how pages are organized and structured on
>> techbase and userbase.
> Thanks for moving forward with this discussion. There definitely is a need
> for some better organization.

Hi, thanks for entering the discussion on this. I really do want to get the
best solution for this and the more ideas on how to restructure the better.

>> It's not entirely clear where such discussion belongs. See
>> to
>> catch up.
> That itself shows, that we need better structure ;-)
>> Currently some teams have pages which live below the Projects/ page, like
>>, and particular games live a few
>> levels below that:
>> I don't think there's any need for all those subpages. I propose moving
>> such pages to Userbase already uses
>> the$APP scheme. Additionally
>> would be moved to
>>, so that if you want to get started
>> contributing to a module, you go to$MODULENAME.
> What would we gain by such a change? The additional directory elements 
> give information about the meaning of the page and provide people creating
> pages some structure, so we don't get a mess with a lot of different pages
> in a flat namespace.

Well, it would be obvious where a page for an application belongs without
even knowing what module it's in, what category of game it is, and not
forgetting the top level projects item. Currently you have to look on
techbase and click through the links until you end up at the url above.

Additionally, sub-page schemes are currently not consistent. See how
different the structure beneath 'Edu' and 'Games' is. does not
automatically get a link to it's 'parent' Projects/Games/Arcade_Games/, and
Projects/Games/Arcade_Games/ does not know a list of its children. It has a
list currently which someone put there, but all that does is cause extra
clicks to get to the KGoldRunner page. It would make more sense instead to
have something like

It can be made better looking in many ways, but it would be included in the
[[KDEGames]] page, and maybe each game page as well. See how is included in all kde pages.

There's really no need to click through all those sub pages to get to what
you want. I'd say they make it less maintainable because it's inconsistent
across different teams, it's not predictable (Is it Projects/Edu or
Projects/Education?, Is it Projects/PIM/Mail/{KMail,Mailody}?), it obscures
pages inside multiple sub pages which are only used as 'index' pages anyway
(I mean like Projects/Games/Arcade_Games/ and others).

What you get is some information encoded into the url, but I don't think
it's neccessary, and the page doesn't gain anything. 

>> I think Projects/ makes more sense for things like:
>> Projects/Migrate KMail to Akonadi
>> Projects/Port KJots to KDE4 pillars
>> Projects/Move libplama to kdelibs
>> Projects/Reviewing techbase and userbase structure
> I think this is a misunderstanding caused by our sloppy way of using the
> term project where it means sub-project of the KDE project. Actually the
> vast majority of pages under Projects/ are team pages.

Yes, but I don't think that's necessarily the best way to do it. What if we

And a single page with links to all the teams.

* [[KDEPIM]] - Personal information management applications
* [[KDEGames]] - Games in KDE.
* [[i18n]] - Translating and localizing KDE.
* [[Promotion]] - Promoting KDE

If you click on one of the pages you get information on how to join the team
(mailing list, irc) and what you need to know (GraphicsView and any other
games libraries for Games; ModelView, TextEdit, akonadi, rss etc for pim
etc) the list of bugs for the module or whatever and how to get started.
Not just 'A page about kdepim' or 'A page about KSirk'. That's far too
broad. It has to be 'How to contribute to KSirk' in terms of development,
documentation, artwork etc. The page would be the
quick tips on, eg, How to play Ksirk against your friends over a network or

I've just created a Kjots techbase page at [[KJots]] (I can move it later if
this structure is seen to be a really bad idea). Because it's at the top
level, I could trivially make a link to it from userbase with
{{TechbaseLink}}. I'll can also put a link to it in [[KDEPIM]] later if
that page is seen as a good idea, or on the [[Projects/PIM/Applications]]
page. The former seems like the more obvious place to me.

> But in the end it would be better to not have these pages on techbase at
> all. Techbase was meant to contain polished technical content for system
> administrators, third-party developers and external people interested in
> contributing to KDE. It wasn't meant as whiteboard for internal
> development information and mainly community related content.

I'm interested in focussing in more on 'external people interested in
contributing to KDE'. If that's what it is, though, it does make sense to
also have the whiteboard of internal development information in the same
place if external people are going to get started joining a team, doesn't

> My proposal would be to create a dedicated Wiki for community content
> which could server for all these purposes without degrading the quality of
> techbase by mixing in content not useful for techbase's target audience.
> This dedicated Wiki (""), would contain team pages,
> information about work in progress, could be used for community
> coordination, documentation about KDE internal processes, etc.

I don't think another wiki is a good idea. Many people in KDE already don't
sign up for a tech- or userbase account because they already have too many
accounts for things. Fragmenting things out again is not going to help

Also, whatever the initial purpose of techbase was, it has evolved. If you
try to migrate the people away from there on to communitybase, you will
lose a lot of people along the way.

Instead, I think techbase could be used for team pages
($Team), information about work in progress
( - also with relevant projects linked in the
team page, documentation (Documentation team page, [[Projects/Bringing
Documentation up to date with KDE4]],,
documentation about internal KDE processes

Techbase is already used for these things. The structure was just not
designed to hold them, so we could just fix the structure.

> So as result we would get a clean structure with a natural place for
> everything I can think of:
> - userbase for KDE users
> - techbase for external KDE developers
> - communitybase for KDE community content

I don't know, you seem to be proposing moving techbase.k.o to
communitybase.k.o and resusing the subdomain. Also, I think it could be a
thin blurry line between techbase and communitybase. The focus for each
will have to be pretty clear if it all comes through. Especially because
you're proposing changing what techbase is already used for.

>> Yet another thing that I don't see a reason for is that it's not possible
>> to create a 'normal' account on userbase. Why is that? Can we change it?
> OpenID provides a lot of advantages, but also has some challenges. The
> OpenID handling on userbase could be a lot more user-friendly. But how to
> best deal with OpenID is a separate discussion.

Sure. Let's leave that aside for now.

Any more thought on what I've said from anyone?

I think we should make a page to plan out some reorg, where pages are
proposed to be moved to (within techbase or to communitybase etc) and see
if any good ideas fall out of it. I can do that later if need be. Going out



More information about the kde-www mailing list