On Issue Tracker Reference Schemes

I'm jumping back and forth between working on my big "secret" project and getting some good code into my pet project manager Darcsforge [1]. One of the oldest (now) pieces of Darcsforge is my pet issue tracker, nicknamed 'orkin', and it was time to renovate it to better fit with the later pieces I've worked on. One of the big things I re-debated was the use of "Issue Numbers". Every Issue Tracker I've ever dealt with has used Issue Numbers as the main tool to reference an Issue [2]. The big Pro for Issue Numbers is their terseness: hundreds of thousands of issues can be addressed by a sequence of 6 numbers. The big Con: terseness. Sure you might be able to remember the difference between Issue 34 and Issue 43 but at a certain threshold you have to start referring to cheat sheets or the Issue Tracker itself to figure things out. Quick: What's the difference between Issue 135736 and Issue 135637? Issue numbers don't work well for us people and are often much more artifacts of back-end systems (auto-numbered database primary keys) than artifacts for human consumption.

Django encourages web designers to design "humane" URLs. Take this blog site, for example, I could just as easily use /entry/343/, but I specifically chose the /2007/mar/14/issue-tracker-reference-schemes/ format because it says a lot more to the human mind and is a lot friendlier. It breaks into two major pieces, the posted date (3/14/2007 or March 14 2007 or whatever other mental format you prefer) and the 'slug', which is a newspaper term by way of Django, which in this case is issue-tracker-reference-schemes. The address there tells me when I posted the blog entry and something about the subject of the ...