Calendar:Development Strategies: Difference between revisions

Line 13: Line 13:
Lots of conflict can be avoided by careful ordering of work and by ensuring that code and UI owners are all on the same page throughout the development process.  Over the years, the workflow that we've seen that's most effective for driving bugs and features into the tree with the least amount of pain looks something like this:
Lots of conflict can be avoided by careful ordering of work and by ensuring that code and UI owners are all on the same page throughout the development process.  Over the years, the workflow that we've seen that's most effective for driving bugs and features into the tree with the least amount of pain looks something like this:


; 1. Get UI buyoff : Doing this before worrying about the implementation avoids large rewrites because of basic design differences.
; 1. Get UI buyoff : Doing this before worrying about the implementation avoids large rewrites because of basic design differences. mvl or dmose can set the ui-review+ flag in Bugzilla to indicate that they have signed off on the UI for a given change or set of changes.
 
; 2. Get basic code-level strategy agreement : Same benefit as 1.  Even if you have a pretty good idea of how to attack a bug, the code owner may have big-picture (or little-picture) information that would suggest a different strategy.   
; 2. Get basic code-level strategy agreement : Same benefit as 1.  Even if you have a pretty good idea of how to attack a bug, the code owner may have big-picture (or little-picture) information that would suggest a different strategy.   
; 3. Code with <u>ongoing</u> discussion : When you're wondering about some implementation issue, or see red flags (like having to copy/paste chunks of code, add weird dependencies, or violate abstractions), plunging ahead anyway is often the wrong thing to do.  Instead, talk to a code owner or peer.  Perhaps even post a patch fragment in the bug for input.
; 3. Code with <u>ongoing</u> discussion : When you're wondering about some implementation issue, or see red flags (like having to copy/paste chunks of code, add weird dependencies, or violate abstractions), plunging ahead anyway is often the wrong thing to do.  Instead, talk to a code owner or peer.  Perhaps even post a patch fragment in the bug for input.
Confirmed users
2,615

edits