Reorganising techbase around "Contributor Paths".

[Stephen Kelly]

Hi,

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. Aspects include coding, translation, documentation,
art, bugfixing etc.

However, currently techbase is mostly structured around development. Other
aspects have been added in places but the main navigation structure of it
does not really reflect that.

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)
* 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)
* KDE projects (/Projects)

Techbase might have started out being all about development, and we now have
a lot of good development tutorials. 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.

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

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)

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.


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

Writing plasma scripts   <-- Possible entry point for new dev. Page contains 
       links to plasma tutorials with scripting languages
Using KDE in bash scripts.    
Writing simple KDE-python applications   Maybe Kubuntu has some resources 
       for this.
Writing kross plugins          Page contains links to tutorials on creating 
       kross plugins for whatever apps support them
Writing other plugins, kioslaves etc.
Writing a simple KDE c++ application     We already have about a 7 tutorial 
       series on this. <--- Possible entry point for more experienced coder. 
       Introduces some of KDE framework.
How to use CMake
Fixing bugs and sending patches.        Including EBN stuff.
Differences between Qt and KDE apps     cmake, not qmake, actions, i18n etc.
Anatomy of a complete KDE app     Tutorials on using Config, i18n, designing 
       for plugins, printing from a kde app. Also recommendations for simple
       existing apps for new devs to contribute to.
Writing apidox
Maintaining a KDE application
Getting your application to users    kde-apps, kdereview etc.
Using the pillars of KDE4        Solid, akonadi, nepomuk, dbus, decibel, 
       phonon, ghns etc tutorials. They probably don't belong in every app
Building KDE from SVN.
Design Patterns in Qt/KDE        GoF patterns implemented within Qt/KDE.
Optimisation                    Understanding valgrind output, algorithms...


== Resources ==

api.kde.org
kde-devel@
lxr.kde.org
doc.trolltech.com/latest/
qt-center.org
qt quarterly
qt-interest@
qt4-preview@
qt faq
kde examples (?)
qt demos
qt examples


#kde-devel
#qt
#plasma
userbase/how_to_use_irc



etc. For artists, I'm guessing here. I haven't seen any info on techbase on
how to create KDE artwork, but I'd really like to. Currently there's only
dead links to kde-artists.org around the place.

==Dive in ==
backgrounds
logos
www
icons
sounds
themes
plasma themes
Putting your art on kde-look
Creating art consistent with the oxygen style.

== resources ==
inkscape
The oxygen palette



for promotion:

== Dive in ==
What is KDE     --- Be Free etc.
What is a KDE user   - Depends on what KDE is, eh?
Being honest about KDE4
Logos and images for your blog.
Creating a screencast
Writing dot articles
Writing release announcements
Reacting to misinformation
Manning a conference booth
DIY marketing materials

== resources ==
kde-promo@
planet.kde.org
dot.kde.org


usability:

== Dive in ==
What is the HIG?
Reviewing KDE apps - What to look for.
Using qt designer to fix usability issues.
Fixing usability issues in code.




Anyone want to expand on this or comment? To make such a reorganization of
techbase worthwhile would require buy-in from many different groups, and a
fairly concrete plan.

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.

Best regards,

Steve.

PS: Is techbase favicon the kde3 logo?