search

SourceKettle / sourcekettle

SourceKettle is an open source project management and source code management tool
17 stars 6 forks source link

The priority planner is mega broke #470

Open patrickmcsweeney opened 9 years ago

patrickmcsweeney commented 9 years ago

I created a milestone with a load of tasks on it, then realised it was too big. In the priority planner moved all the tasks back to the backlog. when used the priority planner to bring them into the new milestone the interface behaved very strangely. Tickets bounced about but went back to the backlog. When refresh is placed everything looks like it should. then in the kanban view all my tasks had been put in the dropped status box. Very odd.

antineutron commented 9 years ago

When you move things back to the backlog, it unsets the milestone ID and sets the status to 'dropped', which may not be the right thing.

I'm starting to think I made a mistake by making a 'dropped' status. Better idea (may disrupt a lot of things now?) - use MoSCoW priorities, and the Won't Have priority is used as a "dropped" status.

Not sure what the bouncing thing is about though. Might be that the AJAX call "failed" from the client point of view but didn't actually fail? Hmm.

patrickmcsweeney commented 9 years ago

I think dropped is the wrong thing. I think what used to be the ice box and is now "Dropped tasks" should be "Return to task to backlog". Most of the time the ticket is in the wrong milestone not planned never to be done. Returning a task to the backlog probably shouldnt change its status or at very least should change it to open. Returning tasks to the back log should maybe should only be doable in the project planner which frees up space on the kanban board. The term dropped tasks gives the users the heebies as well. They think of dropped as senonomous with "deleted" and i am inclind to agree with them. dropped is a task we never indend to do how ever the interface sort of treats dropped tickets like they are normal tickets when it would be helpful to annex them from the default tasks and things. I usually mark a ticket as closed if I want to get shot of it but i know in the four column kanban (which i dont use) this has different semantics.

Pat

On Wed, May 6, 2015 at 3:44 PM, Andy Newton notifications@github.com wrote:

When you move things back to the backlog, it unsets the milestone ID and sets the status to 'dropped', which may not be the right thing.

I'm starting to think I made a mistake by making a 'dropped' status. Better idea (may disrupt a lot of things now?) - use MoSCoW priorities, and the Won't Have priority is used as a "dropped" status.

Not sure what the bouncing thing is about though. Might be that the AJAX call "failed" from the client point of view but didn't actually fail? Hmm.

— Reply to this email directly or view it on GitHub https://github.com/SourceKettle/sourcekettle/issues/470#issuecomment-99496828 .

'But your intentions are beside the point, It's the outcome of your actions that count...'

antineutron commented 9 years ago

Originally, the "ice box" contained any tasks without a milestone. I added the "dropped" status because if you have a LOT of non-milestoned tasks, it becomes pretty horrible to deal with (same problem on the planning view, but not a lot can be done about that). It's also useful to keep it associated with the milestone so you can see a list of "things we planned to do this time, but didn't".

On 06/05/2015 16:11, Patrick McSweeney wrote:

I think dropped is the wrong thing. I think what used to be the ice box and is now "Dropped tasks" should be "Return to task to backlog". Most of the time the ticket is in the wrong milestone not planned never to be done. Returning a task to the backlog probably shouldnt change its status or at very least should change it to open. Returning tasks to the back log should maybe should only be doable in the project planner which frees up space on the kanban board. The term dropped tasks gives the users the heebies as well. They think of dropped as senonomous with "deleted" and i am inclind to agree with them. dropped is a task we never indend to do how ever the interface sort of treats dropped tickets like they are normal tickets when it would be helpful to annex them from the default tasks and things. I usually mark a ticket as closed if I want to get shot of it but i know in the four column kanban (which i dont use) this has different semantics.

Pat

On Wed, May 6, 2015 at 3:44 PM, Andy Newton notifications@github.com wrote:

When you move things back to the backlog, it unsets the milestone ID and sets the status to 'dropped', which may not be the right thing.

I'm starting to think I made a mistake by making a 'dropped' status. Better idea (may disrupt a lot of things now?) - use MoSCoW priorities, and the Won't Have priority is used as a "dropped" status.

Not sure what the bouncing thing is about though. Might be that the AJAX call "failed" from the client point of view but didn't actually fail? Hmm.

— Reply to this email directly or view it on GitHub

https://github.com/SourceKettle/sourcekettle/issues/470#issuecomment-99496828 .

'But your intentions are beside the point, It's the outcome of your actions that count...'

— Reply to this email directly or view it on GitHub https://github.com/SourceKettle/sourcekettle/issues/470#issuecomment-99506467.Web Bug from https://github.com/notifications/beacon/AAdY-iiIYPIHOPKt9MTEWC3Smnjg2RCHks5oGiaGgaJpZM4ERJzs.gif

patrickmcsweeney commented 9 years ago

In that case i think the crux of the issue can be addressed by not marking things as dropped when you are on the planner view. It should probably un-drop things when they leave the milestone (either because the milestone closes or they get kicked by the planner). Possibly the status dropped should be not assignable to tickets which are in the backlog but this might be overkill. I guess the status dropped only really makes sense if its been dropped from something.

Pat

On Wed, May 6, 2015 at 4:39 PM, Andy Newton notifications@github.com wrote:

Originally, the "ice box" contained any tasks without a milestone. I added the "dropped" status because if you have a LOT of non-milestoned tasks, it becomes pretty horrible to deal with (same problem on the planning view, but not a lot can be done about that). It's also useful to keep it associated with the milestone so you can see a list of "things we planned to do this time, but didn't".

On 06/05/2015 16:11, Patrick McSweeney wrote:

I think dropped is the wrong thing. I think what used to be the ice box and is now "Dropped tasks" should be "Return to task to backlog". Most of the time the ticket is in the wrong milestone not planned never to be done. Returning a task to the backlog probably shouldnt change its status or at very least should change it to open. Returning tasks to the back log should maybe should only be doable in the project planner which frees up space on the kanban board. The term dropped tasks gives the users the heebies as well. They think of dropped as senonomous with "deleted" and i am inclind to agree with them. dropped is a task we never indend to do how ever the interface sort of treats dropped tickets like they are normal tickets when it would be helpful to annex them from the default tasks and things. I usually mark a ticket as closed if I want to get shot of it but i know in the four column kanban (which i dont use) this has different semantics.

Pat

On Wed, May 6, 2015 at 3:44 PM, Andy Newton notifications@github.com wrote:

When you move things back to the backlog, it unsets the milestone ID and sets the status to 'dropped', which may not be the right thing.

I'm starting to think I made a mistake by making a 'dropped' status. Better idea (may disrupt a lot of things now?) - use MoSCoW priorities, and the Won't Have priority is used as a "dropped" status.

Not sure what the bouncing thing is about though. Might be that the AJAX call "failed" from the client point of view but didn't actually fail? Hmm.

— Reply to this email directly or view it on GitHub

< https://github.com/SourceKettle/sourcekettle/issues/470#issuecomment-99496828

.

'But your intentions are beside the point, It's the outcome of your actions that count...'

— Reply to this email directly or view it on GitHub < https://github.com/SourceKettle/sourcekettle/issues/470#issuecomment-99506467>.Web

Bug from

https://github.com/notifications/beacon/AAdY-iiIYPIHOPKt9MTEWC3Smnjg2RCHks5oGiaGgaJpZM4ERJzs.gif

— Reply to this email directly or view it on GitHub https://github.com/SourceKettle/sourcekettle/issues/470#issuecomment-99516803 .

'But your intentions are beside the point, It's the outcome of your actions that count...'