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 projects are LEP/ParallelTesting and LEP/LaunchpadSetupScripts.

Daily call checklist

• Review cards on our kanban board in the active and done lanes (in Miscellaneous, Development, Deployment, and QA lanes).

• Is a card done that had been a problem (non-moving for more than 24 hours)? If so, record it on the wiki page as a topic for the Friday review call.

• Move all Done-Done cards (fully completed) to the archive, off the main board. Celebrate!
• Have any active cards been in the same lane for more than 24 hours? If so, discuss pairing and problem solving.
  • Are the developers stuck? Consider "convening a panel" after this call to become unstuck.
  • Has the card been in the same lane for more than 48 hours? If so, consider adding or rotating programmers.
  • Is no-one available for regular pair programming? If so, strongly consider blocking an active card in order to get that developer(s) available for focusing on the non-moving card. If more than one card is not moving, consider focusing on one at a time.
• Do any non-done cards on the board have deadlines? If so, review as necessary.
• Review all blocked cards everywhere. Are any of them unblocked? Do we need to take action to unblock any of them?
• Make sure there are clearly kanban cards to be done
• Update all cards with collaboration information
• Rotate through the squad. Each person should mention any items that everyone should know: remind people of reduced availability, request help such as code reviews or pair requests, etc

Panel requests

Unsticking panel checklist

• Take note of when the panel starts / set an alarm for T+20.
• Describe problem avoiding mentioning your own (stuck) solutions and ask for solutions and approaches.
• If that fails, describe your own solution and ask for solutions and ideas.
• If the panel has taken longer than 20 minutes, stop. Arrange for a pair programming or consultation as necessary.
• If no-one has said anything other than filler for three minutes, stop. Arrange for a pair programming or consultation as necessary. Consider rotation.

Pair programming observer checklist

• Be actively skeptical.
• Watch the other person's back.
• Be a planner: actively propose plans to tackle problems
• Offer to be a "navigator," keeping the destination in mind while the "driver" handles the details.
• When something doesn't make sense, this is a trigger for both parties to check assumptions and step back.

Weekly review call checklist

• Briefly review where we are in project plan.

• Review "topics for next", below

• 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?
  • Prompts to ask people about:
    • (benji) nosetests doesn't seem to like pdb... [later] oh! -s to the rescue
    • (bac) nosetests will not discover test modules if the execute bit is set. Weird.
    • (benji) I chafed a bit on the lpsetup framework a little while working on the "get" subcommand
    • (benji) the decoy doctests in lpsetup wasted some of my time and they are slowly getting out of date, they should be removed or made to work

    • (gmb) lpsetup can and will blow away your SSH keys if you're little more than a beard with an idiot hanging off it: https://bugs.launchpad.net/lpsetup/+bug/1018823

  • 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?

Topics for next

• gary_poster: trick from hallyn: how do you identify whether you are running in an lxc container?

<hallyn> 1. if /bin/running-in-container is present (precise and above, always), run it and check for 0 return value * mfraz74 (mfraser@2.30.164.138) has joined #ubuntu-server <hallyn> 2. else, if lxc-is-container is not present, assume lxcguest is not installed and you're not in a container (or are in trimmed container) <hallyn> 3. else, run lxc-is-container, if 0, you're in a container, if 1 you're not

(also see https://github.com/kwilczynski/facter-facts/blob/master/lxc.rb ?)

• bac: success or pain of tarmac?
  • multiple running gpg-agents is bad. Years-old login files (.profile, .bash_rc) are bad.

  • tree_dir setting is supposed to create the directory if it does not exist but since it is suggested to be in /var/cache I had to pre-create /var/cache/lpsetup so I could chown it to my user. Since it was there tarmac did not check it out. So I did a checkout myself. Having done that, tarmac merge only merged into the local repo but didn't push to LP. Solution was to create /var/cache/tarmac and chown it to my user. Then I set tree_dir to /var/cache/tarmac/lpsetup/trunk. Tarmac then created the subdirectories, did a checkout, merged changes to it locally, and pushed to LP.

  • Tarmac docs - confusing. Fixed and will propose.
• bac: pain of Python packaging?

Writing a LEP checklist

• Describe the idea to one or more people in the squad to vet and refine it.
• Write up the LEP.

• Get at least one person in the squad to review it, especially if you are tired of it .

• Announce the LEP for broader review.

Starting a project checklist

• Prototype (no tests). Consider competing prototypes.
• Have a squad discussion about lessons learned and design decisions.

• Review CreatingNewProjects to get everything started properly. Also see jml's document for further ideas on what to add to this checklist.

• Begin coding with TDD.

Depending on another developer or team checklist--someone new or with past delivery problems

• Doublecheck whether you can't do it yourself somehow, or get someone with proven cross-team delivery ability.
• Are you depending on a person or a team? If it is a person, consider trying to escalate it to the manager, to make it a team goal, or at least something with team visibility and managerial approval and encouragement.
• If they need something from you, ask what format they want it in in order to be able to process your request as quickly as possible.
• A corollary to the previous one: make sure that you are making the smallest request necessary and reasonable.
• While it is tempting, and sometimes necessary, to be flexible for interacting with busy people, if the work is worth doing, the sooner it is done, the more value you get from it. The longer you wait, the more likely it is that you will get no value from it. This is "lean" for our squad, and also for the company. Try to communicate this.
• Request a delivery date guess. Consider requesting that a call be scheduled on that date, either for handover or for reassessment. If there is a deadline for us, also bring this to the attention of the Launchpad manager (flacoste).
• If the delivery doesn't happen on the expected date, (on the scheduled call) ask for three things: a revised delivery date, another associated call, and a fallback plan. The fallback plan should be some reasonable remediation if the second delivery date fails. Also bring this to flacoste's attention, and discuss with him whether official escalation is appropriate.

jml also pointed out this checklist from Covey's Seven Habits.... You need to establish these things up-front:

1. Desired results [spend time here, include "when"]
2. Guidelines [what I'd call constraints]
3. Resources available [money, team, people]
4. Accountability [what measures, how often]

5. Consequences [natural ones & incentives]

We should also try to incorporate these ideas.

Slack project checklist

• The project should further Canonical in some aspect. Examples include making yourself a more valuable employee to Canonical (i.e., studying a technology that is important to the company), improving processes or tools for our squad or team, or building or improving something for another part of Canonical.
• Consider who you expect to maintain the project.
  • Yourself: Be skeptical of this, but if so, that's fine.

  • Our squad: discuss design with squad, and/or follow the prototype -> discuss -> code pattern we have for new projects

  • Our team: make a LEP, consult with team lead (flacoste), and get acceptance from TA (lifeless) and/or any other stakeholders identified
• Make a card for the task or tasks in the kanban board.