Michael Meeks wrote: > Nope, seems a good summary; one of the ideas I came up with was of > splitting the work-flow aspects [ step1: create iTeam, step2: design, > step 3: review, step 4: implement ] etc. from the other pieces that are > necessary for QA / docs / i18n etc. ie. providing separate guidelines > for how teams can function, and develop software vs. what information / > approvals are necessary to get changes included in the product.
I don't see our discussion related to the way something is implemented, so this splitting IMHO is an implicit one. So my idea was (and still is): step1 - idea: mandatory ;-) step2 - create iTeam: optional at this point in time as we can't expect it for all community work step3 - design/review/implementation cycles: indispensable :-) step4 - create iTeam if not done in step2: possible to be done by project lead; now mandatory as needed for the next steps step5 - finalize documentation aka "spec" to the necessary degree as negotiated inside the iTeam; possibly with help from iTeam or Project Lead step6 - QA, maybe fixing bugs, documentation: how could we do without? ;-) Does that make sense? Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
