Trac and Kanban - Redux

Hello there!

Since my last post before summer, the number of total visits has gone from 2000 to over 7000! One of the reasons for this was the  Trac and Kanban post, where I breifly describe how to use a Trac wiki page as a basic kanban board. (The main reason is this Stack Overflow question which asks for a bit more, such as drag-n-drop and the like.)

We'we worked with this for half a year now, and it still feels like a good thing. So good, actually, that I simply had to improve it a bit.

Trac and Kanban, v2.0

Mainly I now use the "format=table" option to get a table, which means we get color for the priority, we can show who is owning the item and what resolution it had (duplicate/invalid/worksforme/wontfix, etc) where suitable.

It looks like this (with no one working on anything at the moment, but you get the idea):

This could be even better if Trac supported sorting on several ticket fields, but that is not possible with 0.12. There is a ticket and patch available on the Trac home site, but I haven't tried it ... yet.


Code review

For the confused, note that I still use two custom fields for post-commit code review "reviewed_by" and "has_review_issues".

I will probably change the boolean review_issues to a checkbox that better handles the states and workflow for code review:

• not_reviewed
• reviewed_with_issues
• review_issues_fixed
• reviewed_and_approved

A custom TicketChangeListener could then manage the has_issues to issues_fixed transition, so that it's automatically visible that the code has changed.

Automatic subpage/dashboard lists 

The second new thing I've discovered and deployed is the TitleIndex macro, to simply list show all sub pages for a single wiki page. Since we have all the dashboards under Dashboard/ProductNameX.Y pages, it's easy to list them all using [[TitleIndex(Dashboard/ProductName,hideprefix)]] on a product's "home" wiki page.

Old/completed milestones could then be moved to DashboardOld container so that they're still there, but does not clutter the "current and upcoming milestones/sprints" list.

Limit right column to last two weeks

Adding modified=2weeksago.. to the queries for closed tickets makes the dashboard work over long time, since older (closed) tickets are not modified and thus removed from the table after some time.

This really helps with using the system in a "pure" Kanban setting, without sprints or milestones. It's also useful to keep a current status view during longer milestones with 100+ tickets.

Wiki code

The wiki page above was generated from the following code:

This is the ticket dashboard for **[milestone:"Orsync 1.0"]**
([/query?milestone=Orsync+1.0&status=new&status=reopened&status=testable&status=accepted&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component open tickets])
-- [wiki:Orcamp/FeatureList current feature list]

Create new
[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=defect defect],
[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=enhancement enhancement],
[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=suggestion suggestion],
[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=change change],
[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=task task],
[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=demo demo] or
[/newticket?milestone=Orsync+1.0&component=Apps/Orsync generic] ticket.

