Michael Meeks wrote: > Hi Mathias, > > So - I think your summary here is great: > > On Wed, 2006-11-08 at 14:41 +0100, Mathias Bauer wrote: > ... snip various good points... >> So perhaps we can describe it so (with less details ;-): >> >> (1) While developing your feature: discuss feature with people on IRC, >> mailing lists and whatsoever to your liking; it is *recommended* (though >> not mandatory) to contact the project lead as early as possible and >> discuss with QA and UserEx also (not to ask for approval but to avoid >> problems by early contact!). >> >> (2) While development happens make sure that at the end you deliver a >> "spec". This could be just an issue in IZ, a web page or a document, >> details can be described elsewhere. BTW: I consider having an Issue in >> IZ mandatory as we need to have a reference for cvs commits. >> >> (3) Get necessary builds (perhaps by using build bots) and hand builds >> and "spec" over by announcing them somewhere(we must define where!) so >> that QA, translation and documentation can start working on it. >> >> (4) React on feedback given by them, be it changing the "spec", fixing a >> bug etc. > > One thing - we managed to loose the timeouts here :-) since > non-responsiveness has been a bug-bear for some years, and is one of > those things that may vary substantially over time depending on mgmt > imperatives & focus, I really want those in there. > > In order to have a 'fair' timeout, it's necessary to have a > time-stamped, reliable, agreed communication medium and length of > timeout: a mailing list is fine for that I guess; but it should be > specified. Possible an early 'features@' post is sufficient (?).
Which timeouts are you talking about? step(1) doesn't need timeouts as nothing is mandatory - everything is a recommendation to avoid problems later on. step(2) is a duty for the developer, he can decide about timeouts on his own. ;-) step(3) also doesn't need a timeout as nobody is waiting for anything/anybody. You might need to force the people involved to hurry up a bit if you wanted to get you work into a particular release, but that's nothing that can be handled by timeouts IMHO. If QA people don't have time to test your CWS there is no way to workaround this. If the QA people just forgot about it you might need an escalation path and not a fixed timeout. IMHO the project lead is the best choice here but possibly also the release committee we just have revived. step(4) once again is a duty for the developer. But perhaps I misunderstood something, so in this case please explain. > > On the other hand - the real strength of your outline is that it is not > too rigid / specific: and can be iterated later and expanded as needed > to cover unforseen cases [ wow, have I converted you to an iterative > process development model ? ;-] No, as we already practice it - just not in the same way as you wanted as to do. But inside a CWS and even sometimes stretched over several of them we already did it. > So - where do we go from here ? > > I believe Kai volunteered to write some of this up in the Wiki > somewhere as a conclusion, so we actually move to the "decision making" > phase after the lengthy discussion ;-) IMHO this could be a good reason for an ESC meeting. 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]
