Diff for "DesignPhoneCall"

Not logged in - Log In / Register

Differences between revisions 2 and 3
Revision 2 as of 2010-01-28 18:41:37
Size: 4102
Editor: bac
Comment:
Revision 3 as of 2010-02-19 21:27:33
Size: 4424
Editor: flacoste
Comment: Reflowed
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
<<TableOfContents(1)>> ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents(1)>>||

 * '''Name:''' Pre-implementation design phone call
 * '''Owner:''' Launchpad Team
 * '''Effective:''' Since Mathusalem.
Line 5: Line 9:
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. 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.
Line 7: Line 15:
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. 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.
Line 9: Line 20:
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?". 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?".
Line 13: Line 26:
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:
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:
Line 19: Line 32:
 * All Launchpad developers are encouraged to participate as both callers and callees.  * All Launchpad developers are encouraged to participate as both
callers and callees.
Line 22: Line 36:
 * 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.
 * 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.
Line 27: Line 43:
 * 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.  * 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.
Line 29: Line 47:
 * 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).  * 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 33: Line 53:
 * 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.
 * 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
 
tep 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.
Line 44: Line 78:
 * 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
 * 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

  • Name: Pre-implementation design phone call

  • Owner: Launchpad Team

  • Effective: Since Mathusalem.

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 tep 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)