Mon, Feb 12
Unknowns are gone, but Scopes seem incorrect.
No more blanks. Quick check against Phab tasks seems correct. Probably can resolve.
Thu, Feb 8
Dev looks good now, but production is still showing Unknown areas in Scope. @JAufrecht my understanding was that we pushed the code to production and wanted to wait overnight to see if it changed anything before proceeding to Status = ''
Wed, Feb 7
Fri, Feb 2
@JAufrecht We might need to make time to look into this more, reports are still not useful. :)
Wed, Jan 31
Jan 11 2018
@mmodell while debugging this bug, we traced it back to tasks that have no "Status" in the Phab<-->Phlogiston dump. Rows are appearing blank (instead of "open" or "resolved" etc). Are you aware of any changes to how the data is handled, particularly around the "Status" field? :)
Jan 10 2018
Dec 13 2017
Dec 12 2017
Dec 7 2017
Dec 6 2017
Dec 5 2017
Nov 30 2017
Thanks, @Jdlrobson . That was super clear and helpful. :-D
Nov 29 2017
I believe @Jdlrobson suggested the approach for this task was "if the magic button is there, proceed, otherwise don't get too deep"? Or did I confuse my tasks?
@ovasileva @Tbayer It's my understanding that we need to get this done in the next 4 days if you want to make the deploy deadline, but because of the deadline we can't UNdeploy in the following 2 weeks. Wouldn't it be safer to wait until January? Am I missing something? :)
Nov 28 2017
@ovasileva Just want to make sure you know this is here (don't see you on the task other than "Subscribers" which isn't terribly useful). :)
Don't have time for this, and too far removed from the experience . :-/
Nov 15 2017
Nov 13 2017
Nov 9 2017
Clarified in standup that this task is a "subtask" of an epic, but not a "[subtask]" of an estimated task that is deliverable in its own right. Updated the title.
@Jdlrobson The team inferred that you are doing the code review for the Web team stuff. Is that right?
Nov 8 2017
Thanks, @pmiazga . Being a big task is not enough to estimate it if it is still part of another task that has already been estimated (even if the original parent task was grossly underestimated). It defeats the purpose of estimation, and is redundant. The exception is if the task is, in reality, delivering something on top of the first task, rather than on behalf of it. In that case, it should simply not be labeled "subtask". :)
@ovasileva @phuedx @Jdlrobson My understanding is that a "subtask" in the title of a task indicates that it is part of an existing task that already has an estimate. However, this has 8 points on it. Am I missing something?
Nov 3 2017
Updated via final steps of
I'm not totally sure what this is. Is there a doc that needs review? Needs making?
Nov 1 2017
Oct 11 2017
Oct 10 2017
I did a git pull, git add . git push hoping that would get me where I needed to be, but something tells me it's more manual than that.
I updated to add the lines
I think you mean step 4? Also, the link in that step takes me to a "Page not found" error.
@ovasileva found this lurking in a hidden column, so I moved it to where you could see it. Feel free to do with it what you need. :)