Diff for "DesignPhoneCall"

Not logged in - Log In / Register

Differences between revisions 1 and 2
Revision 1 as of 2010-01-28 17:38:23
Size: 3857
Editor: bac
Comment:
Revision 2 as of 2010-01-28 18:41:37
Size: 4102
Editor: bac
Comment:
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
 * All Launchpad developers are encouraged to participate as both callers and callees
 * Find someone more experienced than you
 * Find someone less experienced than you
 * Find someone who is familiar with the area of Launchpad that you will be changing
 * Find someone who is unfamiliar with the area of Launchpad that you will be changing
 * Try not to overload any one reviewer
 * Try not to overload yourself doing reviews
 * Ask around on #launchpad-code first
 * When in doubt, use SteveA :)
 * All Launchpad developers are encouraged to participate as both callers and callees.
 * Find someone more experienced than you.
 * Find someone less experienced than you.
 * Find someone who is familiar with the area of Launchpad that you will be changing.
 * Find someone who is unfamiliar with the area of Launchpad that you will be changing.
 * Try not to overload any one reviewer.
 * Try not to overload yourself doing reviews.
 * Ask around on #launchpad-dev first
 * When in doubt, ask the on-call reviewer/s in #launchpad-reviews. They will either be available to help you (it's part of being on-call) or suggest another developer who can help.

 * Community developers '''must''' have a pre-implementation call for '''all''' work. No exceptions. The call must be with a domain expert (someone from soyuz, bugs, registry, translations, etc).
Line 31: Line 33:
 * Before starting on a feature, the developer will contact a suitable buddy and ask for a pre-implementation design review call. Start by asking on #launchpad-code to see if anybody is available.
 * The buddy may accept the request, tell you that the feature does not need a pre-implementation call, or may suggest a different buddy to take the call. (The buddy will be considering their own load, the area you are working in and their knowledge, and the size of the thing you are working on in deciding how to respond).
 * After deciding who will be your buddy, or agreeing that your feature does not need a call, you may move on to the next step of the development process. However, you will need to note this resolution for inclusion on your PendingReviews branch. Your branch reviewer will also ask you about your pre-implementation review call. Examples of what you might say:
 * Before starting on a feature, the developer will contact a suitable buddy and ask for a pre-implementation design review call. Start by asking on #launchpad-dev to see if anybody is available.
 * The buddy may accept the request or may suggest a different developer to take the call. (The buddy will be considering their own load, the area you are working in and their knowledge, and the size of the thing you are working on in deciding how to respond).
 * After deciding who will be your buddy you may move on to the next step of the development process. However, you will need to note this resolution for inclusion on your merge proposal. Your branch reviewer will also ask you about your pre-implementation review call. Examples of what you might say:
Line 36: Line 38:
 * For non-trivial calls, you may also find it helpful to send an email to the launchpad mailng list, summarizing what you and your buddy discussed.
 * Your buddy may also want to send a short summary of the call to the launchpad mailing list, e.g.:
  * Spent 10 minutes talking over how to tackle xxx with David A. Agreed that the right approach is to extend the existing YYY interface rather than adding a new interface.
 * For non-trivial calls, you may also find it helpful to send an email to the launchpad-dev mailing list, summarizing what you and your buddy discussed.
 * Your buddy may also want to send a short summary of the call to the launchpad-dev mailing list, e.g.:
  * Spent 10 minutes talking over how to tackle xxx with Julian. Agreed that the right approach is to extend the existing YYY interface rather than adding a new interface.
Line 43: Line 45:
 What do you mean by this? Are you talking about User interface across the pillars or internals? Design phone calls are not focused on the ui specifically, rather on the broader scope of how to implement the work being tackled. They are not a replacement for the specification process, which is the level at which architecture takes place. I short, I dont think this specific thing being added here makes much sense, or if it does, its needs more explanation -- RobertCollins  * What do you mean by this? Are you talking about User interface across the pillars or internals? Design phone calls are not focused on the ui specifically, rather on the broader scope of how to implement the work being tackled. They are not a replacement for the specification process, which is the level at which architecture takes place. In short, I don't think this specific thing being added here makes much sense, or if it does, its needs more explanation -- RobertCollins

Overview

Launchpad developers are strongly encouraged to conduct pre-implementation design phone calls. These calls serve a kind of virtual pair programming function, not only assisting the caller but also the callee. The calls should lead to an improvement in the design of feature and bug fix implementations.

You will be asked by your reviewer whether you conducted a pre-implementation phone call, and you are expected to include this information on your merge proposal. It is your responsibility to find a pre-implementation review buddy.

Pre-implementation calls are expected even for trivial bug fixes or features. For these, a question as simple as this can suffice: "I think this bug has a trivial fix, do you agree?".

Workflow

Before starting coding on a feature, everyone should now have a brief VOIP call with another Launchpad developer. This includes the review team members - they still have to contact another developer! Here are some criteria you can use to find an appropriate buddy:

  • Your pre-impl call does not have to be with a Launchpad reviewer.
  • All Launchpad developers are encouraged to participate as both callers and callees.
  • Find someone more experienced than you.
  • Find someone less experienced than you.
  • Find someone who is familiar with the area of Launchpad that you will be changing.
  • Find someone who is unfamiliar with the area of Launchpad that you will be changing.
  • Try not to overload any one reviewer.
  • Try not to overload yourself doing reviews.
  • Ask around on #launchpad-dev first
  • When in doubt, ask the on-call reviewer/s in #launchpad-reviews. They will either be available to help you (it's part of being on-call) or suggest another developer who can help.
  • Community developers must have a pre-implementation call for all work. No exceptions. The call must be with a domain expert (someone from soyuz, bugs, registry, translations, etc).

Here is the workflow for doing pre-implementation phone calls:

  • Before starting on a feature, the developer will contact a suitable buddy and ask for a pre-implementation design review call. Start by asking on #launchpad-dev to see if anybody is available.
  • The buddy may accept the request or may suggest a different developer to take the call. (The buddy will be considering their own load, the area you are working in and their knowledge, and the size of the thing you are working on in deciding how to respond).
  • After deciding who will be your buddy you may move on to the next step of the development process. However, you will need to note this resolution for inclusion on your merge proposal. Your branch reviewer will also ask you about your pre-implementation review call. Examples of what you might say:
    • Pre-implementation review call with spiv
    • Bjorn said 'zzz is too trivial, just do it'.
  • For non-trivial calls, you may also find it helpful to send an email to the launchpad-dev mailing list, summarizing what you and your buddy discussed.
  • Your buddy may also want to send a short summary of the call to the launchpad-dev mailing list, e.g.:
    • Spent 10 minutes talking over how to tackle xxx with Julian. Agreed that the right approach is to extend the existing YYY interface rather than adding a new interface.

Comments

  • The reviewer will try to compare your approach against known architectural standards to ensure it's consistent. Should you be extending an existing piece of code, please ensure that it's the same across all Pillars. -- JoeyStanford

  • What do you mean by this? Are you talking about User interface across the pillars or internals? Design phone calls are not focused on the ui specifically, rather on the broader scope of how to implement the work being tackled. They are not a replacement for the specification process, which is the level at which architecture takes place. In short, I don't think this specific thing being added here makes much sense, or if it does, its needs more explanation -- RobertCollins

DesignPhoneCall (last edited 2010-02-19 21:27:33 by flacoste)