Final Report Prepared by:
Bugs2.0
Group members:
Hadhrawi, Mohammad,
Hilden, Jakob,
Kumaraswamy, Mouly and
Wang, Ning
December 4, 2008
Bugs2.0
School of Information, University of Michigan
Ann Arbor, MI
bugs20@googlegroups.com
Table of Contents EXECUTIVE SUMMARY
1
INTRODUCTION
3
CONTEXTUAL INQUIRY
4
Personas & Scenarios
5 Comparative Evaluation
7 Findings
7 DESIGN
8
Primary Requirement
8 Secondary requirements
10 Interaction Design
12 IMPLEMENTATION
Final Report
16
System Architecture
18 Infrastructure Setup
20 Database Design
22 Bug Tracking Server
23 Bug Submission Client
25 UI Design
27 EVALUATION
28
CHALLENGES
29
FUTURE WORK
31
CONCLUSION
32
RELATED LITERATURES
33
APPENDICES
35
Final Report
I. EXECUTIVE SUMMARY Bugs 2.0 is an attempt to improve the bug tracking process in general and to make bug tracking software easier to use for regular users in specific. The motivation behind it was to build a system that would improve the collaboration within open source projects. In order to achieve the stated goal we starting out doing contextual inquiry to increase our understanding of the bug tracking process and to identify socio-technical gaps in the current systems and processes. Among others, our main finding was that there is a major disconnect between users and software on the one side, and developers and bug tracking system on the other side. Based on our findings we came up with a design that brings the bug submission right into the context of the software and thereby bridges the gap mentioned above. It also includes more features to reduce the effort of triaging1 , increase the relevance of the bug information, and improve the communication between users and developers. We implemented the design in form of a JavaScript bug submission client that can be easily embedded into existing web applications, a bug tracking server for the storage and management of the bugs, and an API connecting the two components. Our implementation makes it considerably easier for users to submit bugs, since they can do it right from within the context of the software. In addition, the bug submission process is designed to make it much more likely that users provide the kind of information that 1
Process of finding duplicates and prioritizing bugs. Final Report
1
developers are looking for. It also provides additional information for the developers that can be used for triaging the bugs. All in all, we believe that our system considerably improves how the bug tracking process is connecting users and developers and thereby can help to produce better and more usable software.
Final Report
2
II. INTRODUCTION Our team has a common interest in open source software, hence we wanted to build a system to improve collaboration within open source projects. Open source projects are typically dominated by technical people.
On the one hand this allows for a very
efficient – in comparison to other CSCW systems – collaboration using computer systems, but on the other hand it also limits the contributions and feedback from other users, which can result in less usable software. Therefore we wanted to build a system that makes it much easier for regular users, with less technical knowledge, to contribute to open source projects. One of the collaborative computer systems that open source projects use are bug tracking systems. They are used to gather bugs in the software, to track who is working on which bug, and what the status of each bug is. Bug tracking systems have been used internally within software development teams for a long time, but the combination of open source projects using them and making them available on the internet have brought them to a wider audience. In recent years, the proliferation of agile development processes has placed greater importance on bug tracking. The system have developed from tracking only software bugs to more general issues, and have become an important ways of closing the loop between users and developers of a (open source) software. This makes bug tracking systems a very interesting CSCW system and this is why chose to work on this system to better support collaboration in open source projects.
Final Report
3
From our previous experience with open source projects (like SourceForge, Gallery, Sakai) we knew that these bug tracking systems are almost exclusively used by developers, which creates a lack of knowledge and feedback about the usage by regular users of the software. So our major goal was to improve bug tracking, so that it would be more accessible to regular users. In addition to that we also wanted to look into other aspects that could be improved about bug tracking software and the way it is used. In order to check our assumptions and to learn more about the bug tracking process and the problems that different user groups run into we started a contextual inquiry phase.
III. CONTEXTUAL INQUIRY In order to design a system that takes current bug tracking systems into the next level and make it more productive in a Web 2.0 environment, we have to understand the current solutions/systems and their users along with the gab in between. So, we found that interviewing users and competitive analysis will be the best approach to that solution. Starting with the interview process, we conducted seven interviews with users who contributed to different open source projects in various roles. Some of the users roles are a triaging (scanning bugs for duplicates and deciding which bugs should be fixed), reporting bugs and program managers.
Final Report
4
Personas & Scenarios 2 It shaped our understanding of users, their problems with the current systems and their expectation from a bug tracking system. The three categories of our personas describes the type of interactions users level of contribution to the system. (Refer to the Appendix for detailed personas and scenarios) Those are:
Users End Users of the software who reported bugs they experience to systems. We found that the major contributors to these systems are users with little technical background. Sometimes, users try to don't report bugs to mainstream open source projects (like Mozilla Firefox) since they expect other users to have reported it. Also, they expect feedback to their have reported. Another problem is to access another system just to do additional task. On top of that, some systems make it difficult to report a bug that make the user not to contribute to that project based on the type of questions used in such systems.
Developers Basically, those are users with rich technical background. We found that the majority of the developers are motivated users who like to contribute to the community and have other work to do. That means they are busy people and have 2
Check Appendix E for more details Final Report
5
other priorities than working on such projects. Also, they receive a lot of feedback of the same bug, which sometimes they have to look at these reports that have redundant information over and over again. They usually read users description on bugs and most of the time they find it missing important information. They use emails to request additional information from users and to share information about bugs status and details among other developers.
Program Managers Project Managers allocate tasks within an open source project and ensures adherence to agreed timelines and other commitments. They have same level of knowledge as developers or sometimes better. Project managers are responsible for triaging (determining bugs similarities and prioritizing bugs). This process wasn始t clear to us at the beginning. Part of the task for that particular user is to assign bugs to different developers after evaluating them. Besides, he has to maintain the status of bugs and make sure that it is up to date. Project manager uses emails as the main source of communication with the developers. The next step was comparing the current bug tracking systems and learn more about them and their features. That helped us in finding the necessary features that should be part of our system and what are not. We were also able to spot the current trends in bug tracking systems.
Final Report
6
Comparative Evaluation 3 We took four bug tracking systems and evaluated and compared them to each other. These systems were: Trac, Launchpad, Bugzilla and SourceForge. Most of those systems host open source projects, which users use them to report any bugs appeared in these projects. That was one of the problems that came up during our research. That is, users have to access a different system to report bugs, which is an extra effort that prevents many users to report bugs. We used this evaluation to come up with more detailed features for our system. That includes fieldsĘź types, optional fieldsĘź types that can be added by other open source projects to our system and bug status. We used these evaluations along with the study of the users needs (from the interviews) to produce a list that summaries the results/findings of our research. In addition, we used these results to come up with a list of main and secondary features for the system design, which will be discussed later in the report.
Findings These were the major findings that we gathered from our contextual inquiry: • Users consider the bug tracking software to be a separate system. They were unhappy to constantly visit another system to report the defects and check the status.
3
Check Appendix F for more details Final Report
7
• Developers very often have to have a conversation with the bug submitter to clarify and gather sufficient information to resolve the defect. • Developers do not not like triaging the bugs. They consider it to be on overhead and want to spend minimum time in triaging. • Traditionally bug tracking systems have worked in isolation. Each bug was treated as an independent object. But the latest bug tracking programs are emphasizing on having connections between bugs irrespective of their project. • Comparative evaluation showed that social features like Wiki, sharing bugs across projects, integration with email are becoming common.
IV.DESIGN The purpose of the contextual inquiry was to increase our understanding of the bug tracking process, to identify the user roles involved in bug tracking and to determine their incentives and challenges. In other words we wanted to identify the socio-technical gaps in the present bug tracking systems. The awareness of this gap will naturally lead us to the requirements for our implementation.
Primary Requirement After conducting the contextual inquiry, we had brainstorming sessions to enlist primary and secondary requirements for our new system. An important finding from contextual Final Report
8
inquiry was that users, who report bugs, perceived the bug tracking software as a different system. Reporting bugs is not the main goal of any users. They are willing to report bugs to make a contribution to the community, as an act of reciprocation. But the bug tracking system posed a significant barrier to these end users. Hence our primary objective was to remove or lower the barriers of report bugs. Since the users were reluctant to interact with another system to report bugs, a simple design was to build a “bridge� between the two systems. Many desktop applications allow users to provide feedback and report application crashes using the same application, Mozilla Firefox is an example. We wanted to extend the same functionality to web applications. Current web 2.0 applications demonstrate how the usage of open APIs a n d s t a n d a r d s e n a b l e s r e l a t i v e l y e a s y a n d e ff e c t i v e d e v e l o p m e n t o f connections/"bridges" between different system. Hence we found a prototype implementation of our design to be feasible given our time constraints. To help us develop our design further we choose WordPress to contextualize our solution. WordPress is an open source blogging software managed by a large community. The WordPress project uses Trac for their project management and bug tracking. We wanted to design a solution that will allow WordPress users (and users of any other web application) to submit and track defects without leaving the application. This would significantly decrease the effort to submit a defect.
Final Report
9
Secondary requirements We identified secondary requirements for our implementation that could be built upon our bridge solution and address other CSCW problems that exist in our problem space. Scalability is a challenge facing many web applications. With an exploding user population and data surrounding their activity – new solutions are required for large scale web applications. One of the other CSCW problems that we learned about during our contextual inquiry was, that "triaging" the incoming bugs requires lot of manual effort. "Triaging" mainly refers to scanning the incoming bugs for duplicates and other anomalies like insufficient data to prioritize the defects. In addition "triaging" also refers to the prioritization of bugs and potentially assigning them to specific developers. If our proposed solution to decrease the effort to submit bugs is successful, it would lead to a proportional increase in demand for triaging. Therefore, we designed two solutions to alleviate this problem. First, users reporting bugs will help identifying similar and potentially duplicate bugs; thereby some of the effort required for triaging can be "crowd-sourced" to the users. We split the bug submission into two stages. First stage is for collecting the actual defect description. In the second screen the users can optionally provide data like: marking similar bugs, listing the steps to recreate the bug. From our interviews we found that this information was critical for developers, but users didnʟt consider them to be essential. Although users can choose to not enter this information, we would provide
Final Report
10
psychologically motivating messages to decrease chances of them skipping the fields. The psychological principles of Commitment and Consistency state that people want to be consistent with their past actions. We would use this principle by informing users that ʻtheir defect has a better chance of being resolved if they fill the following fieldsʼ. We think that users would fill the form in order to be consistent with their earlier decision to report a defect so that it can be resolved. Another problem in large scale bug tracking system is the difficulty in prioritizing the defects that need to be resolved. Systems like Bugzilla providing voting feature – users can vote on defects to show their preference. This social feature can aggregate the preference of the community. We want to extend this idea by creating a “bug rank” feature. Bug rank is a meta-metric calculated from other metrics like number of votes, impacted users, duplicate defects, dependent bugs, etc. Bug rank can be a simple addition of all these numbers or the community can determine the weight for each metric in the bug rank. Our interviews revealed that majority of the bugs donʼt get resolved without a conversation between the developer and the user who reported the bug. Many bug tracking systems allows users to engage in a conversation around the bug. The primary requirement of our implementation is to allow users to report bug without leaving their web application. This implementation can also be used as a communication channel between developers and users. So the developer can post her question in the bug tracking system and the user can view the question and provide a response from the Final Report
11
web application itself. This will also provide the right context for the user to answer the questions. For example: if the developer asks the user “what error message you see?� the user can easily recreate and provide the answer from within the application itself.
Interaction Design The system that we envisioned consists of two major sides, the client side and the server side. The client side represents more of the end-user interaction with the system, while the server side represents the developer, triage4 and project manager interaction with the system.
Client-side 5 The first thing about the client side is that it is embedded within the same page of the host application (e.g. WordPress). There will be a small link in that page that will open a small window (widget), which can be moved within that page. This is helpful when users want to copy and paste information from the underlying application to text fields within the bug submission client widget. At the same time it won't block particular parts of the page since it is not fixed in one location. We envisioned the bug submission process for the end-user to be a three step guided process. The first two steps are about guiding the user to report relevant bug
4
Process of finding duplicates and prioritizing bugs.
5
Check Appendix B for screenshots Final Report
12
information, while the last step is more about educating the user rather than collecting information. A small “submit feedback” button is considered to be the starting point to report a bug by an end-user (with/without technical background). When the users clicks on the button, an unintimidating feedback box appears that doesn't request a lot of information from the user. It simply asks for a “title” of the issue, a little of a “description” and some “tags” (keywords) that further describe the reported issue. Among other uses, these tags will be used to query the bug tracking server for similar bugs that will be presented in the next step. The second step will be shown in a larger window that first includes a confirmation of the successful submission of the bugs from the previous step. Furthermore, it includes an second request for the user to contribute more detailed information. That is, to list the exact sequence of what the user was doing before that bug appeared/happened. The reason for asking this is because the developers mentioned that they really need this information to reproduce bugs. If they are unable to reproduce a bug, they won't be able to fix it. Explicitly asking for this will hopefully eliminate the need for the developers to send requests to the users to provide this additional information. In addition to the sequence, users are also asked to select a category for the issue/error they have submitted. Also, they can see other bugs that were reported by other users and determine if they were “similar” to their error, “not similar”, or “maybe similar”. We include this element to ask the user to help with some of the triage work of finding duplicates. In other words, we tried to “crowd-source” some of the triage Final Report
13
process. This second step of reporting a bug is optional and users may skip it, since the information they reporting the first step has already been submitted to the database. Having a second optional step makes it easier and less intimidating for regular endusers to submit bugs just from the first window. Once they have invested in the activity of submitting the bug, it gives them and additional incentive to continue reporting more information about their problem. It should make the submission of the more technical bug information more feasible for less technically experienced users. As an additional incentive make it clear that fulfilling the second step significantly increases the chances that their bug report will be looked at and fixed. At the same time, technical users don’t have to worry more about complicated interfaces and the hassle of accessing and creating different accounts with different bug reporting hosts, to submit their feedback and enhance the quality of open source projects. The last step of the bug reporting process will be shown in a third window. It includes a final confirmation message of their submission, a link for future reference to follow up with the status of their submitted bug report. In addition, there is a section in that window that will educate the users about the steps of the bug reporting process and what kind of paths their bug could take. From the contextual inquiry we learned that the bug reporting process can be pretty long and complex, and that users often don't have a lot of understanding when it takes many months before a bug is fixed, tested and released. In order to visualize this we will show a diagram of the process indicating the different scenarios that might occur during the bug reporting/fixing process; whether the
Final Report
14
developer require additional information, whether it won't be fixed, or if it got accepted what will happen next.
Initializing the feedback submission widget
Server-side 6 As we mentioned earlier the server side represents the developer's, triage's and project manager's interaction with the system. Starting with the home page, these users can either select one of the existing projects or create a new project for a new opens source project. Once they have selected a project, they can access issues that have been reported by all the users, edit them and change their status. At the same time they can create a new issue within that page. That means, they don't have to go the project
6
Check Appendix D for screenshots Final Report
15
website and use the client side to add issues. As the projects vary, program mangers/ developers can customize and add additional fields/questions to match the context and requirements of different projects. For example for WordPress, they could add a question like “What theme are you using?�. In addition, they can assign issues to different users in order to distribute the load among different developers
V. IMPLEMENTATION After we established a good vision of how the system that we wanted to build would ideally look like and what it should do, we had to figure out the best way to implement this. We started out making a couple of high-level implementation decisions and then implemented the individual components. So these are the high-level implementation decision that we made:
The client-server architecture The most general decision that had to be made was to decide where which component of the system was going to "live".
It was pretty apparent that there would be server
component that would be very similar to current bug tracking systems, which would be responsible for storing and managing the bugs, and a client component that would provide the interface for users to submit bugs.
Final Report
16
Focus on web applications In order to establish a feasable scope for our project we decided to exclusively focus on open source web applications (like WordPress, Drupal, etc.) as the host applications for our improved bug tracking system. The reason for that was that the previous experience in the team was mainly in web development.
Rebuild a server-side bug tracking system For the purpose of demonstrating how our system would be a bridge between the open source host application and its bug tracking system, we had to have a server-side bug tracking system in place. We decided to rebuild a simple bug tracking system. This involved looking at current systems and deciding on the most important features that our system would need to have as well.
JavaScript client The major consideration for the client component of our system was that it would need to be very easily integrateable with existing open source web applications. Therefore we decided to implement the entire client using JavaScript. This way it can be integrated into existing web applications independently from the server-side programming language or framework (PHP, Ruby on Rails, Java, ...).
Final Report
17
Use open standards Finally, along the lines of the previous decision about integrateability, we decided to use established open standards for our implementation to make sure it that it can work with any other software that supports those standards. In our case it meant, using an open JavaScript framework for our client and a RESTful API for the communication between client and server.
The RESTful API will use the well established and open HTTP7
protocol for the transportation and JSON 8 for the formatting of the data.
System Architecture The high-level implementation decision described above resulted in the following architecture: The system consists of two major components: 1. A server-side component implemented with Ruby on Rails and MySQL for the storage and management of bugs 2. A client-side component written in JavaScript (YUI) that can be embedded into the other web applications and that allows users to submit bugs from within that application
7
http://www.w3.org/Protocols/
8
http://www.json.org/ Final Report
18
The server-side system exposes its data and functionality through an RESTful API which the client-side application can use to submit bugs and receive data from the server. A RESTful API is characterized by exposing its resources in a stateless and uniquely addressable way. The advantages of such an API is less complex to implement then other web APIs, but yet very universal and powerful. This is how the two components are working together:
1. The Bug Submission Client is integrated into a host application (e.g. WordPress) 2. The client is initiated by the user who wants to submit an bug 3. The user fills out a form with initial information about the bug which is submitted to the Bug Database Server through a RESTful HTTP POST request
Final Report
19
4. The server replies with with the ID of the created bug and a list of similar bugs (formatted with JSON) for the client to display in the second form which asks for additional information 5. Once the user has filled out the second form its content is send to the server again and the bug record is updated with the additional information
Infrastructure Setup To begin the implementation, we needed to set up our development infrastructure. First we needed to install and configure the web application framework, a webserver and a database server on our personal computers as well as our server. Then we needed to install some development tools, and finally to setup the code repository. For our web applications framework we decided on using Ruby on Rails and for MySQL as our database server. As the webservers on our local machines we are using WebRICK (which ships together with Ruby on Rails) respectively Mongrel9. On the server we have a setup with Ruby on Rails running behind Apache in combination with FastCGI, which took us up until the end of the semester to get working. So our server is finally running under the following URL: http://bugs20.kmouly.com After we had the basic software running we had to set up our individual development environments. The environments include the following development tools:
9
http://mongrel.rubyforge.org/ Final Report
20
• An appropriate text editor or integrated development environment (IDE): Aptana RadRails, Notepad++, VI • Front-end software to manipulate the database: phpMyAdmin, SQL Explorer • HTML, CSS & JavaScript debugger: FireBug The most important thing for the collaboration around the code was to set up a code repository. We decided to utilize Subversion (SVN) for that purpose. First we tried to set up an SVN server on one of the team members web server, but then we opted for setting up our project on Sourceforge.net, since they already provide the necessary infrastructure. You can find our project at http://sourceforge.net/projects/bugs20/. After setting up our SourceForge accounts committing the initial version of the code, we had to install an SVN client on our personal computers (e.g. TortoiseSVN or Subclipse) and then check out the code from the repository using the following URL: https:// bugs20.svn.sourceforge.net/svnroot/bugs20. Using the code repository allowed us to always have the latest version of the application on our individual computers, to have the possibility to go back to earlier revision of the code, and to resolve potential conflicts arising from editing the same files on multiple computers. In order to make this work everybody had to update from the repository and commit to it frequently.
Final Report
21
Database Design After our infrastructure was in place, we started the implementation by creating the database design for our system. First, we figured out what entities we will need in any case, these included issues, users, and projects. From there on we incrementally added new entities to the database design. To keep the databases consistent among our individual computers we used the migrations feature in Ruby on Rails. Anytime somebody changed the database the other team member could replicated that change by updating their code from the repository and running the "rake db:migrate" script. If you want to retrace the evolution of our database design you can take a look at the migrations in the "/db/migrations" folder. Here you see the database diagram for the current version of the database.
Final Report
22
Database design10
Bug Tracking Server On the server side, we chose to use Ruby on Rails framework for developing the web and MySQL for storing the data. There were several reasons for choosing Rails and MySQL: 1. Ruby on Rails is an good web application framework for agile web development. Given the fact that the time for our project is limited, we wanted to come up with the application in a quick and easy way. Especially the scaffolding feature - which automatically creates the Ruby and HTML code for basic CRUD (create, read,
10
Check Appendix A for high-resolution diagram Final Report
23
update, delete) operations for the entities in our database - in Rails saved us a lot of time in the implementation phase. 2. Both Rails and MySQL are open source projects which are our primary interests. Also, since we are developing for open source communities, it makes a lot of sense to use open source tools and open standards in our design. 3. The group members were more familiar with Ruby on Rails and MySQL than other alternatives.
Structure of the Bug Tracking Server
!
The structure on the server side is pretty straight forward. Here are the description for the three levels:
1st level Bugs2.0 home page is a portal from where users could see all the projects which are using our application for bug tracking and click on the link to see the issue/bug list for a particular project.
Final Report
24
2nd level From this portal, the second level are the different projects home pages where the issues/bugs are listed. Basic information is showed in this page about the issues/bugs such as title, status, tags, duplicate status and time etc.. Developers and triages have the option to create new bugs here instead of doing that in the client side. Triages usually use this page to check for new issues/bugs and they could also delete issues/ bugs in this page.
3rd level View page refer to the detailed information page for a single issue/bug. The triage uses this page to view the detailed information. She can send message to the bug reporter and comment on the bug here. On the edit page triages or authorized users can update the information about the issue/bug such as change status and category, assign developers to the bug and add new tags to it etc.. If there is a specific need for new kinds of information, triages or project owners can also add custom fields to the project to let the users input more information to help the bug fixing.
Bug Submission Client In our project, the "client" refers to the HTML/JavaScript code that runs in the web browser that interfaces between the end user and the bug tracking software. The client is the bridge to recontextualize the boundary object, in our situation a bug report,
Final Report
25
between the systems (web application like Wordpress and Bug tracking system like Trac). We used Yahoo UI (YUI) Framework for implementing the client. We choose YUI since it supported rendering of dialog windows, handling JSON data, and simplify other web application tasks like making asynchroous HTTP requests. The client side consists of three screens, two screens are used to gather data while the third is used to convey data to the user. The first screen has a simple form with two (or three) text fields for the user to report her feedback. The second screen is used to capture meta data and other non-essential information about the bug. Users have a psychological motivation to complete the second screen after reporting the bug in the first screen. Each screen is written in HTML, upon page load the YUI dialog component is instantiated. As mentioned earlier, the first screen is used to create a new bug report on the bug tracking server. After creating a record in the database, the server responds with the unique of the created bug and bugs in the database similar to it; the response is in JSON (JavaScript Object Notation) format. The similar bugs list returned by the server is used to create a YUI Datasource - which is the a JavaScript data structure that can be used to populate HTML table using YUI Datatable. The YUI data table provides controls for the user to indicate which of the suggested bugs are similar to the bug the user reported.
Final Report
26
UI Design The UI design of our system might look basic and simple. We designed multiple wireframes for the system before creating the current version of the design. We will refer to the previous versions as the first design through the document. Check Appendices B and C for screenshots of current and previous designs of the client-side interaction. Initially, we stared with fixed window that appears on the middle of the screen. That is, it has the look and feel of programs error screens (Mac OS Bugs 2.0 for WordPress
errors, desktop application errors) where it asks you if
Feedback
Report a bug
List of bugs
Chat with a developer...
Recent Bugs Reported by You:
you want to report this issue or not. One problem with such design was the disability of copying or referring to
s No screen shot s
No screen shot
Status The save button is no... Submitted Fixed Bug decription...
Tom E. More details..
More details.. Time takes too lon.. Bug decription...
Status Submitted Fixed Email a developer...
More details..
Title
Attachments Browse Title
Description
problem step1 Screenshot1.jpg
any information from that page. Besides, the window was
Save
Cancel
blocking a big portion of the page and users cannot move it around. Another issue with the first design was the size
Submit
Initial version of the wireframe for the clint-side interaction
of the window (widget) in the client side. What we had before was a fixed window size, which was similar in all the steps (from step one to step three). We wanted to simplify the process of reporting bugs and we were to engage less technical people to such kind of process. So, we found that small windows have less technical feeling of bug tracking process, and users might see it as a small feedback window. (The decision came out based on different resources and papers that were referenced by the course GSI.) Then, the transition from a small window to a larger one gives step two higher attention than the first step and ask the users to commit what they have submitted earlier in step one. Final Report
27
Also, the difference in shapes始 sizes acts like that each window is a one step process. That makes step two more engaging and more fun to interact with and at the same time it is informative for the developers. Both steps are important and even that the second step is optional; the design guides the users in a way that makes them committed to the whole process. Another issue with the first design was the flexibility in the transition among thee steps and the additional feature that makes the first design more complicated but a stand alone widget. At the same time, it requires more time to implement. One last point regarding the design is the bug tracking process diagram. In the first design we dedicated a larger space to insert that diagram, while in the second design we had so simplify it to fit the window size. Basically, that diagram is used to educate users of the bug tracking process in interactive way. That is because we found that most the users complain about the time period between submitting a bug and receiving a feedback from the developers. So, this diagram becomes essential part in out design.
VI.EVALUATION Since we spent most of our time in the design and implementation phases of the project, we did not have lot of time for user testing. We conducted one formal interview with an user who particpates (in roles like triaging and bug fixing) in Ubuntu Project. Informally we presented our system to different people and received feedback.
Final Report
28
The findings from user testing our implementation are: 1. Scalability. Our application works well when the user base is not large. However, when the number of users becomes more, there will be problems such as effectively displaying issues/bugs and identifying the duplicates or similarities of issues. New solutions should be created for large scale web application bug tracking. 2. Back channel communication. We had a prototype for the back channel communication between developers and users to facilitate the information exchange between the two groups. This feature was commented as good design many times during our evaluation in that it simplifies the communication a lot on both sides. 3. User-oriented design. Different from other bug tracking system, our system is more focused on the user side with its aim to reduce user's difficulty in submitting bugs. As a result, more valuable feedback would be received to better improve the project. People like this idea and they think that the system should make the user side as simple as possible. 4. Privacy concerns. Features such as automatically gather user's system information will pose concerns of privacy.
VII.CHALLENGES Our first and foremost challenge was to scope our implementation. We were not interested in recreating a complete bug tracking server. So we decided to implement Final Report
29
only some parts of a typical bug tracking server - such as submission, triaging, and assignment of bugs. Since there were still some opportunities for improvement of current bug tracking servers using CSCW concepts. Nevertheless, we still had to implement a bug tracking server with basic features like creating, updating bugs from scratch. This was our biggest challenge. We spent several weeks to create a functional bug tracking server. Our implementation had features like support for multiple projects, user management, and custom fields. Some of these features, like custom fields, are not present in some of the existing bug tracking servers, but it was also not a central part of our design. The resulting quite functional bug tracking server was the foundation on which we implemented our primary features. Furthermore, our final implementation is a complete web application. This required us to design a database schema, write a web application in Ruby on Rails and design a rich Internet front end using YUI. Not all team members were familiar with this sundry of technologies. Many of us had to learn, design, write code, and debug in new languages or frameworks. We enjoyed learning new technologies, but it was challenging to accomplish in a short time. This was a unique software development experience for us. We were able to sufficiently dissect the application to allow team members to work on different sections. But we needed a lot of meeting time to discuss the interfaces between the software
Final Report
30
components. For example we needed a couple of meetings to refine the server's response to the client upon creating a bug. Finally, setting up the infrastructure for software development took longer than we anticipated. We had to setup a version controlled source code repository (using Subversion), we spend time trying couple of servers before hosting it as a project in SourceForge.net. We also had to get familiar with the basics of software configuration management, collaboration around a single codebase and using a Subversion client.
VIII.FUTURE WORK Because of the time constrain and the workload of this project, some of the features of the system could not be implemented during the time period of this semester. Some of these work came out after our second round of evaluation, and these are the "Bug Rank" and "Communication Channel" Bug Rank: which has been mentioned briefly in the Design section under the secondary requirements. Basically, gives certain bugs some priority so that developer pay more attention to them. and deal more about the scalability issues. Another feature which couldn't be implemented is the communication channel between developers and users, since we found that developers use their emails to communicate with users for clarification questions and that might be unpleasant when there are huge number of users. So, there could be a chatting and notification system between the Final Report
31
developers and the users, and could be implemented in both the client and server side of the system. The notification system allow the developers to know when users who submitted bugs previously, came online and allow them to ask their clarification questions through the chatting system. Also, the notification system allow the developers to track the status of certain users until they come online and might send an email to that developer notifying him/her about the status of that user. To implement such system users must agree to terms and condition for clarification and privacy issues.
IX.CONCLUSION Our system represents a major step towards closing the loop between users and developers through issue tracking. And thereby shaping a more user-centric software development process. It is bridging the gap between developer and user feedback by significantly reducing the effort involved for users to submit bugs, while at the same time providing new benefits to the developers (better bug information, communication channel). We designed a system and were able to proove its feasibility by implementing the major components of it in a very limited time frame. Due to a well though out system architecture using open standards, we believe that it would require only very reasonable effort to implement our design in a real world setting - such as a client plugin embedded in WordPress connecting it with the Trac bug tracking software. Based on our evaluation efforts one of the major issues remaining is the scalability of our system for software with a very big user base and therefore very high volume of bug submissions. But with the Final Report
32
“crowd-sourcing” of similar bug detection and the ranking of bugs we present two concepts to tackle this issue. This is a unique opportunity to significantly improve the collaboration around (open source) software development project and ultimately create more usable software, by the means of a CSCW system.
X. RELATED LITERATURES • High Quality and Open Source Software Practices. TJ Halloran, WL Scherlis. Link • The open source software development phenomenon: An analysis based on social network theory. G Madey, V Freeh, R Tynan. Link • Reitmayr, Ellen.
"Einbeziehung von Usability-Experten in Open-Source-Community-
Projekte: Erfahrungen aus dem OpenUsability-Projekt". Open Source Jahrbuch 2007 • Yeats, Dave. Open-source software development and user-centered design: a study of open-source practices and participants. Dissertation, Texas Tech University. 2006 Link • Cubranic, D. Booth, K.S. Coordinating open-source software development. Link • Justin R. Erenkrantz, Richard N. Taylor. Supporting Distributed and Decentralized Projects: Drawing Lessons from the Open Source Community Link
Final Report
33
• Beenen, G., Ling, K., Wang, X., Chang, K., Frankowski, D., Resnick, P, & Kraut, R.E. (2004) Using social psychology to motivate contributions to online communities. In Proceedings of CSCW 2004. New York: ACM. Pp. 212-221. • Whittaker, S. (2005) Supporting collaborative task management in e-mail. HumanComputer Interaction, 20, 49-88.
Final Report
34
APPENDICES
Final Report
35
Appendix A Database Design
Screenshot of the Database Design
Final Report
36
Database Design
Final Paper
1
Appendix B Client-Side Screenshots
Initial Step
Second Step
Confirmation/Educating Page
Final Paper
2
Movable widget
Small Link
The initial step within a WordPress Environment
Initial step in the client-side (the small window(widget))
Final Paper
3
The second step (the bottom is the similar bugs retrieved)
Final Paper
4
Thank you Thank you, for submitting detailed information about the issue you encountered. If you want to follow up on the progress of the issue you reported, you can check on its status here:
http://bugs20.org/projects/1/issues/xxx What happens next? received
won't fix accepted
assigned
request more information
fixed
reviewed
awaiting response
released
response received
Next, your issue submission will be evaluated and it will be decided on how to handle the issue. This diagram shows several possible routes your issue can take. Be aware, that the process for first replicating and fixing the bug and later testing and releasing the fix can be very long. Here you can find more information how the issue tracking process works and how you might be able to further help. Thank you again for submitting your feedback!
Final step (confirmation and educating users). The middle box show the current status of the report along with an explanation of the cycle, so the user can have better understanding of what’s going on.
Final Paper
5
Appendix C Client-Side Wireframe
Report a Bug Page
Feedback Page
Similar Bugs Page
Final Paper
6
Bugs 2.0 for WordPress
Feedback
Report a bug
List of bugs
Chat with a developer...
Recent Bugs Reported by You: s
No screen shot s No screen shot
Status The save button is no... Submitted Fixed Bug decription...
Tom E. More details..
More details.. Time takes too lon.. Bug decription...
Status Submitted Fixed Email a developer...
More details..
Title
Attachments Browse Title
Description
problem step1 Screenshot1.jpg
Save
Cancel
Submit
First (old) Wireframe Design - Report a bug screen
Final Paper
7
Bugs 2.0 for WordPress
Feedback
Report a bug
List of bugs
What do you think about x... Strongly Agree
Agree
Normal
Disagree
Strongly Disagree
Agree
Normal
Disagree
Strongly Disagree
Agree
Normal
Disagree
Strongly Disagree
It is easy to do a and b... Strongly Agree
I like the x... Strongly Agree
Additional Info...
Save
Cancel
Submit
First (old) Wireframe Design - Feedback page
Final Paper
8
Bugs 2.0 for WordPress
Feedback
Report a bug
Type
Bug ID#
List of bugs
Search
ID or keyword
Bug ID#
Title/Summary
Status
Owner
Created
Edit
Cancel
Detail
Submit
First (old) Wireframe Design - List of similar bugs screen
Final Paper
9
Appendix D Server-Side Screenshots
Projects List Page
Issues Page
Custom Fields Page
Issue Details Page
Edit an Issue Page
Final Paper
10
Server-Side - Projects Page
Server-Side - Issues Page (Add/Remove/Edit)
Final Paper
11
Server-Side - Custom Fields Page
Server-Side - Specific Issue details Page
Final Paper
12
Server-Side - Edit an Issue Page
Final Paper
13
Appendix E Personas, Scenarios & Competitive Analysis
User - Kate Russell
Developer - John Martin
Program Manager - Jake Hither
Competitive Analysis
Final Paper
14
Age: 26 Hometown: Travelocity, MI Martial Status: Single
Degree: M.Sc in Information, University of Michigan Work: part time at the engineering library
Hobbies: Gaming (Rock-band)
Profile
Kate is a second year master student at the school of informa2on. She has a background in computer science and enjoy working on her computer and uses a lot of so;ware applica2ons and interested in trying new ones.
Kate lives off‐campus with a one roommate,
depends on the applica2on size and popularity. If it is a small open source project, she would report it directly. Otherwise she believes that the bug, which she is going to report, is already been reported. That is because there is a huge number of users and the chance of somebody reported the same issue is preCy high. Also, one of her concerns with popular/large open source projects is that the developer may not look at her
and she is a social person. A typical day in
report, which frustrates her. She usually likes
Kate’s life includes aCending two 3 hours
to be updated with any report she submiCed.
classes during the day, check her emails in the class and eat her lunch during the break between the morning and a;ernoon classes.
Things that Kate wants to have in such applica2ons:
Then she go to the library to work and later
Keep in touch with the developers
she goes to the DIAD and work on her
and make sure that they responded to
assignments.
her report An easy way to find where to report a
Kate uses many different open source projects such as Firefox, Pidgin, Word Press, Open Office. When kate finds a bug with such applica2on, she likes to report it. But that
bug A user friendly interface that walks her through the required procedure to report a bug
User
Kate Russell
Goals
she didn’t find any. Since Kate has some Report as many bugs as she can. Improve and increase the use of open source projects.
experience in repor2ng bugs, she wrote the procedure on how the bug happened. A;er sending the report, she didn’t receive any updates about the bug which was frustra2ng. A;er 3 months, she received an email from
Tasks
the developer who’s responsible on such Stay updated with the bug’s status that she reported. Report bugs effec2vely
Scenario I Kate opened the Firefox browser on her machine and logged into her WordPress account. Suddenly, while she was edi2ng an ar2cle, the applica2on was suspended and she couldn’t submit or save her work. She tried to open another tap in her browser to make sure that there is no problems with Firefox. Then she logged in Sourceforge and tried to find the WordPress project to report for the bug. She clicked on the link for repor2ng a bug. Then two text fields appeared, one to enter the bug number/2tle and the other one is to add descrip2on. At the beginning, she didn’t know what kind of descrip2on she should write, because it was to broad. So, she tried to find relevant informa2on on how to report such bug for that applica2on within the same loca2on, but
bugs and asked her to send her addi2onal informa2on (such as, number of tabs that were open in the same 2me, websites name...etc.) and a screenshot if possible. Scenario II Another scenario with Kate repor2ng a bug is when she used Bugzilla and found it kind of messy to report bugs there. There were a lot of op2ons to select for repor2ng the bug and were spread all over the page tat made it confusing to report a bug. So, she thought that the bug was already existed. Then, she searched the web for similar bugs, and yes she found a similar bugs that has been reported earlier. Scenario III When Kate visited the website she found a small tab/sign in the corner of the browser for repor2ng problems and give feedback. When she clicked on that tab, a pop up
window appeared and gave her two op2ons, one is to report a bug and the other one is to give her feedback. Kate was curios about the bug repor2ng process, so she clicked that op2on. She found that she can add a name to that bug, and then a small list appeared that showed similar bugs that have been reported earlier. But, the bug that she wanted to report was not among the list, so she added a new one. Also, she added a descrip2on about the bug and found that there is an op2on for screenshot where she uploaded a picture of the error screen from the browser. In addi2on, she was looking forward to get updates about that bug. One of the op2ons that she found out later was the ability to log in the system, within that web applica2on, and was able to see the status of the the bug that she has reported earlier, which was labeled as fixed. Later, she got an email that says the bug was fixed, and they are looking forward to get her feedback!
Age: 29 Hometown: Fairfield, CT Martial Status: Married Hobbies: Traveling and Swimming
Goals
Degree: BS and MS in Computer Science, University of Connecticut Work: full–2me developer in Pitney Bowes Inc. R&D department
diverse topics in computer science such as Contribute the Ubuntu community by fixing bugs assigned to him as soon as possible Improve the opera2ng system he is using Get sufficient informa2on from the bug tracking system to fix the assigned bugs Have fun in the bug fixing process
Profile
opera2ng systems, databases, networks. But slowly he found himself becoming a programming ninja. So he decided to focus on so;ware engineering in computer science. Around the same 2me, he switched to Linux OS (from Windows) as his development plaaorm. Ini2ally he was not comfortable with Linux, but gradually he became aCracted to it. One of his professors recommended reviewing the Linux code to get a beCer insight into programming. He followed the instruc2on and began to
John was born in a three‐child family in
research on the Linux code base, which
Fairfield in Connec2cut. Due to his father's
aCracted to the system even more.
influence, a huge Yankee's fan, he likes
A;er comple2ng his Bachelors degree, he
baseball very much.
con2nued as a master student in the same
When he was in high school, he showed great
department. Two year later, he graduated
enthusiasm in math and science, which
and got a good offer from Pitney Bowes Inc. a
impressed his teachers. By his hard work, he
top mail‐stream supplier in US. He works
entered the University of Connec2cut to
with Advanced and concept technology
study computer science; a subject which
group to develop new technologies or
interests him. In the university, he studied a
systems for the company. In his professional
Developer
John Martin
work also he uses Linux as the development
A;er dinner, as his wife was washing dishes,
plaaorm.
he opened up his laptop and began to check
Open source communi2es are increasing in
his emails. He found an email with the
popularity in recent years; owing to their
subject ‐ Ubuntu bug assignment. He opened
great contribu2on to people's life. John is
it and found that he was assigned a bug by
very interested in the open sources for two
the project manager. The bug descrip2on
reasons:
read "the screen saver fails to load under
1. Linux is one of the earliest and most successful open source efforts and most of his applica2ons in Linux are open source.
Compiz a;er upgrade to 8.10". Also, there was detailed informa2on about the bug given by the user. He read the content carefully and decided to simulated the user's process to
2. He is greatly inspired by the selfless efforts
recreate the bug. He followed the user's
of developers who are trying to make the
process in his machine and recreated the
open source so;ware even beCer.
bug. He changed the status of the bug to
Ubuntu was released on 2004 and a;er trying it, John switched to it. Ini2ally, he didn't par2cipate in the development of Ubuntu. By and by, he found that there are a lot of things that need to be improved. He became more and more involved in the development community and finally became a developer in the Ubuntu community. Scenario Receive bugs and change bug status
confirm the bug and let others know that he was working on that by sending a formated email with command of status change. Communicate with the bug reporter When he was checking his email, John found that he was assigned another bug which was also about the fact that the one applica2on could not be ini2ated. However, the informa2on given is not enough and he needed more details such as the versions and the system environment from the user.
As usual, a;er his eight‐hour work in PB, John
He formulated the ques2ons that he want
had a dinner with her wife at home. During
the user to answer and send them to the
the dinner, they talked about the plans for
mailing list to get the user's feedback.
the upcoming vaca2on.
Some2mes, this kind of follow‐ups will be
totally ignored by the users and as a result,
changing and status of the bug to solved and
the bugs will face difficul2es to fix. Luckily,
explaining the reasons and the solu2ons of
this 2me, he received the user’s email very
the bug if necessary. He then commit his
soon and got the details he wanted from the
code to the server.
user. Working with other developers The Ubuntu system is a very complex system and he almost cannot do things here without others’ help, so usually several developers would work on the same bug. This 2me, John was faced with a bug that was technically for him to fix and it was the same for his colleagues. So they didn't begin to fix it right away, instead, emails were created in the emaillist to communicate the possible reasons and solu2ons to the bug. The emaillist was created by the bug tracking system at the beginning of the system and would be updated when other developers or uesrs subscribed to the bug. The emails were very effec2ve for the developers in that they explore the reasons of the bugs based on which the developers could begin the next step of fixing the bug. Finish fixing a bug It took John the whole weekend to finish a bug that he had worked on for three weeks. He run the process twice and made sure that the bug was fixed. He sent a email back
Age: 31
Degree: MS in Information Systems
Hometown: Washington, D.C. Martial Status: Married, no children
Work: Project Manager, Hither Co.
Hobbies: Golf, board games and bicycling Goals:
he was promoted to project manager. His company has always used a lot of OS
"Things need to get done!"
so;ware, especially this one so;ware that
Success and advancement for his
they o;en customize for customers. To
company and the OS project
beCer influence the direc2on of that OS
Make sure things get done in an
project, Jake is allowed and asked to spend a
efficient way
certain amount of 2me of the week contribu2ng to the project. Since he has
Tasks:
been with this project for a while he has taken on a leading project‐manager‐like role Steer the general direc2on of the
within the project. In both worlds he is
project
acknowledged for his deep understanding of
Check on the status of the project
so;ware development processes and
Assign tasks/bugs to developers and
workflows, especially within OS
work with them
environments. Lately he has been also a
Weed out duplicates and wonaixs
pioneer of integra2ng user‐centered design
from the bug tracker
methods into the so;ware development.
Profile:
Jake has earned his Master degree in
Although he is not trained in this area he is very open to it and tries to support it in the projects he works on. Especially in the OS project this is very complicated, since the
informa2on systems and started working as a
community around it is inherently technical.
so;ware developer for a so;ware company
But in the project he is always the one that
in the Washington D.C. area. Three years ago
pushes things forward and makes sure the
Program Manager
Jake Hither
project is on a successful path. Success for
his last visit, and takes a look at commit to
him is always measured in the sa2sfac2on of
the code repository. Then he reads the post
the users and how much they are willing to
that have come up in the mailing lists.
pay for it. This makes him a good candidate for a leader of the project and explains his
Managing user feedback
interest in user‐centered design. In terms of
In the bug tracker as well as the mailing list
bug tracking so;ware he has used a bunch of
Jake is looking for feedback from user that
different tools and the bug tracking process
they should act upon. First, he has to figure
has become really natural to him. He has
out which bug reports are new and didn't get
seen bug tracking from both the perspec2ve
worked on yet. In order to do this he sorts
of a developer as well as a project manager.
the lists accordingly. Two bug reports he
In company as well as OS project he hasn't
immediately replies to that they won't get
wriCen a lot of code anymore lately.
fixed since that is something they had talked in the mailing list a couple of weeks ago and
To characterize him a liCle furhter he is a very
decided to not fix it. So he politely points to
pragma2c, forward thinking, success‐
that discussion and says that this won't get
oriented, logical and some2mes a liCle
fixed. As always, there are also a bunch of
pedan2c person.
new duplicates which he has to delete/ merge.
Scenario Assigning and controlling tasks Checking the status
One bug report talks about a use case hasn't
Jake has been on a conference abroad for his
come up in this way yet and that seems to be
company for a couple of days and just
not easily fixable by a developers. So he
returned. Because of his absence he goes
forwards it to the usability person on the
online to check on the status of the OS
team to check whether this is usability
project that he is part of. First, he would like
problem that should be addressed or not. A
to check what has been and is going on and
couple more bug reports he can be assign
who is working on what. In order to do that
preCy directly to certain developers on the
he checks the assignments of the bug tracker,
project, because it is clear that they relate to
checks which bugs changed their status since
certain parts of the so;ware that are
"owned" by these individual developers. A;er he is done dealing with the new reports he checks on older bugs and their progress. For example there has been one cri2cal bug that one developer said he would work on a while ago, but he hasn't goCen back about it yet. So Jake writes him a message to check on the status of that bug. Steering the project One important thing for Jake is to steer the project and to make sure that the issues that are the biggest barriers for the project's success get fixed. In order to do this he priori2zes different bugs differently. The most important bugs get labeled as "blockers", then "cri2cal", and so on. Some2mes there is discussion about this and he has to make sure that a consensus is reached.
Appendix F Competitive Analysis
Competitive Analysis Table
Similar Systems Screenshots
Final Paper
15
Comparative Analysis of Bug Trackers We compared four existing bug trackers to identify their salient features and help us develop the requirements for our implementation of a bug tracker. We choose the following bug trackers based on their popularity, approach towards bug management and type of the product - standalone, integrated, installable or online service. Trac is a light weight project management system. It provides tools like: wiki, integration with Subversion (version control tool), along with a ticket tracking system. The ticketing system is used to track the issues and bugs within a project. Launchpad is a project hosting site supported by Canoncial Inc. It is famous for hosting the popular Linux distribution Ubuntu. It has a bug tracking module. A distinguishing feature in Launchpad's bug tracker is the ability to share bugs across projects. So if an project is being impacted by a different project's bug then the projects can have a shared view of the bug. Bugzilla is the bug tracking tool developed by Mozilla. Unlike other tools that are compared here, Bugzilla is a standalone tool. SourceForge is a project hosting site. It provides various tools for managing open source projects. It has a simple bug tracker.
Product/ Attribute
Trac
Bugzilla
SourceForge
LaunchPad
No. of fields in new bug screen Fields can be hidden or added, values can be preset,
No. of states in bug lifecycle
Reporting Features
New, Assigned, Supports Closed, custom ticket Reopened queries,
20 fields. Supports custom fields
Seven: New, Unconfirmed, Assigned, Resolved, Reopen, Verified, Closed
Seven fields,
Four: Open, Closed, Deleted, Pending.
First user enters the summary of the bug. Then the system presents a list of potential duplicate bugs If the users still thinks it is not a duplicate, then user can enter details: package, security vulnerability,
Search features
Nine states: New, Incomplete, Confirmed, Triaged, In Progress, Fix Committed, Fix Released, Invalid, Won't Fix A liner progression from New to Fix Released
Simple search, advanced search. Can save search.
Can generate reports the on the fly. But the interface is cluttered. Can generate both text based reports and graphic reports dynamically
Simple and advanced search
Provides RSS feeds for the bug tracker. statistics for bug tracker
search by importance, date, etc. advanced search available Filtered search available. But not clear how to setup
Product
Trac
Notable Features •
Ticket work flow can be customized
•
Comments can be added to any submitted bug
•
Allows tickets to link each other using wiki words
•
Email notifications about ticket changes
•
Bugs can be tagged
•
Whining feture: to email users at periodic intervals with bug reports
Bugzilla
•
set deadlines and track time against bugs
•
Keywords can be defined; all bugs containing the keyword are tagged with the keyword
•
Voting: Users can be given a fixed quantitiy of votes which they use for indicating the bugs they would like to be fixed
SourceForge
•
Can mark a bug as private
•
Anonymous bug submissions
•
Users can monitor bugs
•
Users can subscribe to bugs. Subscribed users names are listed in the bug report.
•
Bugs can be converted to question (status is marked as invalid), when an explanation is needed. The new question will be linked to the bug
LaunchPad
•
Bugs can be shared across projects
•
Bugs can be reported, edited by email
•
Security bugs can be kept private until fixed
•
Triage and planning can be delegated on a day to day basis
•
Plugins for integration with Bugzilla and Trac in progress
•
View activity log for bugs
Findings Expectedly none of these trackers are perfect. They were developed with different philosophies and all of them are usable for basic bug tracking. Some of the features and ideas that we gleaned from the comparative evaluation are: •
Interlink bugs: As the complexity of bugs evolve, resolution of a bug is dependent on the resolution of another. The dependent bugs may be present in a different bug tracking system.
•
Customization: We think that the bug tracking system is a reflection of the social norms in the development community. Hence there is an absolute need to provide flexibility to customize the system like ability to add custom fields, define the life cycle of a bug, notification methods. Often the development community has control of the bug tracking system - hence they will customize the system to maximize their incentives. This a huge challenge.
•
Conversation space: Most of the initial bug submissions lack enough information to resolve the defect. Bug submissions are followed by a conversation with the user to reduce the uncertainty surrounding the bug description. So the tracker should facilitate conversation around the boundary object - a bug submission.
Screenshots
!
!
!
!
!
!
!