On Sat, Oct 15, 2011 at 3:19 PM, Lydia Pintscher <ly...@kde.org> wrote: > Heya folks :) > > Google Code-in > (http://www.google-melange.com/gci/document/show/gci_program/google/gci2011/about) > has been announced again for this year. Org applications will start on > Monday and we'll try to get in again given last year's success. The > kids were wonderful. > Google changed the rules a bit this time. If we're accepted we need to > add a large number of tasks at the beginning and can only add a second > round in the middle of the program again. This means we need to start > thinking of good tasks for the kids now. All this small stuff you wish > you had time for - make it a task. If you're unsure if it's suitable > find me in #kde-soc and I'll help you. Tasks can come from the > following areas: > * Code: Tasks related to writing or refactoring code > * Documentation: Tasks related to creating/editing documents > * Outreach: Tasks related to community management and outreach/marketing > * Quality Assurance: Tasks related to testing and ensuring code is of > high quality > * Research: Tasks related to studying a problem and recommending solutions > * Training: Tasks related to helping others learn more > * Translation: Tasks related to localization > * User Interface: Tasks related to user experience research or user > interface design and interaction > > Please think of tasks. I'll go around with a wiki page or similar > later to collect them.
Some ideas (they may or may not be appropriate for this): 1. Rewrite individual or small numbers of plasma widgets in QML 2. Write comprehensive unit tests for a particular module 3. Make sure a particular module conforms to its coding style 4. I noticed openSUSE is working on something called openQA for automated testing of software. It might be worth seeing if that could be useful 5. Some sort of easy-to-use tracking and display of page hits and/or search terms for userbase so we know what people are trying to find out or learn 6. Integrate the amarok feedback system into one or more other applications 7. Improve detection and handling of duplicates in Dr. Konqi, such as detecting duplicate backtraces 8. Some sort of fuzzy duplicate search, ideally with some sort of learning algorithm, in bugs.kde.org (or bugzilla in general) that can rank reports in terms of how likely they are to be duplicates to help triagers focus their searches. Bug reports could also be run through this before submission to help users find out if their bugs are duplicates. This could be too difficult for such a project, though. 9. Something in bugs.kde.org to let users report a bug as likely fixed or a likely duplicate. These sorts of reports should probably be prioritized over normal comments since they can help reduce the overall noise in bugs.kde.org, so having a dedicated way to do that would be helpful. Maybe a general way for users to report bugs that should probably be closed but that they do have permission to close themselves. Once again this might be better done in upstream bugzilla. 10. Scientific and technical QML components like plots, axes, meters, dials, LEDs, thermometers, etc. Each person would either do one such component or a small number of them. The goal would be to reproduce the stuff offered by the QWT project in QML. 11. Remove all Qt3support or KDE3support instances from one application or part of one application (depending on the size of the application and number of such instances) 12. Integrate a simple, low-bitrate screencast tool into both KDE and userbase so it is easy to make and upload visual walkthroughs of various tasks. It should ideally be dedicated to this tasks, with annotations and automatically pausing after each stage so the user can do it themselves. 13. Make an interactive problem solver for Userbase that directs people to particular articles based on their responses to a series of questions. 14. Integrate userbase with the existing KDE help system. This would probably involve two projects, one to have userbase search in the help system (but would just show links that open the page in a web browser), and a second to display userbase web pages directly in the help browser. 15. Fix the search in KDE help. Maybe use strigi to index the help and man files. A second project could be something in nepomuk to automatically cross-reference help pages based on the mention of specific applications or tasks in other help pages. 16. Packagekit help integration, to automatically try to download documentation for an application when the documentation cannot be found on the system. This is already available for debuginfo and codec packages so there is a basis someone could use to get this started. 17. Improvements in how .xsession-errors is handled by KDE. Currently applications often dump a large amount of informationt there even when debug data is turned off in kdebugdialog.. 18. Automatically enable and disable debug files. Currently you need to manually enable or disable the debug information kdebugdialog, and if it is off my impression is drkonqi cannot use it. Perhaps have it off by default, and have drkonqi turn it on when it needs it then turn it off again afterwards. Turning on the debug information manually would still be possible for developers. 19. Integrate GHNS into one system settings module or application that does not currently support it. Examples include: personal image, bespin and qtcurve styles, and perhaps others. 20. General usability overhaul of the File Associations configuration. It needs quite a bit of work. 21. Go through and make sure all (or some subset of) lists that can be re-ordered support drag-and-drop reordering. Many lists still require you to use buttons to re-order objects, which is good to have for accessibility reasons but is not as easy with mice. Do the opposite as well, make sure lists can be re-ordered with buttons if accessibility requires it. 22. Many applications have menu entries and.optional toolbar entries without icons. Probably going through some subset of applications and, where possible, assigning existing icons to those would be nice. Another possibility would be a card-sorting poll for which icons should be used in those cases. This would only use existing icons, or at least icons that are in the spec even if oxygen doesn't implement them. 23. When building KDE applications I see a lot of warnings about icons that are not the size that the folder says they should be. Perhaps going through and checking and fixing oxygen icon sizes would be good. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
