Before starting: I'm not really sure about *where* to put this, so excuse me.

As you may (not) know: KDE is lacking active contributors and real developers to deal with the ammount of current work:
Several applications are completely unmaintained, and people only fix them if they produce compilation errors; but there are no people to take care of their bugs and fix them properly.
Regarding the maintained applications, their main developers are doing a really good job, but they need more helping hands in order to handle the ammount of bug reports and feature requests they have.

A lot of people from the BugSquad (and that includes me) have been working on reducing the ammount of bug reports in the bugtracker site (bugs.kde.org) and improving the quality of the genuine reports; but this is not enough. Even when we spend a lot of hours a day triaging reports, some genuine ones stay there, unfixed, even after a long time. (there are really old reports)

--
In order to improve this situation and to give the KDE the opportunity to *shine* I'm planning something like a "recruitment promo". (I'm going to need help with this and the all organization, that is why I'm asking you (forum users) )

I have been working on an internal list of unmaintained applications, and other work which should be done: http://techbase.kde.org/Contribute/ImportantWorkToBeDone : As you can see the list is not small, and even includes great apps. Sadly enough, the list may be still incomplete.

--
We need people, more people actively contributing with KDE, specially devs; and we would need people knowing about specific topics and code.

There are a lot of small bugs to fix, but if you don't really know the code you may spend a whole day trying to discover it: that is not really productive. We need some "ninja teams" of devs (which should be trained by learning the code and by the current mentors/ninja/main-devs of every KDE technology).

Blauzahl, from BugSquad team too, has also summarized the whole idea as: "we want more redundancy and less single points of failure"; we should not depend on only one developer (who may vanish) for each technology.

--
Now it is your time to give me feedback about the whole bunch of (bad organized) ideas I am proposing here. I hope you understand the problem and sorry about the mess.

Thanks in advance to everyone.
Regards

Darío Andrés
(BugSquad Team, DrKonqi2 dev, general "bug-fixer")

I always had in mind to do more promotion in local universities and technical high schools (or whatever those are called in your country). We should prepare a leaflet we could send or bring to the IT department to do some promotion, maybe getting in touch with the professors/assistants/PhD students and such and ask them to help us promote collaboration on KDE.
The leaflet should include links to the techbase wiki, the forum and the devel mailing list as well as to #kde, #kde-devel and #kde-bugs so we can point people to the work waiting to be done.
Seeking for maintainers is an arduous task and I am sure it's far from being junior jobs, but it would give us some more momentum. The more people we are, the more likely it is that orphaned applications find a maintainer. Of course it is illusory to think that those applications will find a maintainer very fast, as people tend to flock to the more "public" stuff.
I propose you send your proposal to the kde-promo@kde.or mailing list as well to get a broader public, I doubt that many of the promo folks read the forum.

BTW, you also should add applications to your list that need much more love because they have only one maintainer who simply can't handle everything alone. There are quite a few basic applications where work has not progressed much in the last months and on which we almost all rely upon.

* Madman is currently reading, "Thinking in C++" and the KDE programming tutorials.

Mamarok wrote:I always had in mind to do more promotion in local universities and technical high schools (or whatever those are called in your country). We should prepare a leaflet we could send or bring to the IT department to do some promotion, maybe getting in touch with the professors/assistants/PhD students and such and ask them to help us promote collaboration on KDE.
The leaflet should include links to the techbase wiki, the forum and the devel mailing list as well as to #kde, #kde-devel and #kde-bugs so we can point people to the work waiting to be done.

Great idea. (and btw, they are indeed called "technical high schools" here)

Mamarok wrote:I propose you send your proposal to the kde-promo@kde.or mailing list as well to get a broader public, I doubt that many of the promo folks read the forum.

I will

Mamarok wrote:BTW, you also should add applications to your list that need much more love because they have only one maintainer who simply can't handle everything alone. There are quite a few basic applications where work has not progressed much in the last months and on which we almost all rely upon.

I'm going to need help with this, as I don't use every KDE app in the official repos. I can get some ~statistics~ of bug reports in the database, about bugs not getting fixed; but that could be not 100% true in all the cases. May be the devs themselves should add their Application to the list (btw, that list should be editable by anyone, so I think I should move it)

I completely agree. More developers could really help to improve the software.

Involving universities could be very interesting. Probably students from universities are people who could be motivated and, not less important, with a lot of available time. Moreover a KDE-University project could be useful for gaining degree points, thesis or PHD.
A mutual collaboration: students give us help on development but they can learn a job (programming)

I'm with Dario

One problem in my opinion is the large amount of duplicate applications.
A lot of manpower is used to create apps that are more or less QT clones of GTK based apps. After the initial creator becomes bored those apps are ballast that has to be maintained.
To make it short: A lot of work as been spent on parts which don't really belong to the KDE core.
If that work would have been used for KDE's core 4.0 would have been useable
However I know that this is not the way open source projects work.

