Restructuring techbase and userbase

[Stephen Kelly]

Stephen Kelly wrote:
> Cornelius Schumacher wrote:
> 
>> 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.
>> 
> 
> OK so.
> 
> Maybe we can grab an hour to talk about it a bit this weekend, and look at
> what parts do and don't need to be moved etc.

Sorry it has taken me so long to post back about this. 

Some of us spoke about some kde website issues last weekend suring the PIM meeting. Thorsten wrote some notes on the wiki:

http://techbase.kde.org/Projects/PIM/Meetings/Osnabrueck_7#Web_Site_Meeting

Most of it is focussed on the PIM websites, but we did speak about some more general stuff around a community wiki and where the division is between it and techbase.

Techbase was originally intended to be a repository of high quality technical documentation, and it is intended to return its focus to that. The communitybase wiki is intended to be a common workspace for community data, team and contributor information, meetups and projects (etc). The content that currently starts with 'Projects/' will likely be migrated to this new 
wiki.

http://techbase.kde.org/index.php?title=Special%3AAllPages&from=Projects&namespace=0

The pages starting with 'Contribute/Bugsquad' about bug squashing days probably also belong on communitybase, as they don't have the same target readers as what techbase is intended for.

http://techbase.kde.org/index.php?title=Special%3AAllPages&from=Contribute/Bugsquad&namespace=0

Additionally there are many pages starting with 'Localization/fy' (Which seems to be dutch) which would probably belong on communitybase instead of techbase.

What definitely does belong on techbase is Policies, Schedules, Licensing information, System administration (Kiosk mode etc. Not stuff which belongs on userbase) and tutorials on how to use products from KDE (libs etc), the build system etc. The content on techbase should be aimed at both experienced Software Engineers and interested users of KDE who wish to become contributors (from the very beginning). 

The communitybase is intended to be for pages that the various teams within KDE wish to create to organize their team. Teams take a top-level url (community.kde.org/KDE PIM, for example), and choose their own url scheme beyond that (ie, use subpages and few top level urls). Such a page would include information on how to join the team and current projects being worked on by the team. 

Information on how to contribute to the team would likely be on techbase however, as third parties which are not interested in joining a team would also be interested in such content. For example- How to create an akonadi resource, how to create an akonadi application, how to test/debug akonadi resources, how to create plasmoids, how to create icons (and use cmake to include them), how to create oxygen style icons (to be consistent with the rest of the system), how to translate, write documentation which appears in khelpcenter - All belongs on techbase.

The team which would be an exception to this would be the promo team, as contributing to the promo team is more of a community thing and not something third parties would get involved in except where they chose to.

We also spoke briefly about translations and came to the conclusion that as the language of using KDE for third party development and of contributing to KDE is English, techbase and communitybase do not need translation in the same way as userbase, though people will probably still want to translate them. The issue of maintaining multiple mediawiki installations for translations seemed like a large maintenance burden, so we thought sticking with the current scheme of code in brackets at end would do for now and to check what other wikis do. Also, some translations have only one or two pages translated, so setting up wikis for all language codes there are teams for in KDE may be a way to use more resources than necessary. The biggest non-wikimedia wiki I know of is wikitravel, and they have some pages which must be translated, and then they set up a new wiki at travelwiki.org/<Language_Code>/.

http://wikitravel.org/shared/Language_version_policy

It's obviously quite a mature wiki and with many more people willing to be admins than kde has, so I'm not sure that kind of thing would work for KDE.

Danimo (Who is not on this list as far as I know) is talking about this issue on his blog, so if you want to discuss this I don't know if this mailing list or his blog is the best place to do so, as he is the technical contact.

All the best,

Steve.


> 
> All the best,
> 
> Steve.