New post
Article
· Mar 31, 2018 1m read

What Are You Using For Issue Tracking?

#Change Management #Caché

Hi, Community!

What is your favorite issue tracking system for projects with InterSystems Data Platform? What did you use and what are you using now?

In projects with InterSystems Data Platform, I worked with Redmine, JIRA, Trello. A lot of code versioning systems now have this feature too (Gitlab, Github).

Now my favorite for small and medium projects is Github, because it is simple, is very close to code (commit-issue linkage) and it has kanban).

E.g. see the DC public GitHub project (and add your issue request ;)

What is your choice?

Discussion (10)3
Log in or sign up to continue
Sergei Shutov · Apr 2, 2018

My advise to small teams that are co-located in the same office is not to use issue tracking system at all and use physical cards on whiteboard instead. In my experience using issue tracker just adds overhead without any significant benefits compared to index cards. Obviously if you have a large or distributed team you should use something, but again the simpler the better

Here is a random example from the internet (I usually use bigger cards, A6 format - quarter of a standard paper sheet):

Another example: http://theagilepirate.net/archives/1178

2 0
Sergei Shutov · Apr 3, 2018

Hi Ed,

I prefer to have real-time real-world discussion near the whiteboard to leaving comments in issue tracker.

discussion about implementation strategy

You do a whiteboard discussion and write results into your Wiki/Confluence where it's easy to find it. Then you have a code review tool to make sure you implemented it correctly

references to other issues

Don't need this

cross-references to commits

Also don't need this, just write meaningful commit messages

test hints

Talk to tester

start/due dates & time spent

I usually write date the card was created in the corner to track how old it is. Then place it in the backlog based on its urgency. Don't need anything else.

milestones

You can organise your backlog into milestones.

current status

Sprint status is obvious by looking at whiteboard. For more high-level status use wiki/confluence and update it once in a while manually.

assigned person(s)

It's either written on the card or there are "person buckets" on the whiteboard. I usually don't assign issues to people until they start working on them - so if we have capacity for 20 dev days in a sprint there will be few unassigned cards on a whiteboard and people assign themselves once they pick their next card

Issues help to collect all this information and make it available later

It's a bit scary at first to just throw away all completed issues at the end of the sprint, but in reality there's nothing wrong with it. Most of this information is available via source control, and there are not many use cases where you would need to look up an old issue to have some info that's not in source control anyway.

2 0