The Ticket to Open Source

Keeping up with the theme, our assignment this week was to read up more about open source software and understand better how to approach a project. Topics included beginner-friendly contributions, contributing through providing documentation, support, and maintenance, and a deeper dive into bug-tracking systems. Although I skimmed over the others, I chose to get a better understanding of bug trackers (or ticket trackers, as the author chooses to call it) through Karl Fogel’s book.

Tickets indicate participation

A healthy amount of ticket and ticket-related interaction indicates that the project’s maintainers are active in keeping track of underlying bugs and working to get them resolved. It allows a visitor to get an insight about how alive the project is and quickly determine whether it is worth their time and effort. What is more important, from my understanding of the reading, is not following the classic ticket life cycle, but handling exceptions to it.

Although tickets are insightful and provide valuable information to developers, such tickets grow increasingly rare as the project begins to gain popularity. There can be a significant portion of tickets that are duplicate or invalid. It is upon the maintainers, then, to answer all these tickets in an efficient but encouraging and compassionate way to sustain the link and appreciate the effort the users put in despite its invalidity.

Potential Projects

From my understanding of Bug trackers and how the maintainers contribute to its management is a paramount factor when considering projects that are potentially worthy of contribution. How quickly a ticket is responded to and the last time a ticket was opened indicate the project’s growth and active state in addition to revealing whether there are crippling bugs that can only be mitigated by a redesign; such projects are not worth the time. Of course, a myriad of other factors, social and technical, go into the evaluation of a candidate for contribution.

Communication Preference

Karl Fogel makes clear that there are multiple ways one can communicate with co-developers, incoming contributors and users. He seems to push IRC (Internet Relay Chat) very heavily. I, however, believe Slack to be more efficient, convenient and feature-rich than most of the other solutions he mentioned. He does raise a valid concern about whether or not this chat should allow conversation history archiving and if it does, it should provide links to the archive. Since Slack allows unlimited viewing of past messages in their premium plan, it would be a feature that could be added to an open-source repository. Unfortunately, this locks the project into Slack’s ecosystem.