{{{
#!div style="float:left; margin-right:1em; width:30%"

= Open Tickets =

Total: [[TicketQuery(status=new|reopened,type!=suggestion,milestone=Orsync 1.0,format=count)]]
([[TicketQuery(status=new|reopened,type=suggestion,milestone=Orsync 1.0,format=count)]])

== New & Reopened ==

[[TicketQuery(format=table,col=summary|type,status=reopened|new,type!=suggestion,milestone=Orsync 1.0,group=priority,order=type)]]

== Suggestions ==

[[TicketQuery(group=priority,status=new|reopened,type=suggestion,milestone=Orsync 1.0)]]

}}}
{{{
#!div style="float:left; margin-right:1em; width:30%"

= Work In Progress =

Total:
[[TicketQuery(status=accepted,order=priority,group=owner,milestone=Orsync 1.0,format=count)]]
([[TicketQuery(status=accepted|testable,milestone=Orsync 1.0,format=count)]])

== Started ==

[[TicketQuery(status=accepted,group=owner,order=priority,format=table,col=summary|type|owner,milestone=Orsync 1.0)]]

== Unreviewed tickets ==

[[TicketQuery(review_issues!=1,reviewed=,status=testable,group=owner,order=priority,format=table,col=summary|type|owner,milestone=Orsync 1.0)]]

== Reviewed tickets with issues ==

[[TicketQuery(review_issues=1,status=testable,group=owner,order=priority,format=table,col=summary|type|owner,milestone=Orsync 1.0)]]

== Ready for Test ==

[[TicketQuery(review_issues=1,status=testable,group=developertest,order=priority,format=table,col=summary|type,milestone=Orsync 1.0)]]



}}}
{{{
#!div style="float:left; margin-right:1em; width:30%"


= Closed Tickets =

Total: [[TicketQuery(status=closed,resolution=fixed,milestone=Orsync 1.0,format=count)]] 
([[TicketQuery(status=closed,resolution!=fixed,milestone=Orsync 1.0,format=count)]])

== Fixed tickets (last two weeks) ==

[[TicketQuery(status=closed,format=table,col=summary|type,resolution=fixed,order=priority,desc=1,milestone=Orsync 1.0,modified=2weeksago..)]]

== Denied tickets (last two weeks) ==

[[TicketQuery(status=closed,resolution=wontfix|worksforme,format=table,col=summary|type|resolution,order=priority,desc=1,milestone=Orsync 1.0,modified=2weeksago..)]]

== Invalid/duplicate/other (last two weeks) ==

[[TicketQuery(status=closed,resolution!=fixed|wontfix|worksforme,format=table,col=summary|type|resolution,order=priority,desc=1,milestone=Orsync 1.0,modified=2weeksago..)]]


}}}

{{{
#!div style="clear:both"
}}}




There you go. Hope it helps!

Trac and Kanban

(Don't miss my update Trac and Kanban Redux)


We use a Trac wiki page as a simple kanban board. It's pretty neat, especially when put on a 42" LCD TV in the project room.


Here's how it looks in the browser:

And here's the wiki code, all built using TickeyQuery-macros, both for counting (to keep an eye on the WIP-limit) and listing the tickets themselves. It's pretty basic, but it works well  for our small team and it's easy to understand and maintain.

This is the ticket dashboard for Orcamp for [milestone:"Orcamp 1.0"] ([/query?milestone=2010+M11&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component tickets])  -- [wiki:Orcamp/FeatureList current feature list]

{{{
#!div style="float:left; margin-right:1em; width:30%"

= Open Tickets = 

Total: [[TicketQuery(status=new|reopened,milestone=Orcamp 1.0,format=count)]] 

[[TicketQuery(group=priority,status=new|reopened,milestone=Orcamp 1.0)]]

}}}
{{{
#!div style="float:left; margin-right:1em; width:30%" 

= Work In Progress =

Total: [[TicketQuery(status=accepted|testable,milestone=Orcamp 1.0,format=count)]] 

== Started ==

[[TicketQuery(status=accepted,order=priority,group=owner,milestone=Orcamp 1.0)]]

== Ready for Test ==

[[TicketQuery(status=testable&review_issues=0&reviewed!=,group=developertest,milestone=Orcamp 1.0)]]

== Reviewed tickets with issues ==

[[TicketQuery(review_issues=1,group=owner,status=testable|closed,resolution=fixed,milestone=Orcamp 1.0)]]

== Unreviewed tickets == 

[[TicketQuery(review_issues!=1,status=closed|testable,group=status,resolution=fixed,reviewed=,milestone=Orcamp 1.0)]]


}}}
{{{
#!div style="float:left; margin-right:1em; width:30%" 


= Closed Tickets = 

Total fixed: [[TicketQuery(status=closed,milestone=Orcamp 1.0,resolution=fixed,format=count)]] 
Other: [[TicketQuery(status=closed,milestone=Orcamp 1.0,resolution!=fixed,format=count)]] 

== Fixed tickets ==

[[TicketQuery(status=closed,group=type,resolution=fixed,milestone=Orcamp 1.0)]]

== Other resolutions ==

[[TicketQuery(status=closed,group=resolution,resolution!=fixed,milestone=Orcamp 1.0)]]


}}}

{{{
#!div style="clear:both"
}}}

Note that the above wiki code contains some references to custom fields (notably review_issues) that we use to manage code reviews on a ticket-by-ticket basis. In our small team, we've decided to allow commits of unreviewed code, but require code to be reviewed before it's cleared for testing. 


As always, you should adapt to local conditions. :)

