Reorganising techbase around "Contributor Paths".

[Aaron J. Seigo]

On Wednesday 01 October 2008, Stephen Kelly wrote:
> As far as I know, the focus of techbase is for documentation, information,
> policies, schedules etc around producing KDE products, and bringing new
> contributors into that.

not just contributors, but yes.

> Aspects include coding, translation, documentation,
> art, bugfixing etc.

the focus to date has been on technical aspets: coding and system 
administration.

> However, currently techbase is mostly structured around development.

yes, and that's been, at least to this point, purposeful.

> http://techbase.kde.org/Welcome_to_KDE_TechBase
>
> On the homepage we have
>
> * Setting up a KDE development environment (/Getting_Started)
> * Developing with KDE (/Development)
> * KDE System Administration (/KDE_System_Adminitration) (Should be on
> userbase I think)

userbase is about end user information and community.

the sys admin stuff on techb ase is really about more "pro-level" topics.

keeping clarity in mission on each site is important to keeping them useful 
for the intended audiences. by making user base too technical, we'll lose 
certain people from it; by putting sys admin stuff in amongst end user 
tutorials, we potentially make them harder to find and certainly send the wrong 
message about what sys admin tasks are with kde.

> * Join the KDE Team and Contribute (/Contribute) (This is all about dev,
> but with a link to kde.org/getinvolved.)
> * ISV Information (/ISV) (Some of this is way out of date. Should it be on
> a wiki at all, or is www.kde.org better for this stuff)

it needs to be done up properly, i think. www.kde.org is not really a great 
place for that .... what www.kde.org is for is a whole other topic that we 
probably don't want to get into here? ;)

> * KDE projects (/Projects)

i'm on the fence as to whether this is the right site for these, or if we 
should have a wiki infrastructure that lets us set up individual wikis quickly 
and easily. right now it's the pragmatic choice.

> Techbase might have started out being all about development, and we now
> have a lot of good development tutorials.

lots, but not enough =)

> We also have a lot of other great
> tutorials on internationalization and documentation etc, but the
> organization of techbase doesn't make them easy to find.

the i18n tutorials are primarily for developers, however. the ones that aren't 
aimed at developers, i agree.

> I'd like to see techbase reorganized (or at least its homepage and
> navigation structure) around contributor paths.

that's not really the aim of techbase today, of course. it's a bit more 
focussed than that.

> Something like:
>
> Contributor Paths (/Paths)
> Learn to create KDE software (/Paths/Developer)
> Learn to create KDE artwork (/Paths/Artist)
> Learn to create KDE user documentation (/Paths/Documentor)
> Learn to translate KDE (/Paths/Translator)
> Learn to squash bugs and test KDE (/Paths/Bugsquad)
> Promoting KDE the right way (/Paths/Promotion)
> Learn to make KDE more Usable (/Paths/Usability)
> Learn to create KDE websites (/Paths/WWW)

i love this concept, though really it's what http://kde.org/getinvolved/ is. 
so the question is: where does it belong?

moving it to techbase makes sense for two particular reasons, imo: it's a wiki 
so it's easier for people to build up around and we have the Contribute/ area.

so if we took http://kde.org/getinvolved/ and migrated it to Contribute/, and 
then forward http://kde.org/getinvolved/ to Contribute that could make sense.

promo ... i'm not sure it's best served by techbase, but it could certainly be 
at least covered in the Paths concept.

> The /Schedules, /Projects, /Policies structure probably doesn't need to
> change imo. /Developer/Tutorials could be moved to /Tutorials and kept as
> an index of all tutorials.

so that developers run into art, and artists run into developer tutorials? 
shouldn't we be separating the tutorials into target audiences?

> Each page would have resources specific to it along with tutorials with
> possibly multiple entry points. Emphasis is on low barrier to entry, so the
> first stop for a developer is not /build/kde4. Now that kde4.1 is on many
> distros, it is not necessary for new devs to build kde4 from scratch with
> all the hassle of dependancies, learning to use svn etc.

yes, times have changed and that area needs to be updated to reflect it. very 
good point.

> Also, at the
> beginning, software is created without a need for a compiler. It's possible
> to make a start with something simple. For example:
>
> = Paths/Developer =
>
> This page is a guide to new KDE contributors who want to create software.
> The order of items is the recommended path for KDE users who want to learn
> to create KDE software. The top sections are easiest and simplest to set
> up, and
>
> == Dive in ==

this is an interesting approach and one that would be useful. we should still 
keep the topical arrangement that we now as well, however, as it is a 
reference platform for developers, not just a way to get new devs in. of 
course, this "Dive In" structure could simple be a page of links into that 
same body of tutorials.

at some point we also need to make the topical categorization page a bit more 
approachable without diminishing its reference value...

> == Resources ==


> Anyone want to expand on this or comment? To make such a reorganization of
> techbase worthwhile would require buy-in from many different groups

then you should be talking with kde-artists at kde.org, kde-promo at kde.org and 
recruiting active hands there.
 
> Additionally, if there are people willing to join it, it might be a good
> idea to have a kde-new-contributors@ ml for people who need a kick in the
> right direction or more interactive help, mentoring etc.

hm.. and then they have to transition at some point? and who would be there to 
guide them? i think kde-devel at kde.org is a good starting point, we just need 
to let people KNOW that it is ...

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20081001/e6d296dd/attachment.sig>