launchpad development|
Size: 9184
Comment:
|
Size: 2381
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: |
| == Notes == | * 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: |
| * "unsubscribe in anger" may have to deal with things that can't be unsubscribed normally, like owning a pillar in some cases. [GaryPoster] * Editing a structural subscription should allow/enable access to subscriptions of teams you administer. * In regards to https://wiki.canonical.com/Launchpad/Strategy/Research/BugSubsFeb2011/Round2/: 1. We will implement (a small variation of) version 1 for now. It got a positive response, and it does not require any server-side changes, and it is similar on the UI side to what we would do for version 2, so it seems like a pretty clear next step. 1. Version 3 (the assignee filter) we can ignore. It got mediocre response and we won't get to it. jml, would you like us to file a bug about this feature so you can track it? 1. We might get to version 2. It got a lot of positive feedback, and we know a number of people have said they want something like that. We can cross that bridge later. See notes below on version 2. 1. We need to get rid of the ellipses. A triangle is the right way to go. Benji has volunteered to come up with another mockup for this, for our own internal agreement. 1. I don't think we need another UI testing iteration on version 1. If we work on version 2 later, we might or might not want to go for another UI testing; we can cross that bridge then. |
== Notes for next call == |
| Line 24: | Line 40: |
| In regards to possible later work on version 2: | * Not buildbot with Juju. Jenkins? Net positive, but in future question directives? Have time associated with answering that question, when we propose? Kind of like agile. |
| Line 26: | Line 42: |
| 1. We should consider subscribing multiple people 1. We should try to address fear of choosing the wrong team (we don't think confirmation messages are the right approach, but we probably want something to address the concern) 1. I have some thoughts on combining version 1 and version 2 as Matthew suggested. Again, we can cross that bridge when we get to it. |
== Notes from weekly review call == |
| Line 30: | Line 44: |
| * [[yellow/EmailNumberEstimation|Estimating number of emails for a subscription (filter)]] | === Resolutions === |
| Line 32: | Line 46: |
| == Next Deliverables == | * 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 34: | Line 51: |
| === Due 2011-02-18 === | * We will read all ~yellow reviews when in feature development. |
| Line 36: | Line 53: |
| Value to Users | * We are interested in using Go for our next project, if appropriate. |
| Line 38: | Line 55: |
| * gary: Bug:164196 delivered | * 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. |
| Line 40: | Line 57: |
| Incremental Deliverable | === Tabled === |
| Line 42: | Line 59: |
| * Graham: Deliver first version on qastaging of bug +subscriptions page based on user testing * Brad * Document how we will add JS/CSS to tree after discussion on LP list * get new JS widget in tree; * get Huw to get started on skinning accordion widget * deliver ugly accordian within gary-alt on some branch we check out and click on - Benji: Brad's widget will be hooked up to actually work on some branch or qastaging - Danilo, Gary: ? Should help the other efforts if possible. === Delivered 2011-02-11 === Value to Users * Graham: Demo the widget for direct subscriptions, on --(production)-- qastaging. Announcement to malone-alpha team (with warning that it might or might not change significantly soon) will be coming today. * Gary: Bug:548. Also Bug:713382 . Also Bug:713392. Brad will announce 548 today. Incremental Deliverable * Brad: user testing results from Matt. Brad/Benji/Gary delivered another version for more testing. Brad showed yellow devs a YUI accordion overlay widget with a screenshot earlier this week. * Benji: webservice changes for structural subscription filter UI are figured out. Delivered [[/JavaScriptAPIAccessDraft|JavaScriptAPIAccessDraft]] to document. * 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. Bug: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. Bug: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-11 === * We met all goals, yay! * No new problems reported. * Gary did not announce "cronscripts/send-bug-notifications.py -vv" though he used it a bunch. * Benji has [[/JavaScriptAPIAccessDraft|his new webservice page]]. He circulated it among some experts, but needs to publicize it. * Brad will be talking to devs about how to incorporate new JS in the tree. He will then be writing up the results. === 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 [[http://pragprog.com/titles/jrpm/manage-it|Manage It]]. The kanban's charts are not quite what I want. For each individual project (i.e., [[LEP/BetterBugSubscriptionsAndNotifications|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. [[http://pragprog.com/titles/jrpm/manage-it|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] |
* 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
- Not buildbot with Juju. Jenkins? Net positive, but in future question directives? Have time associated with answering that question, when we propose? Kind of like agile.
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?
