Probably some kind of IdeaToRent program could be useful for collecting and developing ideas in a systematic way:
http://www.ideatorrent.org/ideatorrent http://drupal.org/project/ideatorrent This could even be one of the tasks for the students. Dashamir On 10/15/2011 04:31 PM, todd rme wrote: > 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 -- Dashamir Hoxha GPG: 4F97 4EDE C739 4C3D 361E 16D3 FD06 AA8E 55D5 9B28 In God we trust. Everybody else we verify using GnuPG!
signature.asc
Description: OpenPGP digital signature
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
