Why is yellow brick half plane taking so long?

i’m extremely heart-warmed by @drtall’s apologia but agree with @kenoubi pretty much completely. i even almost agree with the sorta implied “is anyone even working on the code??”. :slight_smile: i mean, we have been, all day every day – and you can see the blow-by-blow at Beeminder Changelog (well, that’s the user-visible tip of the iceberg – plenty of those things, like what shows up user-visibly as crisper svg graphs (whoop-dee-do) is part of a massive undertaking to switch from python/matplotlib to javascript/D3 (and that’s in fact part of YBHP – we meant for YBHP to be a prereq for that but flipped it around) anyway…) where was i? oh yeah, we have not been smart about triage and project management, etc, and that’s a big reason we have @mary now!

hugely appreciate little kicks in the butt like this!

answering the specific questions:

  1. kind of, and there’s some truth in @drtall’s characterization. it touches freaking everything.
  2. well, also kind of. i personally view it as high priority but CEO’ing generally has taken precedence and the way YBHP spans the rails code and beebrain (the graphing/stats) it kind of needs both @bee and i heads down on it. this is another thing that @mary is helping with as she’s now COO/CFO.
  3. ha!
  4. mostly not, though we got pretty hung up on the messy migrations needed to fully kill of auto-widening weight loss roads. more on that in our progress report thread: Progress Report on Yellow Brick Half-Plane - #22 by dreev
  5. not this
  6. yes, even just for the death-to-auto-widening piece, for which we have a sprawling confusing blog post draft…
  7. i guess but i mostly don’t want to justify our slowness. it’s really not ok and i’m thinking about how best to hard-commit to getting this thing out the door. obviously this didn’t quite work: http://dreev.commits.to/deploy_YBHP/by/this_summer (that “this summer” is, gulp, last summer!)
5 Likes