Kohei Yoshida wrote: > On 11/3/06, Niklas Nebel <[EMAIL PROTECTED]> wrote: >> Kohei Yoshida wrote: >> > Another point I want to mention is that, perhaps the UI design >> > requirement at CWS integration time should be relaxed a bit. Instead >> > of requiring UE approveal of the UI change at cws integration time, >> > either QA or peer reviewer can pre-approve the UI and integrate the >> > code first. And queue the final UI approval to IssueTracker as a new >> > issue, assign it to UE (whoever that is) and set the appropriate >> > target milestone so that he/she can finalize it later. If UE thinks >> > that a UI change is necessary, request change to the developer so that >> > the finalization takes place before the public release. This way, the >> > process is asynchronous, and in line with our goal of fast track code >> > integration. >> >> Then we would end up with unfinished UI integrated into HEAD and >> potentially in a release. That's not good. > > The point is unfinished *to what degree*? I trust that a QA personnel > and peer reviewer can at least have enough intelligence to tell if the > UI is badly broken (hence reject it). But if it's not badly broken, > and functional to a sufficient degree, it should be okay to integrate > it. So, I consider that a 90% finalized at that stage, then UE would > add the remaining 10% (before the release). > > Admittedly my proposal does not include how to make sure it does not > slip into the release, though. :-)
Let's put it that way: it should be possible to integrate something even if the original goal laid out in the spec wasn't reached but the result is "good enough". "Good enough" means that we could live with it even if nothing was changed until the release date. This is something you always must take into account, especially in case of community development. That's what we already have done in many cases ourselves. Of course we adjusted the spec accordingly then and moved the missing pieces to the "future tasks" section. We never should accept unfinished UI work in a way that parts of the necessary functionality *willingly* don't work to a degree that users will expect in a professional application. This can't be described by a fixed percentage but I assume that it can be judged with common sense. If developer, QA and other participants agree that it's good enough, then let's take it. 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]