- Kopete: I really like Kopete, a lot more than pidgin - but what is its justification? All that code, just for a QT interface better integrated into KDE?

- Amarok: Another iTunes linke music played. 2.0/2.1 quite buggy. We have Sonbird, aTunes, all those gtk based media players.

- KHTML: (KJS, ...) is a great html engine, KDE devs can be proud on it and its success in all the webkit based browers. But after all, how much has KHTML helped KDE to become a better desktop? Wouldn't have been a little work on gecko to make it better embeddable been enough for KDE's needs?

- Dragon: Why another media player?

......

Linuxhippy wrote:One problem in my opinion is the large amount of duplicate applications.
A lot of manpower is used to create apps that are more or less QT clones of GTK based apps. After the initial creator becomes bored those apps are ballast that has to be maintained.
To make it short: A lot of work as been spent on parts which don't really belong to the KDE core.
If that work would have been used for KDE's core 4.0 would have been useable
However I know that this is not the way open source projects work.

Some bit: Let's do not convert this post in a flamewar. Thanks.

We somewhat need KDE applications to be able to integrate all the KDE technologies and benefits into it. However, I agree that some simplification of the "core" of every application could be useful to reduce duplicated effects.
- Kopete is moving to use Telephaty (I was also thinking about purple (pidgin lib))
- KHTML vs WebKit is a big discussion which is a bit offtopic. About gecko integration... mh I think a Qt version of firefox was released in alpha-unstable-state, but there was no more progress so far.
- Dragon could be replaced with some other player (Kaffeine may be?)
- Amarok is a great and very popular app in the KDE world. Besides that, a lot of the problems it is currently facing are related to Phonon (which needs to get more attention from both KDE and Qt devs (that is already in the list I posted)).

Sorry, it was not my intention to start a flamewar, although I should have known better. Sorry.

After all, thanks a lot for KDE. Its a great desktop environment, and its a pleasure to work with it every day.
Hopefully I will have some spare time left, to work a bit on performance related problems.

Thanks, Clemens

Dario_Andres wrote:There are a lot of small bugs to fix, but if you don't really know the code you may spend a whole day trying to discover it: that is not really productive. We need some "ninja teams" of devs (which should be trained by learning the code and by the current mentors/ninja/main-devs of every KDE technology).

The Forum started a project "Klassroom" (viewforum.php?f=71) to fix bugs in groups with a maintainer who says where to find the code, if the patches are OK (as far I understood this system). Wouldn't it help with this problem?
I asked if the project is dead, cause it wasn't active since start of 2009 I think, and sayakb said that they want to continue it when they've got more time (viewtopic.php?f=9&t=64998).

JanGerrit wrote:The Forum started a project "Klassroom" (viewforum.php?f=71) to fix bugs in groups with a maintainer who says where to find the code, if the patches are OK as far I understood this system). Wouldn't it help with this problem?
I asked if the project is dead, cause it wasn't active since start of 2009 I think, and sayakb said that they want to continue when they've got more time (viewtopic.php?f=9&t=64998).

Yes, I remember that project(and/or "Kourses"?) and in fact, such a work would be really useful to do and keep up with bugfixing. It is also good way for people to start knowing the internals of technology or an application. I hope it can be "reborn" and it can keep going regularly.

Thanks!

The main problem we had with the Klassroom project was the lack of people who were skilled and had the time to hold them. If anyone wishes to help in this regard, please contact us.

Linuxhippy wrote:One problem in my opinion is the large amount of duplicate applications.
A lot of manpower is used to create apps that are more or less QT clones of GTK based apps.

Jsut to make sure: did you check if all apps in your list of examples are actually older than the KDE app you are comparing with?

E.g. that the first embedable Gecko with stable API and ABI was released before KHTML development started.

I happens quite often that such statements are based on assumptions based on prior use.
There is another thread somewhere on the forum showing that quite nicely.

Cheers,
_

Linuxhippy wrote:One problem in my opinion is the large amount of duplicate applications.
A lot of manpower is used to create apps that are more or less QT clones of GTK based apps. After the initial creator becomes bored those apps are ballast that has to be maintained.

The reason is simple: KDE project starts about one year before GNOME project, most KDE applications found its prototype way before GNOME.

It is the Gtk programmers who rewrited Qt in C and duplicated the whole desktop applications in Gtk, and that is for historic reasons. (QT was not LGPL at that time, if QT was LGPL at that time, there will never be gtk clones and Qt applications may be the only applications now.)

Try to blame Gtk programmers if you want.

hmm... May be i would like to join the crew here. But me a new chap for QT (C++) development. So things gonna kick in a bit slow from my side since i have to work part time.

Even in Gnome/XFCE there are quite no of projects which are orphaned now. So it happens every where.

Damn it.If only I knew C++ i sure as hell would have helped.But being an amateur and learning Java developer is not much of a help, is it?