Re: [dev] Specs. closer to a solution
Niklas Nebel [EMAIL PROTECTED] writes: If we consider User Experience involvement with UI changes important, we can't skip that step whenever they are too busy to look at a specific issue. Otherwise, we could do the same with QA: If they don't object within two weeks, a change is integrated. That would speed up things, too. :-) Hi Niklas, well, I guess the issue here is that UX has proven to be much more of a bottleneck than QA in the past. See that quoted issue in one of the first mails of this thread forest, where UX did not respond for ~.5 years. And while I think that UI cohesiveness/usability is important, I would compromise it (temporarily), to have otherwise useful and properly QAed features integrated - in the case an UX feedback request has timed out. And besides that, with documents like http://wiki.services.openoffice.org/wiki/OpenOffice.org_Guidelines and http://wiki.services.openoffice.org/wiki/UI_Style_Guides devs and QA should be able to design/verify good-enough UI in the first place - I would be very surprised if any UI atrocities would survive a proper QA cycle then. Given all this, I also second the timeout proposal. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Niklas Nebel wrote: Mathias Bauer wrote: Primarily interaction with User Experience, but also Documentation, l10n - I'd like to ensure not only that they have a clearly defined opportunity to comment / have their say; but that their window of opportunity here is time limited :-) 'discuss' with ... UserEx is fundamentally synchronous, and very hard to verify later, and perhaps open to lots of problems. Much as I hate process, I'd like to be able to point to a mailing list post and say no replies in 2 weeks = uncontroversial approved. I see. I think at least no developer (neither Sun or non-Sun) will have any problem to agree here. :-) One does. If we consider User Experience involvement with UI changes important, we can't skip that step whenever they are too busy to look at a specific issue. Otherwise, we could do the same with QA: If they don't object within two weeks, a change is integrated. That would speed up things, too. :-) If they are too busy doing other things I assume that they don't see the issue as important enough to work on it. In this case I don't see a problem going on without them. We can't make UX the single point of failure as currently where gazillions of issues are going mouldy being assigned to requirements and some patches aren't looked at because we are waiting for input from UX. If we ask developers to work on patch integration we also can expect some readiness for cooperation from UX. And a possible response in a 2 weeks time frame could be I don't have enough time for all the details but I don't consider this to be critical so please go ahead. In case they don't have time but consider it to be important something is going wrong and must be escalated. The importance of UX input is overestimated in many cases (IMHO). This is different for QA where I don't expect that we can do without. But QA can be done by people outside of Sun as all necessary tools are available for everybody. I don't see this possible for UX at the moment. 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]
Re: [dev] Specs. closer to a solution
Eike Rathke wrote: Hi Mathias, On Wednesday, 2006-11-15 18:24:43 +0100, Mathias Bauer wrote: The exact length of the timeout should be nailed by the ESC. 2 weeks seems to be enough IMHO. Depends on. If the person in question is on vacation it might not be enough. To prevent this situation enquiries should always somehow be made public, so someone may jump in or point it out. Vacation can't be an excuse for being unresponsive. This is a team effort and project leads or team managers should be able to monitor this. At least that's what happens in development. Why not in other teams also? I already mentioned that it should be clear that it can't be expected that a problem is always solved within 2 weeks. One reason for this might be vacation. So my constraint that automatic timeouts shouldn't take effect if people are responsive but just don't finish their work in 2 weeks should become rephrased: if UX doesn't give any answer in 2(?) weeks the developer(s) should be allowed to proceed without them. 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]
Re: [dev] Specs. closer to a solution
Hi! Niklas Nebel wrote: Otherwise, we could do the same with QA: If they don't object within two weeks, a change is integrated. That would speed up things, too. :-) Best would be: No QA, no Doc, no UserEx, just hackin' code ;-) I agree in making the processes transparent, liveable etc. for all stakeholders but it has to be also an agreement of them the we don't want to give the quality away we have already reached - means: no regression, no work hinderers (build and process breakers) anymore. Just for information: If the automated GUI testing can not be started on a [to be released] build we loose ~50% (over all modules, in some we have 95% in others less) testing code coverage. Do we all agree that it makes no sense to break this testing process which also being used by porting-dev to get things done on other platforms!? We all can also agree that we should invest in making it faster. Same for specifications: Yes, make it faster but don't give up the content needed by one of the stakeholders/customers of this document. And we already know which groups need which information. Time is never a valid reason to waste quality. Yours, Jogi -- === Sun Microsystems GmbH Joerg Sievers 20097 Hamburg Quality Assurance Engineer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Joerg Sievers wrote: Hi! Niklas Nebel wrote: Otherwise, we could do the same with QA: If they don't object within two weeks, a change is integrated. That would speed up things, too. :-) Best would be: No QA, no Doc, no UserEx, just hackin' code ;-) Hehe, paradise is lost. At least when we started to get users :-) But we didn't talk about QA or documentation *work* here, we are talking about cases where exactly this does *not* happen and what we should do in these cases. I agree in making the processes transparent, liveable etc. for all stakeholders but it has to be also an agreement of them the we don't want to give the quality away we have already reached - means: no regression, no work hinderers (build and process breakers) anymore. I didn't read any proposals here that we wanted to leave that path. OTOH I really would like to open another discussion (means: a new thread) about what developers could do to make GUI testing or parts of it unnecessary in some defined cases. This will save us some time in QA so they will have more time for other CWS where perhaps more testing would be desirable. Do we all agree that it makes no sense to break this testing process which also being used by porting-dev to get things done on other platforms!? Yes, for me that goes without a saying: we shouldn't lower the QA barriers. AFAIK the problems for volunteer developers we had in the past wheren't causes by too exhaustive testing but by no testing happening at all. We could do us all a favor if we could avoid this situation in the future and if all people involved developed a positive attitude towards community contributions - even if they are presented in a less than perfect way. 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]
Re: [dev] Specs. closer to a solution
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]
Re: [dev] Specs. closer to a solution
Hi Mathias, On Wed, 2006-11-15 at 12:39 +0100, Mathias Bauer wrote: Which timeouts are you talking about? Primarily interaction with User Experience, but also Documentation, l10n - I'd like to ensure not only that they have a clearly defined opportunity to comment / have their say; but that their window of opportunity here is time limited :-) 'discuss' with ... UserEx is fundamentally synchronous, and very hard to verify later, and perhaps open to lots of problems. Much as I hate process, I'd like to be able to point to a mailing list post and say no replies in 2 weeks = uncontroversial approved. 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. Of course, but we have our own people (or other engineers) that can do QA - so, if there is some check with UI / Docs / l10n implied by QA then that piece needs to be asynchronous. 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. Indeed :-) it'd be good to talk; perhaps best to rubber-stamp (or recommend to the Community Council (or whatever) the draft result ? Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Michael Meeks wrote: Hi Mathias, On Wed, 2006-11-15 at 12:39 +0100, Mathias Bauer wrote: Which timeouts are you talking about? Primarily interaction with User Experience, but also Documentation, l10n - I'd like to ensure not only that they have a clearly defined opportunity to comment / have their say; but that their window of opportunity here is time limited :-) 'discuss' with ... UserEx is fundamentally synchronous, and very hard to verify later, and perhaps open to lots of problems. Much as I hate process, I'd like to be able to point to a mailing list post and say no replies in 2 weeks = uncontroversial approved. I see. I think at least no developer (neither Sun or non-Sun) will have any problem to agree here. :-) The exact length of the timeout should be nailed by the ESC. 2 weeks seems to be enough IMHO. I hope that in cases where the person asked for a comment is helpful but isn't able to accomplish this in 2 weeks just because it is a lot of work to do nobody insists on a 2 week deadline. IMHO this could be a good reason for an ESC meeting. Indeed :-) it'd be good to talk; perhaps best to rubber-stamp (or recommend to the Community Council (or whatever) the draft result ? Sounds good to me. 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]
Re: [dev] Specs. closer to a solution
Mathias Bauer wrote: Primarily interaction with User Experience, but also Documentation, l10n - I'd like to ensure not only that they have a clearly defined opportunity to comment / have their say; but that their window of opportunity here is time limited :-) 'discuss' with ... UserEx is fundamentally synchronous, and very hard to verify later, and perhaps open to lots of problems. Much as I hate process, I'd like to be able to point to a mailing list post and say no replies in 2 weeks = uncontroversial approved. I see. I think at least no developer (neither Sun or non-Sun) will have any problem to agree here. :-) One does. If we consider User Experience involvement with UI changes important, we can't skip that step whenever they are too busy to look at a specific issue. Otherwise, we could do the same with QA: If they don't object within two weeks, a change is integrated. That would speed up things, too. :-) Niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Hi Mathias, On Wednesday, 2006-11-15 18:24:43 +0100, Mathias Bauer wrote: The exact length of the timeout should be nailed by the ESC. 2 weeks seems to be enough IMHO. Depends on. If the person in question is on vacation it might not be enough. To prevent this situation enquiries should always somehow be made public, so someone may jump in or point it out. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Hi Niklas, On Wednesday, 2006-11-15 19:18:30 +0100, Niklas Nebel wrote: One does. If we consider User Experience involvement with UI changes important, we can't skip that step whenever they are too busy to look at a specific issue. In that case they can at least say so. I think having a timeout should be for the cases where one doesn't receive any answer at all. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Specs. closer to a solution
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 (?). 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 ? ;-] 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 ;-) Anyhow, thanks for your time, Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
