Related Objects
Event Timeline
Hi @Danny_B
These cards are actually special cards that reflect the team goals for this sprint. In that sense, they are not "real" tasks. The team has thus far identified that "placeholder" cards such as these are the easiest way quickly see what the goal of the sprint is, and remain on target for the iteration. While I can see that it makes sense to tag these special cards with external projects, such as Page-Previews , the reality is that doing so will break functionality elsewhere in Phabricator, in this case in a filter the team uses to catch "stray" tags. I think your instincts are good here, and I'll discuss with the team to see if they can identify alternatives to their methodology. :)
Hi @MBinder_WMF, thank you for explanation of the removal of the tag and motivation behind creation of the task.
However, I have to say, that this is bad misuse of tools for totally different purposes which has bunch of side-effects and shortcommings, and I am pretty sure that there are other, better ways, how to achieve the goal rather than using a sledgehammer to tight a screw... Tools should be used to purposes they have been intended and created for...
On the very first shot after reading your description and checking the board, it comes to the mind why don't you (pl.) simply describe the goals of the sprint on the project description page?
As a user who is quite familiar with Phabricator's features, I'll be happy to help you (pl.) with finding more reasonable solution than this, but for that, I'd need clear description of your (pl.) needs, of what you need to achieve by that. Thank you.
Thanks for your support @Danny_B .
On the very first shot after reading your description and checking the board, it comes to the mind why don't you (pl.) simply describe the goals of the sprint on the project description page?
Please see T137458: Improve pain points of "Sprint Goals" sprintboard column cards for more detail on what you've described.
I appreciate your sentiments and share many of them. The team has many improvements that have been identified for future iterations, and while we'd love to do them all at once, the reality is that we can only do a few at a time, so we prioritize them every few weeks before applying them to the team's continuous improvement cycle. The team holds a bi-weekly retrospective on process. It has been proposed that the linked task is a candidate for the next iteration, but I'd like to wait until the retro is complete to see if there is something urgent and emergent that will take precedence.
Thanks again for your feedback and patience.
Thank you for explanation of the process and link to the proposal. I am going to go through that and if you would be interested I may put some comments or suggestions (if I will have any ;-)) there.