My new ticket tracking system is now vaporware!

I set up to host my pitz project, which is a python implementation of ditz.

Instead of just banging out code, I decided to write the documentation and the list of supported features FIRST.

Once I have my feature set established, then I’ll write the tests for those features, and finally, I’ll write the code.

I’m looking for feedback on the feature set. What would an ideal bugtracker look like?

30 thoughts on “My new ticket tracking system is now vaporware!

  1. This looks very interesting. My current favourite issue tracker is the one provided by Google Code. It has a simple interface and is really easy to use, but the feature that really separates it from others is easy configuration. That is achieved by using labels (a.k.a. tags) for pretty much everything, and that's something I hope other trackers would “steel”. We didn't, for example, like milestone word that much and decided to use target instead (our tracker is at if you want to take a look at it). Based on the documentation, pitz could use the same approach. Another change I would also consider is changing name to automatically created and immutable id.

  2. We've found trac's ability to add properties to tickets useful. We have a few custom fields with string, boolean, and enum types that we use for managing the workflow of the ticket.

    It would be nice if the real workflow engine was configurable, too, since we have a couple of stages not always used in other dev shops (like “in design” and “under review”).

  3. There are lots of bug tracking systems out there. Why roll your own? My first thought is that the marginal utility of time spent on building a brand new bug tracking system is less than that of your core product.

    Or do you have other motives here than just tracking issues?

  4. Hey Doug — yeah, there are lots of them, but there isn't one that is
    exactly perfect for me, where perfect means:
    * command-line interface
    * stores all files locally so I don't need an internet connection
    * makes it easy to run weird queries, like “old high-priority tasks
    linked to either of these two components”

    I use ditz right now, and I like it a lot. My stuff is really just a
    refinement off that project.


  5. Yeah, some web API is in the works. I'm not going to call it RESTful
    because I'm tired of hearing the pharisees argue about what
    RESTfulness means, but it will be something like:

    POST to /task/insert to add a new task
    GET /task?milestone=m99 to get all tasks assigned to milestone 99.
    GET /task/new to see a blank form useful for POSTing to /task/insert.
    GET /task/edit/t99 to see a form populated with data for task 99.

    and so forth.

    However, the big difference between this system and say, ticketbuilder
    or trac or bugzilla is that this is NOT a centralized system.
    Instead, the bugs are really just data in text files stored in the
    same source control system as the source code mean to fix these bugs.
    Any web interface will just be a way to read and write a local list of
    tasks. If I want to assign a new bug to somebody else, I gotta insert
    the bug into my system, then commit my source code to my repository,
    then tell the other person to merge in my stuff from my repository.

    Sure, the web interface could automatically commit its changes to the
    SCM, so as soon as I insert a new bug, it gets committed.

    There's also going to be an email interface. The idea there is that
    non-technical people can send an email to me with a subject like [NEW
    BUG] login page is wrong color and then I'll automatically create a
    bug with a title matching the email subject and a description matching
    the message body.

    Thanks for the comment. Keep the ideas coming.

  6. Pekka,

    I really like the simple tag-based approach too, and in general,
    everything is going to use an entity-attribute-value table. Any
    entity (e.g. a task, a person, a milestone) can have as many
    attribute-value pairs attached as you want.

    My code really just makes working with the underlying EAV database easier.

    I think you're right about using an immutable and automatic ID for the
    name field. Then the “human-friendly” label would be stored in the
    title attribute.

    Thanks for the comment!

  7. I've been going in circles on this point — use a schema-less system
    or a strict system. I'm going to start with a compromise, where I
    start with required attributes and allow arbitrary extensions.

    The problem I see with an entirely configurable schema is that it
    seems much more work to build out the scaffolding for all that.

    Thanks for the comments!

  8. I can see going that way since most of the items will have a core set of properties you almost always want. Making everything optional eliminates a class of special cases, though. I guess if the API to retrieve properties is the same no matter where they are stored, that solves the problem for extension authors.

  9. Really no further suggestions at the moment beyond some of the ideas presented here (eg graphs) just wanted to add myself to the list of people that can't wait to start using pitz. <3

  10. For me the feature differentiating pitz from most other bug/issue trackers is the possibility to have issues as plain text files. In addition to making integration to version control trivial that makes it easy to automate handling issues. For example Google Code's wiki pages are stored in version control and it has been great to be able to edit with commands like “sed -i s/2.0.1/2.0.2/g *.wiki”.

    I would vote for a schema-less system with as few mandatory fields as possible. Google Code's tracker has id, summary (= title), description, owner, status and comments, and everything else is defined using freely configurable labels. What I really like about the status is that you can set possible values yourself and then define which values are considered open and which closed. Really easy to configure and use, but flexible enough to construct different workflows. Matt, if you want I can give you temporary admin privileges for our project so you can try this yourself.

    Many great ideas have already been presented here. Are you planning to start a mailing list for consolidating feature ideas further? And when is pitz ready to be used for storing issues related to it? =)

  11. “What would an ideal bugtracker look like?”

    I was going to offer a lot of suggestions but then read what ditz does.

    Let me get my bias out of the way: An ideal bug tracker is not simple, lightweight, or distributed. Admittedly you can cover 95% of use cases with such a tracker (witness the popularity of trac and google code) but that isn't “ideal”.

    It sounds like you are interested in an 80% solution ( That's fine and there's nothing wrong with that. But it's a far way from creating an ideal bugtracker.

    An ideal bug tracker would support comprehensive internalization and localization (something not really possible in python because of the lack of unicode collation and regular expressions); custom workflows that are dynamically editable; everything can be renamed (users, groups, projects); multi-project, multi-group, multi-issue type, multi-permission scheme, multi-everything; fine grained and configurable permission scheme down to the level of what fields can and cannot be seen; full text search; flexible, structured querying with load limiting; designed from Day 1 for massive data sets (5 million+ issues) and large user bases (50,000+ users) operating 24-hours a day (i.e. no “downtime” for backups or database vacuuming or anything else); support for hierarchies and other relationships between issues; some kind of clustering/failover/redundancy support; email support (including ability to edit properties via email which requires support for PGP/GPG type systems); a nice AJAXified web front end; flawless spam filtering; graphs and burndown charts; support for agile processes; some way to submit tickets without having to sign up to Yet Another System; an easy way to follow tickets without having to hand out my email address to someone I might not necessarily trust (maybe rss); Open Social type dashboards; shareable, persistent filters and graphs; integration with external user management systems (LDAP, AD, etc); migration of things: issue-type-A to issue-type-B (which doesn't necessarily have the same fields, migrate issues between projects and workflows, etc.

    Lots more that I won't bother listing but you get the idea.

    Nearly every bug tracker worth talking about has a public instance so you can see what kinds of features real users ask for after a product has been around for a while.

  12. Hi Pekka, this page has a link to the mailing list and the git

    I'm doing this project in the opposite way that I usually write
    software. Normally I start with a vague idea, and it crystallizes as
    I write and rewrite the code. Then at the end I might write a little
    explanatory snippet somewhere.

    Instead with this project, I want to decide on a feature set and then
    sketch out the architecture, and then write some tests, and then write
    code. I'm hoping that this approach will make it easier for others to
    get involved. They won't need to read a bunch of buggy exploratory
    code and guess what I was trying to do. It will all be written ahead
    in plain english.

  13. No worries, not every piece of software is a perfect match for everyone 🙂

    >>> u'cafe' < u'café' < u'caff'

    So (the most common problem) you want to sort by username, people in, say, Germany, get upset that you aren't sorting properly.

    Here's a lengthy explanation of some of the problems with unicode in Python. AFAIK, none of the issues have been addressed.

    You might also want to read the design document for roundup, which Ka-Ping Yee wrote for the Software Carpentry competition. You can find it on

    (I've worked on trac, roundup, and JIRA so I guess I'm a bit evangelical about issue trackers 😉

  14. There are lots of other bug tracking solutions out there, but thats what I love about the web: when you can't fine EXACTLY what your looking for, you create your own version 🙂

  15. Requirements differ. JIRA is great for a lot of shops and a lot of purposes, but it is naive to think that it is for everybody and every project.

    JIRA is not cheap and it takes substantial effort and resources to administer, in addition to the vendor lock-in problems which can arise with proprietary software. What if the cost gets cranked up another 50%? What if you like the product, but you can't get an additional feature without paying thousands of dollars? What if you need to migrate out, what if you have problems with a supplied API, or what if you need to make nontrivial changes to the software itself? JIRA may fit you and many others, but it doesn't fit everybody.

    Pitz seems to have its own disadvantages, as its alternatives do (e.g. ditz and be, not to mention Trac, Bugzilla and a million proprietary products other than JIRA). I say let a thousand flowers bloom, a choice of usable tools which are free and interoperable is not hurting anybody. The best open source tools gradually rise to the top and everyone benefits.

  16.                  Leggings For Men
    Menswear, for the most part, has always seemed all the same and no alternative at all. But things have changed and one of the fashion designers Hedi Slimane brought something really good to men. All he did is narrow the silhouette for Dior Homme, resulting in the return of the skinny jean. All in a flash, it has become a trend now. Men who still rely on a weathered pair of Levi’s in 50s will feel embarrassing now. The look will no long work now. Men’s silhouette should also change as time goes by.
    Off the runway in 2011, we are already observing a drastic change in the way men dress up and a blurring line between masculinity and femininity. Cropped tees, Laced shirts, One-shouldered tops, skirts and even leggings are readily introduced to the world of menswear, bringing about a fresh breath to the previously monotonous industry. Feminine style for men is adopted by every designer that matters from the rationalists like Givenchy, Emporio Armani and Calvin Klein to the edgy types such as Ann Demeulemeester, Vivienne Westwood and Commes des Garcons, just to name a few. Retailers have adopted the trend and included key androgynous fashion items for the more daring male customers. I remember that there was an exclusive collection of skirts and dresses for the indie types.
    This season in 2012, menswear has been taken to new levels of skinniness. Leggings made a comeback! Guys wince and whimper a painful “hello” to man-leggings, or “muggings”.
    On the catwalk, in magazines, people began to take a cautious look on this newly design. Some are thinking of buying one pair, while some fatter men just appreciate the look. Maybe they have also made up their mind to lose some weight to tuck into these slim leggings.
    “Step and thrust; step and thrust,” came the sage words from Hawkins, who was on his way to Whitstable at the time with his new rock outfit. That’s true, men who prefer these slim look always will make a sharp hair style to match this thrust look too.
    Strapped up like Rudolf Nureyev (I decided against Hawkins's undergarment advice), I hobbled to work in a pair of sequined black leggings as conjured up by Belgian designer Martin Margiela. I looked like an evil mermaid and felt as if I was walking with a crotch full of staples.
    But it is really fantastic to try on these leggings, guys, come on! You will be so surprised to see how perfect your body shapes are! You will spend more time on admiring your muscles in these leggings! That’s pretty cool, isn’t it?
    Girls also love to see men in leggings. Girls also need something to spirit up! Skirts fashion has been outdated, as there were floods of news on the men street fashion last year. Leggings are dramatically re-invented for the 2012 in catwalk shows featuring men’s straight legs and warped hips. Internationally renowned designers re-appropriate the leggings for men, a garment which until relatively recently was reserved for the ladies.
    Proper skirts for men don’t look feminine at all. However, if you wear leggings in satins or laces, which were cut into lines and swing over your legs, that will make you look like a real fashionista.In fact, when you wear one of these leggings for men, your strength and confidence can be released immediately. If you think the skirts represent an alternative to conventional menswear, and then we should say, these leggings for men, evolutionally change their behavior and their life style. The implication is not just feminine inspired menswear, but it is also about re-appropriating cultural traditions in a contemporary way.

    Men who love Korean fashion embrace this wardrobe challenge into this hot summer. That’s because they are not only unique and rebellious but also easy to mix and match with everyday street clothes. It really does impress people even though it’s only a piece of leggings. But obviously, it certainly does speak a lot for itself and the person wearing it!

    Finally, gender flexibility in leggings has almost always been more acceptable for the style and fashion oriented crowd. As you can see, this fashion trend does start from men and now it is only a comeback. This small step develops further to legitimize gender blurring in leggings and finally men can wear the same as ladies. Couples can even dress in the same leggings and hang out together. Awesome!

    Contemporary fashion is about pushing limits. There are no rules, not have-to about what you should and shouldn’t wear to match your leggings. It’s about defining yourself without definitions. Cross boundaries fashion is becoming more and more acceptable!

    Have fun and play around with th

Comments are closed.