launchpad development|
Size: 4137
Comment:
|
Size: 2372
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| Slogan for public consumption: '''''Go go Yellow Jackets!''''' | Slogan for public consumption: '''''Go go Golden Horde!''''' |
| Line 7: | Line 7: |
| Slogan when we feel tired: '''''Go go Yellow Banana Slugs!''''' | Slogan when we feel tired: '''''Go go [[http://en.wikipedia.org/wiki/File:Banana_slug_closeup.jpg|Yellow Banana Slugs]]!''''' |
| Line 9: | Line 9: |
| Current project is [[LEP/BetterBugSubscriptionsAndNotifications]] . | Current project is [[LEP/ParallelTesting]] . |
| Line 11: | Line 11: |
| Also see UI work at [[yellow/Subscriptions]] . | == Weekly review call checklist == |
| Line 13: | Line 13: |
| == Next Deliverables == | * Briefly review where we are in project plan. * Any new tricks learned? * Collaboration tricks? * Debugging tricks? * Communication tricks? * Checklists? Processes? * Any nice successes? * Can you attribute your success to anything beyond the innate brilliance of yourself and your coworkers? * Any pain experienced? * Questions to ask: * Are there any cards that are/were taking too long to move? * Are they blocked? * Are we spinning our wheels? * How long is too long? * Are we not delivering value incrementally? * Are we not collaborating? * Did we duplicate any work? * Did we have to redo any work? * Did we misunderstand the technical requirements, the goal, or a process? * Was the ordering of tasks that we chose broken? * Can we learn from it? * Checklist? * Experiment? * Another process change? |
| Line 15: | Line 38: |
| Due 2011-01-28 | == Notes for next call == |
| Line 17: | Line 40: |
| * Gary: * Updated LEP, with definition of success/completion approved by Jono. * Iterative user testing plan, after discussion with Matthew and Jono. * Report on status of YUI upgrade plan from RobertCollins. * Report on reply from Jono/Robert on scheduling SMM or similar sooner. |
* Gary: lxc docs are here: https://help.ubuntu.com/12.04/serverguide/lxc.html * Brad/Benji: hints for dealing with strace blather in diagnosing non-hanging program? |
| Line 23: | Line 43: |
| * Brad and Benji: * Establish new testing feature flag that is granted to team:yellow * Replace non-js subscribe link with JS subscribe link. * Have the link pop up an accordion widget, on production. * Next task: Make the widget behave the way we want. * Danilo and Gary: * Filters and subscribers should be joined: demonstrate that the current filter page is gone. * Show that events are now integrated as one of the filters available on structural subscriptions. * Next task: One person takes mail unsubscribe story with Graham; other person joins Brad and Benji on JS/Webservice work. * Graham: * Make bug notification work through the API (in review) * Demo the widget for direct subscriptions, on production. Announce to malone-alpha team (with warning that it might or might not change significantly soon). * Next task: Mail unsubscribe story, with Gary and/or Danilo. |
== Notes from weekly review call == |
| Line 37: | Line 45: |
| == Problem Solving == | === Resolutions === |
| Line 39: | Line 47: |
| === 2011-01-21 === | * Next "new to us" project (like charms) when we do not know enough to write tests initially, we want to try this process: * Prototype (no tests, as a rule) * Squad discussion: lessons learned, design decisions * Begin coding, TDD. |
| Line 41: | Line 52: |
| * 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? |
* We will read all ~yellow reviews when in feature development. * We are interested in using Go for our next project, if appropriate. * Short term goal: charm is ready for review next Tuesday, Feb 14. We would like to provide feedback to the juju team about our experience, and we are willing to take time to do so. Gary is reaching out to hazmat and SpamapS to see how it would be best to do this. === Tabled === * How will we share smaller design decisions that we learn during the day? The daily call is good but not good enough. IRC? micro-blogging? |
Yellow Squad Wiki Home
https://launchpad.net/~yellow/+mugshots
Slogan for public consumption: Go go Golden Horde!
Slogan when we feel tired: Go go Yellow Banana Slugs!
Current project is LEP/ParallelTesting .
Weekly review call checklist
- Briefly review where we are in project plan.
- Any new tricks learned?
- Collaboration tricks?
- Debugging tricks?
- Communication tricks?
- Checklists? Processes?
- Any nice successes?
- Can you attribute your success to anything beyond the innate brilliance of yourself and your coworkers?
- Any pain experienced?
- Questions to ask:
- Are there any cards that are/were taking too long to move?
- Are they blocked?
- Are we spinning our wheels?
- How long is too long?
- Are we not delivering value incrementally?
- Are we not collaborating?
- Did we duplicate any work?
- Did we have to redo any work?
- Did we misunderstand the technical requirements, the goal, or a process?
- Was the ordering of tasks that we chose broken?
- Are there any cards that are/were taking too long to move?
- Can we learn from it?
- Checklist?
- Experiment?
- Another process change?
- Questions to ask:
Notes for next call
Gary: lxc docs are here: https://help.ubuntu.com/12.04/serverguide/lxc.html
- Brad/Benji: hints for dealing with strace blather in diagnosing non-hanging program?
Notes from weekly review call
Resolutions
- Next "new to us" project (like charms) when we do not know enough to write tests initially, we want to try this process:
- Prototype (no tests, as a rule)
- Squad discussion: lessons learned, design decisions
- Begin coding, TDD.
- We will read all ~yellow reviews when in feature development.
- We are interested in using Go for our next project, if appropriate.
- Short term goal: charm is ready for review next Tuesday, Feb 14. We would like to provide feedback to the juju team about our experience, and we are willing to take time to do so. Gary is reaching out to hazmat and SpamapS to see how it would be best to do this.
Tabled
- How will we share smaller design decisions that we learn during the day? The daily call is good but not good enough. IRC? micro-blogging?
