Yellow Squad Wiki Home

https://launchpad.net/~yellow/+mugshots

Slogan for public consumption: Go go Yellow Jackets!

Slogan when we feel tired: Go go Yellow Banana Slugs!

Current project is LEP/BetterBugSubscriptionsAndNotifications .

Also see UI work at yellow/Subscriptions .

Next Deliverables

Due 2011-02-11

Value to Users

• Graham: Demo the widget for direct subscriptions, on production. Announce to malone-alpha team (with warning that it might or might not change significantly soon). (This is done except for spuriously failing windmill tests now.)

• Gary: 548 (almost done now, thanks in large part to Danilo). Also 713382 . Also 713392. Announce. Help Graham if more time.

Incremental Deliverable

• Brad: user testing results from Matt. Be able to show yellow devs a YUI accordion overlay widget somewhere, somehow.
• Benji: webservice changes for structural subscription filter UI
• Graham: Mockups for user testing #2 of "change subscriptions in anger" story

Notes: Danilo out this week

Delivered 2011-02-04

Value to Users

• Danilo: The "Lifecycle" implementation of event filtering for direct subscriptions now works. (Structural submissions mask the behavior. 713382)

• Gary: Event filtering (only available for the malone alpha team at this time) is now per-filter, giving more flexibility, and leading towards the UI that Brad and Benji are working on. (Event filters on structural subscriptions are not reported properly on +structural-subscriptions. 713392)

• Gary: You can delete structural subscriptions that have filters.
• Graham: direct bug notification filtering available through the API

Incremental Deliverable

• Brad: Got mockups to Matt, user testing happened, test results Monday

Problem Solving and Hints

2011-02-04

• We met some goals, yay!
• landing problems, JS problems, windmill problems. problem-solving approaches already in play.
• Danilo: If you want to see notifications on qastaging without having to check emails, ask losas to run this: "cronscripts/send-bug-notifications.py -vv". Action: Gary will write this up somewhere and send a note out.

2011-01-28

• Why did we not meet the goals this week?
  • Growing pains: old pre-squad work ate Benji's time; Graham agreed that growing pains affected his week as well.
  • CHR annoying: Benji and Danilo this week, Gary and Brad next week, Graham following week. Gary has already raised this to flacoste.
  • Danilo out two days this week.
  • Gary focused on getting things set up.
  • Conclusion: Don't worry about it. See how we are next week or two before we consider changes.

2011-01-21

• Landing issues slowing us down. Solution: no short term solution identified. Ask Jono/Robert that SMM or similar be scheduled earlier.
• JS painful; example we found was bad. Solution: Ask for early review from Deryck. Rejected solution: ask Deryck for a "blessed" example.

• YUI upgrades are painful. Going from dot releases (e.g., 3.2 to 3.3) is a cost like switching major Python releases (e.g., 2.6 to 2.7). Solution: ask RobertCollins to be on top of YUI upgrades like Python upgrades, and to schedule upgrades with significant warning and full knowledge of the cost.

• How do we get ongoing stakeholder guidance in an efficient way?
  • Francis suggests that we use UI testing of the full interface as a way to also get initial stakeholder approval. He feels user testing will frame the conversation productively to encourage direction of our plans rather than bikeshedding. Benji warns that users may not understand that other features they are not tested on will not be present.
  • Benji wonders (without necessarily advocating) if Elliot might say "build it and people will like it." Gary feels we've tried that before (i.e., without sufficient stakeholder approval) and failed.
  • Benji suggests that we ought to have a single stakeholder representative. Gary feels that we've seen before that this is insufficient and historically problematic.
  • We collectively wonder what Jono's approval of the UI and the definition of "done" means in this regard. Is it Jono's responsibility to be the developers' only interface to the stakeholders now?

  • We talk about whether UI mockups or prototypes or incremental deliveries would be more valuable for getting input. UI mockups are cheaper than development, but incremental deliveries are more efficient if they are on the right track. Gary feels an ideal answer is finding a cheap way of getting just enough of a stakeholder blessing of a UI, and then using incremental deliveries to steer the rest of the way. Time-boxed mockups, developed iteratively ideally, combined with iterative delivery.

  • Next task for pursuing solution: Gary needs to contact Matthew (and Jono and/or Francis?) and see how user testing might work and what we need to provide. We do not yet have all parts of the user interface mocked up. We'd like to see if we can find an approved way to do iterative user testing--several tests instead of one big one. Can we make it cheaper/easier?

Thoughts for later discussion or action

• I want to try keeping a velocity chart, as described in Manage It. The kanban's charts are not quite what I want. For each individual project (i.e., our current project), track Features Left, Features Done, and Total Features over time. I'll use a Google graph. I'm adding that to the Administrivia lane of our kanban board. [GaryPoster]

• Next feature, maybe we can try a Tuesday or Wednesday delivery date. Manage It specifically warns against the Friday delivery dates we have now because she says that it can encourage stress and work over the weekend. If that proves to be a problem, here's a solution. [GaryPoster]

• Think about sprints. [GaryPoster]