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.
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 :-)
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
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
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
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
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
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
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
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
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
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
12 matches
Mail list logo