Distributed Version Control Systems on Windows...

It's never easy...

So, having used Subversion and Trac successfully for roughly three years, I now have the oppurtunity to research and choose the technology base at the startup where I'm currently at.

DVCS:es seems to be all the rage, with Git and Mercurial being the two topmost contenders (I know about bazaar and a few others, but I didn't bother looking too much.)

Now, my prerequisites was that I wanted to get this to run on a Windows server (for various reasons). Open Source on the bleeding edge and Windows is never easy, but I've learnt a few things and gotten halfway there.

I'm using:

* Apache 2.2
* ModPython
* Python 2.5
* Trac 0.11
* Windows XP (server) and Vista (client)

Git

Git has a standalone installer for windows build on MSys (Mingw) which works well, both from the command-line and using the Tcl GUI.

By using Cygwin on the server, one can use ssh to access the common repo and push/pull. (Cygwin can import domain passwords, so you don't need to bother with dual user/password lists)

Pulling from http using webdav/apache is possible. With mod_auth_sspi you can again use windows domain usernames/password. (It might be possible to use LDAP too, haven't tried yet)

Git in daemon mode with by cygwin and inetd works too. (fast download path)

Trac and Git on windows does _not_ work, yet. This is because GitPlugin uses an old version of PyGit (not the PyGit on PyPi), for detail see this ticket. I might get around to do some hacking there.

I'm working on getting gitweb.cgi to run. I just get "403 Forbidden - No project found." all the time.

Mercurial

There are clients both for command-line (py2exe standalone builds, no python required) as well as windows shell integration (although it still has some rough edges, being 0.5 at the time of writing).

Trying to use Mercurial with mod_python is tricky, since the command-line dist has everything in library.zip (including dll's), which regular python can't import. So you need to unpack it somewhere and add that dir to sys.path. Also, Mercurial expects it's Templates to be in the same dir, so you need to copy that as well (otherwise you'll get hit an assert when using hgweb.cgi). See here for details.

hgweb.cgi works! See here for some tips.

Using MercurialPlugin in Trac from mod_python does not work. There is an issue with demandimport, or expat (under unix), or something. Which simply makes apache or python crash.

Installing Mercurial into c:\Python25 using easy_install might help (to avoid importing library.zip from the stand-alione cmd-line binaries), but that requires Visual C++ 7.1, which I don't have. I haven't found anyone who has precompiled for that use yet. (Copying the files to lib/site-packages did not work.)

I did get trac to run in tracd mode by modifying tracd-script.py and adding 'sys.path.append(r'C:\Program Files\Mercurial\lib')' and running it with 'python tracd-script.py --port ...' !! I have .py files associated with python so can just run py-files as .bat/.cmd, but this did not work here! Very strange.

So, tracd is slower than mod_python (or mod_wsgi, which I haven't tried, but I expect it to have the same wierd issues as mod_python), so I guess I'm stuck with using tracd.

Tracd can be run as a service with the help of the Windows Resource Kit, but you don't get apache authentication (LDAP/SSPI). :(

Anyway, that seems to be the best bet.

Final words

I'm thinking of using apache under cygwin instead. That might help somewhat. Or just usel ighttpd/fastcgi on cygwin and windows-apache's mod_proxy. But.. the layers.. the jumping.. the hoops... arggh..

OTOH, I might go for subversion and wait until the DVCS-on-Win32 state improves (perhaps with my help), or until I get a Unix based server to toy with...

To be continued, as they say...