[almighty] priority driven model for issue tracking

[Max Rydahl Andersen]

On 5 Aug 2016, at 17:39, Thomas Mäder wrote:

> I just wonder how the approach scales to large projects. What do you 
> do with bug reports that you can't get to right now...just abandon 
> them? Way to value your customers that were nice enough to actually 
> report a bug...

Yeah, I've always struggled with how to handle bug reports in an "Agile 
process" - I think the answer lays in the article though: If noone is 
around to care about an issue, then it is better of being closed.

This does not mean you just abandon them, it means that if you care 
about your customers bugs then someone is triaging them and making sure 
they are on the backlog and in the plan for the coming sprints.

> Part of the approach seems to be that the have a engineering tracker 
> and then the "real" issue tracker somewhere on the side (left as an 
> exercise...)

Yeah, this is my takeaway too and it plays to my ideas of making it 
trivially easy for anyone (and I mean *anyone*, not just product 
managers) to be able to define one or more queries that can be used as 
"backlog" for a board (or other mechanism used to visualise work).

While at the same time making it an option to explicitly add issues to 
actually be on a board.

In model terms that is that unlike Jira where a query fetch all the 
items for a board (backlog and current progress) then we would have that 
for defining the backlog, but each issue will explicitly be linked to a 
board and possibly its column (column/state should be possible to 
calculate most of the time rather than manually set it).

This is a hybrid of trello's 100% manual adding and moving of boards and 
jiras all queried. I think this will give the best mix.

And it allow one to have boards that focus on different things - keeping 
them fairly clean, without resorting to deleting everything outside the 
developers mind set.

/max

> /Thomas
>
> Am 05.08.2016 um 16:10 schrieb Max Rydahl Andersen:
>> Hey,
>>
>> spotted this article today: 
>> http://blog.gitprime.com/a-priority-driven-model-for-issue-tracking/
>>
>> Pretty interesting read and it captures one of the concerns I always 
>> have when I see the number of ideas, bugs, tasks etc. flowing into an 
>> planning tool or issue tracker - it will just overwhelm you if things 
>> are not nurtured.
>>
>> In this they very aggressively say that anything not precise enough 
>> or too old gets removed from the engineering issue tracker.
>>
>> This article nicely illustrate the importance of not cluttering your 
>> system - I do see that we need in almighty be careful about how we 
>> present the workitems and that we do not require a lot of process 
>> hell to keep it uptodate.
>>
>> In PDD terms - might be that board views by default filter out higher 
>> level work items and just provide a link to them. Basic stuff like 
>> that.
>>
>> /max
>> http://about.me/maxandersen
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public


/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160808/0e033d9f/attachment.htm>