t+1 - Latest Comments in My new ticket tracking system is now vaporware!

Re: My new ticket tracking system is now vaporware!

Sasha — Thu, 21 Apr 2011 17:08:29 -0000

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.

Re: My new ticket tracking system is now vaporware!

cheap condoms — Mon, 21 Sep 2009 06:21:20 -0000

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.

Re: My new ticket tracking system is now vaporware!

the website guy — Sat, 11 Jul 2009 23:37:37 -0000

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

Re: My new ticket tracking system is now vaporware!

Justus — Tue, 24 Feb 2009 15:58:33 -0000

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

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

Re: My new ticket tracking system is now vaporware!

Matt Wilson — Tue, 24 Feb 2009 09:27:17 -0000

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

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.

Re: My new ticket tracking system is now vaporware!

Matt Wilson — Tue, 24 Feb 2009 09:23:24 -0000

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.

Re: My new ticket tracking system is now vaporware!

Matt Wilson — Tue, 24 Feb 2009 09:21:17 -0000

But this bug tracker is (very slightly) different!

Re: My new ticket tracking system is now vaporware!

Matt Wilson — Tue, 24 Feb 2009 09:20:15 -0000

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

Re: My new ticket tracking system is now vaporware!

Jason R. Coombs — Tue, 24 Feb 2009 07:48:37 -0000

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.

Re: My new ticket tracking system is now vaporware!

fuzzylollipop — Mon, 23 Feb 2009 23:44:26 -0000

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

Re: My new ticket tracking system is now vaporware!

Pekka Klärck — Mon, 23 Feb 2009 15:44:56 -0000

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

Re: My new ticket tracking system is now vaporware!

Matt Wilson — Mon, 23 Feb 2009 15:18:21 -0000

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

Matt

Re: My new ticket tracking system is now vaporware!

mikegrb — Mon, 23 Feb 2009 14:58:05 -0000

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

Re: My new ticket tracking system is now vaporware!

Doug Hellmann — Mon, 23 Feb 2009 12:38:24 -0000

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.

Re: My new ticket tracking system is now vaporware!

Matt Wilson — Mon, 23 Feb 2009 12:31:18 -0000

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!

Re: My new ticket tracking system is now vaporware!

Matt Wilson — Mon, 23 Feb 2009 12:28:30 -0000

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!

Re: My new ticket tracking system is now vaporware!

Matt Wilson — Mon, 23 Feb 2009 12:21:20 -0000

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.

Re: My new ticket tracking system is now vaporware!

Aaron Oliver — Mon, 23 Feb 2009 12:06:21 -0000

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

Re: My new ticket tracking system is now vaporware!

Matt Wilson — Mon, 23 Feb 2009 11:01:47 -0000

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

Re: My new ticket tracking system is now vaporware!

Matt Wilson — Mon, 23 Feb 2009 10:59:20 -0000

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

Re: My new ticket tracking system is now vaporware!

Doug R — Mon, 23 Feb 2009 10:38:57 -0000

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?

Re: My new ticket tracking system is now vaporware!

Doug Hellmann — Mon, 23 Feb 2009 07:48:57 -0000

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

Re: My new ticket tracking system is now vaporware!

Doug Hellmann — Mon, 23 Feb 2009 07:45:05 -0000

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

Re: My new ticket tracking system is now vaporware!

Pekka Klärck — Mon, 23 Feb 2009 04:18:18 -0000

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/robot... 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.

Re: My new ticket tracking system is now vaporware!

Paddy3118 — Mon, 23 Feb 2009 02:57:26 -0000

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

- Paddy.