Page MenuHomePhabricator
Create Task
Maniphest T89715

Fix the VE Q3 burndown chart start date
Closed, DeclinedPublic
Actions

Description

Regardless of the outcome of T88325: Whole team chat with Damon RE burndown chart expectations, could the VisualEditor Q3 Blockers project please be set to a better start date (Feb 04 or 05?) to get rid of that unrealistic spike in https://phabricator.wikimedia.org/project/sprint/view/1015/ and be able to track progress?

(Off-topic and only for completeness: Other issues (e.g. non-readable axis, 77621) might get deployed with the T86772: Next Phabricator upgrade on 2015-02-18 which will change the UI a lot, it'll also require setting the "Sprint" checkbox for that project so we could kill the § in the name, see T89646: Notify existing Sprint Projects about new Sprint extension upgrade changes).

Related Objects

Event Timeline

Aklapper created this task.Feb 17 2015, 2:09 PM
Aklapper assigned this task to Jdforrester-WMF.
Aklapper raised the priority of this task from to High.
Aklapper updated the task description. (Show Details)
Aklapper added a project: VisualEditor 2014/15 Q3 blockers.
Aklapper added subscribers: Aklapper, • Elitre.
Jdforrester-WMF closed this task as Declined.Feb 17 2015, 8:21 PM

No. The sprint really did start on the first of January. This software's incompetence at understanding reality isn't appropriate reason to mis-represent the work of the team.

Jdforrester-WMF moved this task from Nominated to Done on the VisualEditor 2014/15 Q3 blockers board.Feb 18 2015, 3:28 PM
Aklapper mentioned this in T78684: Have public bug day / triage sessions in February 2015 about VE.Feb 19 2015, 2:01 PM
Qgil updated the task description. (Show Details)Feb 19 2015, 4:44 PM
Qgil set Security to None.
Qgil subscribed.Feb 19 2015, 4:50 PM
In T89715#1044646, @Jdforrester-WMF wrote:

This software's incompetence at understanding reality

Mmm I guess you wouldn't like people to talk about your software like this. :) Anyway, is the current graph correct understanding reality? If not, what are the problems? I'm happy to report them.

Now the spike is gone, and what is shown is a flat line without any points burned between January 1 and February 2. Why is this?

  • Because no sprint tasks were resolved during that period?
  • Because no sprint tasks were moved to the Completed (now Done) column during that period?
  • Else?

As explained at T78684#1049659, I'm only asking because I think this chart is going to play an essential communication role.

Jdforrester-WMF added a comment.Mar 2 2015, 5:51 AM
In T89715#1050042, @Qgil wrote:
In T89715#1044646, @Jdforrester-WMF wrote:

This software's incompetence at understanding reality

Mmm I guess you wouldn't like people to talk about your software like this. :)

Well, I wouldn't encourage people to use my software in a way for which it was explicitly not intended, either. :-)

Anyway, is the current graph correct understanding reality? If not, what are the problems? I'm happy to report them.

Now the spike is gone, and what is shown is a flat line without any points burned between January 1 and February 2. Why is this?

  • Because no sprint tasks were resolved during that period?
  • Because no sprint tasks were moved to the Completed (now Done) column during that period?
  • Else?

The second option.

Originally, the problem was that the tasks weren't in the project at the time they were marked as Resolved (so instead they started as negative points and then became even more confusing). This was bad.

Now tasks only count as fixed for the tracker based on when the task is moved into the "Done" column in the project, and as this wasn't around until early February the software assumes that the project wasn't running (rather than that it was, but we weren't using the software). This is also mildly bad, mostly because it encourages people to think that the speed of getting things done is so irregular.

As explained at T78684#1049659, I'm only asking because I think this chart is going to play an essential communication role.

Well, that's where we part. :-) I think it's a useless chart, and I'd disable it if I could (or ideally put huge red banners next to it explaining that it's suspect and should only be interpreted alongside significant other data).

Qgil added a comment.Mar 2 2015, 8:24 AM

Thanks for the explanation. Understood.

About the relevance of burndown charts as communication tools, I was simply convinced by Damon'[pitch at T85155: Our Challenges for 2015, opening plenary session at 2015 MediaWiki Developer Summit. I don't have a stake on this topic, though. As long as we communicate well within and outside the dev team, I'm happy.

Aklapper added a comment.Mar 2 2015, 9:26 AM
In T89715#1077319, @Qgil wrote:

I was simply convinced by Damon's pitch

@Qgil: FYI, T88325#1045276 for the general picture

Jdforrester-WMF edited projects, added VisualEditor; removed VisualEditor 2014/15 Q3 blockers.Mar 20 2015, 8:13 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits