Attracting the Community’s Many Eyes: an Exploration of User Involvement in Issue Tracking

User input drives the development of software systems by contributing ideas, reporting bugs and clarifiying requirements. To encourage such feedback, open source projects often provide issue tracking systems (e.g. Bugzilla) that are open to the public. In commercial software development, however, this is often not the case. I was interested if opening issue tracking systems of commercial projects to the public would yield similar community input as is the case for open source projects. Together with Holger Schackmann, Adrian Schröter, Christoph Treude and Margaret-Anne Storey, I studied community involvement in issue tracking in the Eclipse and IBM Jazz projects. IBM Jazz is a commercial IDE for collaborative development. The Jazz project has opened its issue tracking system to the Jazz community. Eclipse is a well-known open source IDE with a public issue tracking system.

Our 8 page research paper "Attracting the Community’s Many Eyes: an Exploration of User Involvement in Issue Tracking" was accepted at HAoSE 2010, the Second Workshop on Human Aspects of Software Engineering, co-located with SPLASH 2010. Here is the abstract of our paper:

A community of users who report bugs and request features provides valuable feedback that can be used in product development. Many open source projects provide publicly accessible issue trackers to facilitate such feedback. We compare the community involvement in issue tracker usage between the open source project Eclipse and the closed source project IBM Jazz to evaluate if publicly accessible issue trackers work as well in closed source projects. We find that IBM Jazz successfully receives user feedback through this channel. We then explore the differences in work item processing in IBM Jazz between team members, project members and externals. We conclude that making public issue trackers available in closed source projects is a useful approach for eliciting feedback from the community, but that work items created by team members are processed differently from work items created by project members and externals.

Download Paper

Configuring Eclipse for Writing Papers

I used to write my papers in Latex using Kile (a KDE Latex IDE) - but several limitations like having to use external tools for versioning, missing integrated literature management and limited extendibility made me look for an alternative solution.

Being an Eclipse user & RCP developer, I immediately though of customizing Eclipse for writing scientific publications aka papers. Here is a short description of the configuration I currently use:

Programs / Plugins
- Eclipse 3.4 as baseline
- TexClipse for writing Latex
- EclipseWiki for writing notes on read literature using a wiki style in the workspace
- A local Subversion server for versioning my changes
- Subversive for connecting to subversion

General Configuration
- file association (under Preferences) *.bib to my favorite bibliography tool (KBibTex)
- file association *.pdf to preferred PDF viewer
- Wiki settings to use TWiki (Preferences/Wiki/Rendering) for historical reasons

Subversion / Workspace layout
- no trunk/branches/tags, just plain project name (I believe that this is not necessary because typical publications do not require branching etc. as far as I see it)
- for each publication I write, I have a separate project, e.g. paper_conferenceA_2008
- there is a bibliography project with the bibliography.bib file used by all projects (by \bibliography{../bibliography/bibliography} - when I finish a paper I copy the current bibliography to that project and change the reference to the copy (to it from breaking in the future))
- in the bibliography project, I have a literature folder containing .wiki (notes) and .pdf (paper itself) files for the papers I read. That way, I can search my notes and find the papers. The name for both is firstauthorname_yearX, X being a,b,c... depending on the number of publications from that author in that year.

Project configuration
- Latex Project Properties/temporary files directory: tmp (excluded in subversion)
- output as DVI

The advantages of using such a configuration are:
- if you are used to Eclipse, you can rely on this knowledge (e.g. shortcuts)
- integrated versioning support
- notes, papers, and bibliography at one place
- opportunity to develop additional tooling (visualizations, search, etc.)
- mostly platform independent

I might have missed some details of my configuration - if you notice something not quite working or unclear, please comment on this post.