Introduction

This is a brief description of the workflow we use to manage tickets, mixed with some food for thought. It helps us to make tickets easy to understand for new people like you, and maintain a overview of "what do you have to do to complete a release". It must be said this is somewhat inspired by the "Getting Things Done" ^(TM) methology.

For developers only

The tickets can only be created and updated by developers. This is done on purpose. This way we can translate a "some bugs" request to separate well written tickets. It becomes more obvious what we have to do: what bugs to fix to have to complete a release. If you want to report a bug there isn't a barrier of entry to register another account, or learn how to use a ticket system properly. If you can understand a forum, you can report bugs! That's why we use the Help Forum for this.

Food for thought

• "I have 100 e-mails in my inbox. Can I be confident everything is done?"
• "I got this BugZilla report with 100 comments and idea's. Can you tell me what I have to code?"
• "I just (re-)read all my e-mail and comments, I know what to do now!" (er: memorize the topic, flooding your mind with stuff)
• "I have a well defined action list and each time I strike an item though it just feels great. Almost everything is done now!"
• "I have a well defined action list and wrote unrelated notes between the different items."
• "I wrote notes in my agenda between the tasks I planned for a specific date."
• "Oh yeah I still remember what to do that specific date." (er: memorize).
• "Is the release ready now?"
• "I don't understand this ticket, what do I actually have to do here?"
• "So if I half-complete this list leaving the notes out, the release is ready?"
• "Oh wait I've got something buried there, between those comments!"

...you'd probably get an idea here ;-) Some simple rules make it more pleasantly to work. Keep the chaos out of your mind, so it can be turned to the actual work! (...and actually get more creativity/inspiration too because you have a clear mind).

The ticket system is not a discussion board

The ticket system should only be used for well-defined tasks, enhancements and bugs. The ticket system is not a discussion board. It should not be used to post vague suggestions with endless discussions what the actual action should be. Use a scratch pad page for that, like Idea's open for discussion. If a decision has been made, create a ticket to implement that specific idea. This way, the tickets remain a clear TO-DO list of actions to complete.

The process

Collect all stuff

First collect the stuff that needs to be done. It can be user input, forum topics, e-mails, things on your mind, notes on your desk, etc.. If you have a random idea, write it on a note (an INBOX), put it in your wallet, and process it later at home. After processing it, it will be put somewhere so you can put it out of your mind. And trust it won't be forgotten either.

Process it

Decide what to do with the input.

For well defined actions, it's relatively simple:

• Create a ticket ('defect' / 'enhancement').
• For bugs that cause a crash, use the 'crash' type. We want those to stand out.
• Write an intro, so everyone understands it.
• Describe the actual thing to do.

Sometimes it's not obvious what the actual problem is. These tickets shouldn't clutter the list of things to do. Instead, create a task to investigate it.

• Create a ticket instead to research the problem.
• Use the 'task' type.
• Depending on the outcome, mark it as fixed, or create the proper ticket(s) to fix the problem.

When it's just something on your mind without any clear action, write in down in the Wiki, e.g. at Idea's open for discussion, or at your option any other random page. You can put a link to the page at the Scratch pad block of the main page.

Reviewing tickets

Tickets shouldn't get a milestone unless the issue should absolutely be fixed for that milestone. Until that time, the tickets are an open pool developers can randomly choose from. In fact, it's not a problem at all to choose something from the open pool, we love to get enhancements in KMess! It is only a problem when a new release is close, and the codebase should be kept stable.

Every once in a while, the tickets are reviewed to see which ones are a priority. During the review, it's also possible to assign a milestone to a "nice to have" because it's something we really want to have in that release.

Reference: Getting Things Done

• Collect your stuff (user requests, forum topics, e-mails, random idea's)
• Put the information in a system you trust.
• Don't mix up idea's with tasks, notes with agenda items.
• You only have to keep a list of the 'very next action' to complete.
• When starting with that action, you can grab the whole project history, bug lists and notes from your reference/archive.
• (what GTD calls a project is just something that has multiple steps, so in reality it's a subproject like "rewrite the contact list")
• Review next actions / waiting for items every day.
• Review the whole system once a week.
• After processing your inbox is empty.