Things to be figured out:

Documentation: Do we want to go for the *.qch road?
Templates: Are the ones we have in kdesdk/kapptemplates enough?
Examples: are those enough? How do we comple one of those separatedly?
QtQuick: How far should KDevelop integrate such language?

Probably at the moment KDevelop is quite optimal when it comes to the day to day development of a C++ developer/KDE Hacker. Making an SDK on top of KDevelop, I think it would mean to fulfill the following use cases:

Easily debug KDE plugins (e.g. KIO, kded, plasmoids)
Improve discoverability of KDE technologies. Good examples and templates integration.
Integrate as much as possible the official set of technologies while developing a project. Those would be: C++, Qt, KF5 and QtQuick/QML.

Notes from the KDevelop Vienna Sprint 2012

Remote/Embedded Development

Someone should add a "deplyoment" concept to our launch/build tools, such that we can use e.g. CMake/QMake for cross compiling and afterwards deploy some binary blob onto a device.

Better KDE Debugging

It should be simpler to debug e.g. an KIO slave or a KDED plugin or a Plasmoid or ... Maybe by adding different/special launch configurations for these things or so... What about a Gammaray plugin?

QML

One way or the other, QML will stay and we should support it. Thus lets work on a language plugin and integrate the qmlviewer and stuff like that.

Documentation

Thanks to the .qch integration it should all work already. We should ensure it does. We could also think about adding a 'getting started' section to the welcome screen that has shortcuts to download the most common .qch documentations e.g.

KDE/Qt Examples

The new file templates stuff should help a lot here. But we could/should add a new provider for KDE and Qt examples. Also, we must ensure that these official examples have a high quality. Also we should write/extend the KDevelop examples, i.e.: toolview, language plugin, app wrapper (like quanta), ...

Unit Testing

The unit testing branch should be merged and we should ensure it works nicely. E.g. we want to hide unit tests from the launch configuration.

Launch Configurations

Once the unit testing is in, we could automatically add launch configs for targets in a project. Also (or alternatively?) we could store launch configs associated with a project target (opposed to scripts or running an absolute path) in the project.kdev4 file such that it can be shared between developers.

Project Page

The Project Page idea should be revived and implemented. Sharing meta data and social aspects around community projects should be cool.