Re: [KDE Usability] tasks for Google Code-in
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
Re: [KDE Usability] tasks for Google Code-in
On Sat, Oct 15, 2011 at 16:31, todd rme toddrme2...@gmail.com 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
Re: [KDE Usability] tasks for Google Code-in
On Sat, Oct 15, 2011 at 17:33, Dashamir Hoxha dashoho...@gmail.com wrote: 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 No Google has its own system for that later that we need to use. Also the tasks are not of a scope that needs a lot of discussion/development. This could even be one of the tasks for the students. We need the tasks before the kids start. Again: no need to cross-post to all lists. For questions/discussions find me in #kde-soc or email me please. Cheers Lydia -- Lydia Pintscher KDE Community Working Group / KDE e.V. board member http://kde.org - http://about.me/lydia.pintscher
