Bug Submission and Manipulation Web-based User Interface for debbugs
Mentor: StefanoZacchiroli
Summary: developing a web-based user interface which enable bug submission (i.e. reporting new bugs) and bug manipulation (e.g. changing bug tags, adding comments, sending patches, closing bugs, ...) in debbugs (the Debian Bug Tracking System) without needing a mail access for routine operations
Required skills:
- knowledge of a modern web-based development framework. Frameworks with one or more of the following characteristics will be preferred:
- low footprint
- well-integrated with AJAX-like technologies
- based on languages already used in other components of the Debian web infrastructures (e.g. python, php, ruby, ...)
examples of "welcome" framewords are: Ruby on Rails, Django, Cake PHP, ...
user-level (or greater) knowledge of the Debian Bug Tracking System
- basic knowledge of SOAP
- knowledge of Javascript and AJAX-like technologies
- knowledge of a modern web-based development framework. Frameworks with one or more of the following characteristics will be preferred:
Description: debbugs, the Debian Bug Tracking System, is a core and fundamental component of the Debian project, helping Debian developers in keeping track of bugs. debbugs is being developed according to Debian needs and so far it has always been proven to be the right tool for Debian.
The full-fledged user interface of debbugs is mail-based and enables submission of new bugs and manipulation of previously reported bugs by simply sending mails with appropriate tags to special-purpose mail addresses. This mail-based interface is very handy for users and developers since it's enough to reply to mails received from debbugs adding the needed tags to work on bug reports.
Nonetheless the mail-based interface add the requirement of a mail access to manipulate bug reports. A user without a mail access can't for example report a new bug; similarly a translator with a l10n patch can't work without mail access; again, a developer at an internet point in bug tagging mood but without an email access can't fulfill it's desire (ok, this latter example is unlikely, but you got the picture
) Aim of this Summer of Code project is developing a web-interface for debbugs which is not read-only as the current one, but which enable manipulation of bugs both in form of new submissions and in form of all the other actions which are possible on previously reported bugs. The web interface will be developed entirely separately from the current debbugs code base, since debbugs has been designed for such a separation: - all actions which require changing the status of the debbugs database, will have as their outcome the sending of an email to the appropriate debbugs mail contact;
all actions which require access to the current status of the debbugs database will be implemented on top of one of the available ways of accessing debbugs, prefereddly its SOAP interface
user registration: even if the aim of the project is enabling reporting and manipulation of bugs without mail access, the people working on a bug need to be reachable (for example to inform the initial bug reporter that a bug has been fixed), hence the web interface should deal with the usual registration stuff and initial mail address verification
search for similar bug reports: before letting a user reporting a new bug, the user should be made aware of similar bug report to diminish the likelihood of duplicate bug reports. reportbug does that and the new web interface should do the same (via AJAX-like thingy to improve the user experience)
friendliness: the web ui should be "friendly" with other web-based services to enable its future integration in the current static web-pages of debbugs. For example it should provide a clean URI scheme for its various actions, starting from a bug number.
Links
Debian packages for reporting bugs: reportbug and reportbug-ng
SummerOfCode2008/DebbugsWebUI, SummerOfCode2009/DebbugsWebUI