Why Use Email

Coding horror has a nice entry on why email is counter-productive. It takes a different view as to why this is so. Rather than assume that it is the need to respond to emails that is the counter-productive part, the entry states that it is the constant need to see if anything new has arrived. The chances of any important information arriving via email are quite slim. You might get one or to useful emails per day. So what is the contents of the other emails that arrive daily that you don't care about? Maybe smaller pieces of information that might be of some significance in the future, but not today. And being interrupted with these irrelevant pieces of information is what is counter-productive.

So how to deal with these irrelevant pieces of information? There are always social networks. Social networks are feature reach and are certainly more than common these days. But I find that even moving these smaller pieces of seemingly irrelevant data to social networks as the delivery medium does not solve the problem entirely. Sure, this would clean up your inbox and thus eliminate the need for you to constantly be checking it. But what about that nagging feeling that you are missing something on your social networks? They do suffer from the same productivity problems as email does. Something else that might be taken into account when considering social networks as a delivery medium for sending simple messages is the fact that they support many more features. These other bells and whistles can be even more distracting than email because email does one thing and one thing only.

Using a wiki for exchanging most types of information, both big and small pieces, often makes more sense. Larger, more static pieces of information can be created as wiki pages. Smaller pieces of information can be created as tickets in project management systems, most of which have wiki support. A threaded dialog can then be created on these tickets. The conversation is than public and persistent. It is also search ready. They key point here being that tickets and wiki pages for that matter, are not limited to a software development context. They are much more general purpose and do not require polling on the recipient's behalf.

Navigating Trac Tickets

The Trac project management system allows users of the system to perform queries for tickets. In Trac, tickets are entities that help keep track of outstanding tasks, bug fixes, or basically anything the needs to be accomplished for a given software project. Trac default set of useful ticket queries that users can easily execute. The default set of ticket queries allow interested parties to common groups of tickets such as those belonging to a particular developer.

When viewing a ticket, Trac displays a set of links in the top right of the screen that allow the user to view the previous ticket or the next ticket. There is also a link to return to the the query results. The next ticket and previous ticket links are useful because tickets can be navigated without the need to return to the query. However, the ticket order is based on the ticket number. This presents a problem if the user is only interested in navigating back and forth between tickets in the current query result set. The next ticket can always be completely irrelevant to the tickets the user is interested in.

The really useful aspect of the link back to the query results is how the presentation of the query results can change. Tickets that have been edited while you were viewing a specific ticket, change appearance in the query results once the user returns to the query results. You will also notice that the current user is part of the URL back to the query results.

This feature is incredibly useful in a high paced development environment with many developers. It also helps if a small group of developers are collaborating on a small group of related tickets because changes to tickets by other people become immediately apparent.

Configuring Trac Ticket Workflow

Trac is a project management system written in Python. Trac has a powerful issue tracking system in which new issues are created as tickets. The system is flexible enough to allow for custom ticket types. This means that Trac tickets not only allow for issue tracking, but any conceivable software development task as well. There are many other customizations that can be made to Trac tickets such as custom fields and custom work-flow. Tickets in Trac go through a series of states during their lifetime. The current state of a given ticket determines the actions available on that ticket. The state of a ticket in Trac terminology is the ticket status. The ticket work-flow that determines the actions available, the permissions required, and the state the ticket must be in in order to transition are all configurable. In other words, if a given ticket is closed, the only available action for the ticket is to reopen it. This is because of the default Trac ticket work-flow configuration.

In the Trac configuration, ticket actions can be configured to allow for certain ticket states to be active in order to execute the action. So, if you wanted to allow more actions other than reopen on closed tickets, this can be specified in the Trac configuration. Multiple current states may be specified as criteria. Only a single target state may be specified. Below is a simplistic example of a ticket work-flow configuration element.

[ticket-workflow]

action = current_state1, current_state2, current_state3 -> target_state

action.permission = TICKET_MODIFY

action.operation = ticket_operation_name

The Trac Ticket Database Model

In Trac trunk, we can get a glimpse into the schematics behind the Trac ticket. The internals of the Trac ticket database model are interesting to see because the ticket is such a central concept in the Trac system. Below is an illustration of the Ticket database model class.



Here are some brief highlights of what each method does.

• __init__() - Performs initialization actions. If the ticket id was passed, the values of the ticket in the database will be populated in this instance. Otherwise, the default values will be used.
• id_is_valid() - Return true if the specified ticket id is valid.
• _get_db() - Return the database connection.
• _get_db_for_write() - Return the database connection for writing.
• _init_defaults() - Initialize the default field values. In addition to initializing the default field values, the default options that are available for a given ticket field are also initialized.
• _fetch_ticket() - Initialize this ticket instance using specific ticket field values. This is done by first executing a query to load the stored ticket data from the database.
• __getitem__() - Support the getitem operator to retrieve ticket field values.
• __setitem__() - Support the setitem operator store ticket field values.
• get_value_or_default() - Return the value of the field or the default value. The default value is only returned if there is a problem retrieving the actual value because it does not yet exist.
• populate() - Populate the ticket fields using the specified dictionary. Only valid keys in the supplied dictionary, that exist as ticket fields, will be populated.
• insert() - Insert this ticket into the database. This method will not insert the ticket if the ticket id already exists in the database.
• save_changes() - Update the database with any changes made to this ticket. This includes updating the ticket changelog.
• get_changelog() - Retrieve the changelog data for this ticket.
• delete() - Delete this ticket from the database.