I haven't decided, what I'll work on, yet. There are four projects I'm thinking about. I entered all of them in openFATE for now, will sleep for a night, and then take a decision tomorrow morning, when I'll start hacking. If you have input, preferences, what you would like to see happen, or if you would like to join me in one of these projects, please let me know.
These are the projects I have in mind:
Developer sprint support tool
We have discussed this a couple of times in the KDE community, as there are happening a lot of sprints there, and it would be great to have a tool, which supports taking care of the administrative aspects, helps with reporting of results, and supports the productive process. This would be a nice one-week project, especially, if somebody else would like to join the fun and help developing it. It would certainly also benefit openSUSE and other communities.
Read more in openFATE #311141.
One-click appliance installer for SUSE Gallery
Once-click install works nicely in openSUSE for packages. But we don't have a comparable mechanism for appliances on SUSE Gallery yet. It would be great, if you could just click on a button on an appliance page in SUSE Gallery and the system would automatically take care of installing the appliance, so you could use it right away. This could simply be downloading it and running it in KVM or something different depending on the type and content of the appliance.
Read more in openFATE #311142.
Alternative configuration backend for KDE applications
This is a fun idea from the area of cross-desktop configuration. It wouldn't be the first attempt to come up with some cross-toolkit, cross-desktop, cross-platform configuration system for desktop application, but I'm not aware of any attempts from this angle so far. The idea would be to extend kconfig_compiler to support other configuration backends than just KConfig. This could be QSettings, or dconf, or something completely different. There probably are some practical obstacles I didn't consider yet, but it would be interesting to see, if it's possible to move KDE apps to use a GNOME configuration backend by a simple recompile.
Read more in openFATE #311144.
Humane address book for the cloud
This project goes back to some of my roots. Something like ten years ago I rewrote the KDE address book library and worked quite a bit on KAddressbook, the application to handle contacts in KDE. Back at that time I was deep into the vCard format, and thought it would be a good idea to give the user all the power the format provides. While a couple of good things came from that, I now think, that this approach was a bad idea.
Address book data should be handled in a way, which is more natural than assuming people are just a list of alphabetical ordered contacts with a lot of sophisticated data fields. Especially these days, where lots of personal data is stored in the cloud, there must be better ways how to make use of the technology we have at hand, and put it to use in a way, which puts people first, and the way how they think about dealing with their data, information about other people, and their relationships to them.
Read more in openFATE 311143.
"Developer sprint support tool"
ReplyDeletei'm biased here, but i'd love such a tool :)
"Alternative configuration backend for KDE applications"
would it make sense to just try and finish out the pluggable KConfigBackend stuff? maybe even write one that uses dconf-qt?
cool project ideas though :) have fun with hack week!