Reorganising techbase around "Contributor Paths".
Aaron J. Seigo
aseigo at kde.org
Thu Oct 2 04:51:07 BST 2008
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
> However, currently techbase is mostly structured around development.
yes, and that's been, at least to this point, purposeful.
> 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
> 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...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel