Restructuring techbase and userbase

[Cornelius Schumacher]

On Monday 05 January 2009 16:17:28 Stephen Kelly wrote:
> Cornelius Schumacher wrote:
> >
> > 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
> had
>
> techbase.kde.org/{KDEPIM,KDEGames,KDEEdu,etc,i18n,usability,promotion,etc}*
>
> And a single page techbase.kde.org/Teams with links to all the teams.
>
> * [[KDEPIM]] - Personal information management applications
> * [[KDEGames]] - Games in KDE.
> * [[i18n]] - Translating and localizing KDE.
> * [[Promotion]] - Promoting KDE

This would go against how techbase is structured for all the other content, 
where we have Development/, Schedules/, KDE_System_Administration/, ISV/, all 
with an additional level of subhierarchy. This is the original structure, 
organizing most of the content of techbase.

The Projects/ content was added later because of lack of a better place. It 
never really belonged on techbase. The quality and completeness of the 
Projects/ content is also rather low and it's more volatile information than 
the rest of techbase.

> > 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
> it?

I don't think so. Internal development information is less structured, more 
likely to change, not polished for external people, etc. This is confusing 
for everybody not familiar with the internal of KDE development. Techbase was 
started as a high-quality source of information about how to technically use 
KDE, for system administration, for 3rd party developers, for ISVs. This is a 
very important target group and we should try to provide the best possible 
content without dumping all kind of unsorted information on them.

> > 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 ("communitybase.kde.org"), 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
> that.

Of course we need a combined account system for all three Wikis. That's a 
technical detail, and it's only relevant for people contributing. If we do a 
good job, there is a multitude more people just reading the Wikis where 
accounts aren't an issue.

> 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.

I don't think techbase has changed that much. The Projects/ content was added 
because there simply isn't a better place, not because the content would 
belong there. All the other content on techbase is fine and should stay 
there. So the only thing I'm proposing is to move the content which doesn't 
belong on techbase to a new Wiki. In addition to that there also is a lot of 
content on other sites, which could be moved to a community Wiki. We could 
revive a lot of currently unmaintained KDE sub-sites by putting them on a 
central Wiki, where maintenance is not limited to people knowing how to cope 
with Capacity or having access to the external Wiki instances which were set 
up because of the lack of a central KDE solution for 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.

I'm not proposing to change techbase or to move lots of content. All the stuff 
outside of the Projects/ space is perfectly fine and goes very well along 
with the original goal of techbase.

The focus would be very clear. Techbase for polished high-quality technical 
information for external people, communitybase for community internal 
information.

-- 
Cornelius Schumacher <schumacher at kde.org>