Michael Meeks wrote: > Hi Mathias, > > On Tue, 2006-11-07 at 19:40 +0100, Mathias Bauer wrote: >> 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): > > So - the problem is I discern ~no difference at all with what you > detail here and what we have at the moment :-) this doesn't strike me as > in any way improved:
Well, I see a big difference to what we *suppose* to have now but I think that you became totally absorbed to some of the terms we use and your own bad experience with it. So I'm fine with leaving them out and I think you will see that we are not much apart. >> step1 - idea: mandatory ;-) >> step2 - create iTeam: optional at this point in time as we can't expect >> it for all community work > > I think having a separate flow for internal Sun people would be better, > rather than cluttering substantially different flows with confusion / > unhelpful terminology IMHO etc. These *are* separate workflows. A Sun engineer would create an iTeam upfront, a community developer would ask for QA and documentation work when he is done with this implementation. I just called this the iTeam but if your prefer we can name it as you did: > post mail to UI/Doc/l10n/project lists with link to > CWS, *minimal* spec. & working build My addition to this would be that an issue should exist and the Project Lead should have been informed until then (the earlier the better) so that he can help to avoid the usual problems mentioned here (not finding QA engineer, no response from UserEx etc.). >> 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 > > "create iTeam" is problematic in several ways: > > * it's easy for people in Hamburg > * it is ~impossible for people outside Hamburg. It isn't, but it's harder - that's the reason why I wrote "possible to be done by project lead". > * it is synchronous I don't think so. An asynchronous process it fine for me - but it shouldn't be a "fire and forget". The developer should still feel responsible for his work and so shouldn't rely on others doing the further work for him. > * it implies some 'Team' thing instead of it's real role > which should be one of review / approval. I don't understand this - but perhaps my explanation made my standpoint more clear and your point possibly is now obsolete. > So - what I would like to see: > > + step 1 - create kick-ass feature/tweak/fix for fun > + step 2 - look on IRC for people to discuss with for improvements > => no-one, so on to next step. > + step 3 - write *brief* spec > + step 4 - get build-bot build > + step 5 - post mail to UI/Doc/l10n/project lists with link to > CWS, *minimal* spec. & working build Sounds good and that's more or less what I wanted to describe in less detail ;-). So if you leave the word iTeam out and take it as a variable to be replaced by a number of people doing the UI/Doc/l10n/QA work (though I think that UI problems should have been sorted out before we reach this state). > + the term 'iTeam' doesn't appear, the concept & associated workflow is > nearly antithetical to the sort of iterative, innovation that happens > outside Sun :-) I'm fine with leaving the term "iTeam" out though for me it never was the idea of people sitting together in a room but a group of people assigned to a common goal (to get a feature integrated). It happens in an "asynchronous" style even in Hamburg. 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. 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]
