Calendar:Development Strategies: Difference between revisions

Jump to navigation Jump to search

Calendar:Development Strategies (view source)

Revision as of 04:26, 18 May 2006

146 bytes removed ,  18 May 2006
no edit summary
No edit summary
No edit summary
Line 11: Line 11:
== Basic Bug/Feature Workflow ==
== Basic Bug/Feature Workflow ==


Lots of conflict can be avoided by careful ordering of work.  Note that these are all intended to be guidelines, not hard and fast rules.  Obviously, 5 line changes don't require this much coordination, and changes without much UI effect don't require the UI piece.  And issues encountered during coding sometimes effect design.  Et cetera.  These are all judgement calls.
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 (via the soon-to-be-defined UI design/review process) : Doing this before worrying about the implementation avoids large rewrites because of basic design differences.
; 1. Get UI buyoff (via the soon-to-be-defined UI design/review process) : Doing this before worrying about the implementation avoids large rewrites because of basic design differences.
Line 18: Line 18:
; 4. Review
; 4. Review


The above workflow is intended to help people start on the same page and stay there throughout the development process.  As a result, much of the feedback being requested is likely to be require significantly less time on the part of the code owner, so it should happen faster.  In other words, even though there are more points at which blocking can happen, the hope is that the total amount of time actually spent in a blocked state will go down.
Because everyone is better sync throughout, much of the feedback being requested requires less time on the part of the code owner than dealing with one big patch of the end of the process.  In other words, even though there are more points at which blocking can happen, the total amount of time actually spent in a blocked state is often less.


== Key success strategies ==
== Key success strategies ==


Pretty much everyone I've ever seen be productive and successful in
Pretty much everyone I've ever seen be productive and successful in
the Mozilla development environment has done so by deeply embracing a couple of key strategies.  I think the above guidelines are only really going to help us if we do too.  Specifically:
the Mozilla development environment has done so by deeply embracing a couple of key strategies.  I think the above guidelines only really work in combination with the following strategies:


*; multiplex work on multiple bugs : The key thing here is that whenever the existing bugs you're working on are waiting for feedback, go find another bug.  There are various strategies that help make this managable, including:
*; multiplex work on multiple bugs : The key thing here is that whenever the existing bugs you're working on are waiting for feedback, go find another bug.  There are various strategies that help make this managable, including:
Dmose
Confirmed users
2,615

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/26154"

Navigation menu