Skip to content

Categories:

My new ticket tracking system is now vaporware!

I set up http://pitz.tplus1.com 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?

Posted in Programming, Python, pitz.

By matt

February 22, 2009

Viewing 25 Comments

cheap condoms 5 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

I'll use maybe google's charting API to do stuff.I would prefer to render the charts
locally rather than use an external service.

reply edit reblog flag

the website guy 8 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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 :)

reply edit reblog flag

http://www.dempseygraphics.com/

fuzzylollipop 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

in one word, my ideal bugtracker would look like Jira http://www.atlassian.com/software/jira/
I mean why another bug tracker, there has to be some better way to spend time coding?

reply edit reblog flag

Matt Wilson 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

But this bug tracker is (very slightly) different!

reply edit reblog flag

12 /people/mw44118/ /people/mw44118/following/ http://blog.tplus1.com

Justus 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

"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 (http://www.ccs.neu.edu/home/shivers/papers/sre.txt). 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.

reply edit reblog flag

Matt Wilson 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

Yeah, this may not be a good match for you. I don't understand what
you mean about python lacking unicode collation and regular
expressions.

reply edit reblog flag

12 /people/mw44118/ /people/mw44118/following/ http://blog.tplus1.com

Justus 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

No worries, not every piece of software is a perfect match for everyone :-)

Collation:
>>> u'cafe' < u'café' < u'caff'
False

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.
http://www.cmlenz.net/archives/2008/07/the-trut...

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 roundup.sf.net

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

reply edit reblog flag

Pekka Klärck 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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? =)

reply edit reblog flag

http://eliga.fi

Matt Wilson 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

Hi Pekka, this page has a link to the mailing list and the git
repository: http://pitz.tplus1.com/project.html

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.

reply edit reblog flag

12 /people/mw44118/ /people/mw44118/following/ http://blog.tplus1.com

Michael Greb 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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

reply edit reblog flag

http://michael.thegrebs.com

Matt Wilson 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

Hi Michael, thanks for the note! There's also
http://bugseverywhere.org, which uses python.

Matt

reply edit reblog flag

12 /people/mw44118/ /people/mw44118/following/ http://blog.tplus1.com

Aaron Oliver 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

An external (RESTful?) API to let other things play nice with it.

reply edit reblog flag

6 /people/aaronoliver/ /people/aaronoliver/following/ http://www.codesoftly.aaronoliver.com in/aaronoliver

Matt Wilson 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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.

reply edit reblog flag

12 /people/mw44118/ /people/mw44118/following/ http://blog.tplus1.com

Doug R 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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?

reply edit reblog flag

Matt Wilson 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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.

Matt

reply edit reblog flag

12 /people/mw44118/ /people/mw44118/following/ http://blog.tplus1.com

Doug Hellmann 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

Hmm, in fact, why require *any* properties of a ticket? Why not make the entire "schema" configurable?

reply edit reblog flag

3 /people/dhellmann/ /people/dhellmann/following/ http://www.doughellmann.com/

Matt Wilson 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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!

reply edit reblog flag

12 /people/mw44118/ /people/mw44118/following/ http://blog.tplus1.com

Doug Hellmann 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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.

reply edit reblog flag

3 /people/dhellmann/ /people/dhellmann/following/ http://www.doughellmann.com/

Doug Hellmann 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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").

reply edit reblog flag

3 /people/dhellmann/ /people/dhellmann/following/ http://www.doughellmann.com/

Pekka Klärck 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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 http://code.google.com/p/robotframework/issues 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.

reply edit reblog flag

http://eliga.fi

Matt Wilson 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

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!

reply edit reblog flag

12 /people/mw44118/ /people/mw44118/following/ http://blog.tplus1.com

Paddy3118 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

Graphs. When to ship often depends on looking at graphs of bugs/time fixes/time and a lot of guesswork.

- Paddy.

reply edit reblog flag

http://paddy3118.blogspot.com

Matt Wilson 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

That's a good idea. I'll use maybe google's charting API to do stuff.

reply edit reblog flag

12 /people/mw44118/ /people/mw44118/following/ http://blog.tplus1.com

Jason R. Coombs 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

If you want SVG charts, consider svg.charts, http://py-svg.sourceforge.net/. I suggest working from the SVN trunk. It's stable and has a new, more Pythonic API.

reply edit reblog flag

http://www.jaraco.com

Matt Wilson 1 year ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

Jason -- thanks for the link! I would prefer to render the charts
locally rather than use an external service.

reply edit reblog flag

12 /people/mw44118/ /people/mw44118/following/ http://blog.tplus1.com

blog comments powered by Disqus