Auto-tools/Projects/Bugzilla Tracking: Difference between revisions
| Line 8: | Line 8: | ||
<pre>[ateamtrack: p=<projectname> q=<quarter> m=<milestone> s=<size>]</pre> | <pre>[ateamtrack: p=<projectname> q=<quarter> m=<milestone> s=<size>]</pre> | ||
* p -- project name. Every project has a name, so that's pretty obvious. This field is required. | * p -- project name. Every project has a name, so that's pretty obvious. This field is required. | ||
* q -- quarter. This is what quarter this bug is relevant for. Note that this should include a year: | * q -- quarter. This is what quarter this bug is relevant for. Note that this should include a year: 2013q2, for instance. This is required. | ||
The other fields are totally optional, and you can add other metadata onto this as well, which are optional if you need to. | The other fields are totally optional, and you can add other metadata onto this as well, which are optional if you need to. | ||
| Line 14: | Line 14: | ||
* s -- size. This isn't used right now, but it would be useful if we do something more automated in the future. I'd like to do sizing in numbers of hours. Right now, if this is absent, we will assume a size of 8 (so that means resolving this bug would take a full day). s=1, s=2,s=4,s=80, <-- you get the idea. | * s -- size. This isn't used right now, but it would be useful if we do something more automated in the future. I'd like to do sizing in numbers of hours. Right now, if this is absent, we will assume a size of 8 (so that means resolving this bug would take a full day). s=1, s=2,s=4,s=80, <-- you get the idea. | ||
Here is what this looks like in practice: | |||
<pre>[ateamtrack: p=sfn q=2013q2 m=1]</pre> | |||
== Tracking bugs == | == Tracking bugs == | ||
Revision as of 16:21, 29 March 2013
Rationale
A-Team project tracking. We really need a good way to tie our low level project tracking (i.e. bugzilla bugs) to our high level goals (random bits of text on wiki pages). This has been lacking for a while, and we've done it pretty well by doing Ad-Hoc correlations. However, as we do more and varied projects, it gets harder and harder to keep a handle on what's a priority and what isn't.
This is an attempt to create a very lightweight project tracking mechanism. I don't believe in over-rotating on this because if we make it hard to do/keep up with then we will just shoot ourselves in the foot even before we begin.
The Format
It is just key/value pairs so we can pull the data out and process it automatically (one of these days):
[ateamtrack: p=<projectname> q=<quarter> m=<milestone> s=<size>]
- p -- project name. Every project has a name, so that's pretty obvious. This field is required.
- q -- quarter. This is what quarter this bug is relevant for. Note that this should include a year: 2013q2, for instance. This is required.
The other fields are totally optional, and you can add other metadata onto this as well, which are optional if you need to.
- m -- milestone. Some projects might be broken into milestones so that we have checkpoints through the course of the quarter. If you have a milestone number, it will go here.
- s -- size. This isn't used right now, but it would be useful if we do something more automated in the future. I'd like to do sizing in numbers of hours. Right now, if this is absent, we will assume a size of 8 (so that means resolving this bug would take a full day). s=1, s=2,s=4,s=80, <-- you get the idea.
Here is what this looks like in practice:
[ateamtrack: p=sfn q=2013q2 m=1]
Tracking bugs
I don't think we should put these on tracking bugs. It just doesn't make sense since this is a low-level thing.
Filing a new bug
Is it too hard to remember? Here is a bug template for a [ateamtrack:%20p=%20q=%20&status=NEW new bug with the required fields pre-added]