Hi,
Christian Lohmaier wrote:
On Fri, Jun 03, 2005 at 12:33:34PM +0200, Joerg Barfurth wrote:
For the second point: it is
tedious to do this, but the rfe_eval flag/process can be the vehicle to
do it.
But why do you spend time on something that leads to nothing?
How do you know that it won't?
This is the big problem why evaluating (=quality controlling) of the
RFE-process has "stalled".
I can see that you'd like faster responses. But apparently that is not
the way Sun UE organize their work. Meanwhile presorting and enhancing
RFE issues is the one thing you can do to prepare things for the time
when RFE processing is resumed.
Which is sort of dangerous. I know that queries for 'no target milestone
assigned' are sometimes used to find issues that need this kind of
evaluation.
In the case of RFEs no TM has been processed at all in the meantime.
Again: I don't know how Sun UE organize their work and have no influence
on that. I also don't know what 'in the meantime' refers to. But if I
were in UE, I'd start by looking through issues without target milestone
(to decide between <next release>, Later, PleaseHelp and WONTFIX). After
a release I'd also look through Later, to see what fits the plans for th
e new release. When a new feature is shaped, I might also look at
existing PleaseHelp issues to see whether they are relevant. I'd never
look at issues that already have a special TM, like "Development Tools"
or "not determined".
I have used it (very rarely) for issues where an acceptable patch was
there, but the decision about the target branch/release was still open
or for issues where the target branch was known, but the target release
was unclear (e.g. I needed someone outside Sun to verify a change in
their build/port, but noone did).
Then you should have used the needhelp (and maybe the needmoreinfo)
keyword as well.
I probably did. I also actively mailed some people I thought would be
interested. When 2.0 is out I'll close the never integrated patch
against 1.1.x.
[...]
OTOH, waiting for super-reviews used to be one of the main bottlenecks
in contributing to mozilla, iirc.
AFAIK auch a review was necessary for every contribution, every patch to
assure the quality of the code (not to break other things). This whole
area is covered by CWS-QA in OOo.
I probably meant that if stuff is now stuck assigned to requirements, it
might then end up waiting for super-review. So it all makes sense only
if you find suitable super-reviewers that are willing to make this a
success.
True. But this already happened to a degree. But we have (or had?) very
long designated feature or UI freeze phases. And in those phases - and
even a certain time before the deadlines - little room for decisions
remains.
Nobody said that you have to consider the issues for the current
release.
Apparently that is the way the UE people work: they only look over
issues when there is a release they could put it into.
A shorter release cycle should also mitigate the effect of the long
freeze phases.
Freeze phases are irrelevant since it is not about getting the feature
into the product as fast as possible. It is about getting response,
feedback on the issue. Having the RFEs classified honestly.
See above.
No. When you finished planning for the current release, you can start
planning for the next one during feature freeze.
So far this hasn't been the case. Apparently people are still occupied
with a release after the planning phase. Shorter release cycles may
change this somewhat (you can't really do them without more continuous
planning).
Planning in this case doesn't mean: "Assign ressources" but "work on the
issue, evaluate it, classify it"-> Decide.
I looks as if our UE does not separate these tasks.
OTOH, if we take community RFE work seriously, why couldn't the
evaluation and classification be done by 'community RE'? It is only the
"*we* (Sun) will/may/won't do this" part that requires decisions by Sun.
And these decisions are very much driven by resources and internal goals
for the next release(s).
Try changing/influencing it *before* feature/UI freeze!
The issue was filed before UI freeze! (june 2004)
Which one?
IIRC the originally scheduled feature freeze date was in Juli 2004. And
at that time people were already retargeting stuff that they saw they
couldn't finish in time and otherwise struggling to get stuff done in
time for these dates. In that situation a request to rework a
specification that was just approved (or even implemented) can't easily
be accomodated.
IMHO that way of working is a problem in itself and I hope that more
frequent releases can solve that. It should reduce deadline pressure, as
slipping a release is not slipping for 2 years any more.
Such changes need not only a patch, but a specification - or an update
to the existing specification.
Nobody asked for such actions. And these things are old but still
unresolved (except the font in math's command-window)
If an issue is from an unfamiliar community member, I generally (have
to) assume that the submitter won't be able to do that themselves.
Nobody is saying that the reporter should supply one. If this really is
a problem, then a page "So you were asked for a spec..." could be
created.
Not sure I understand you. Generally the team that 'owns' the feature -
and that will implement it - (the i-Team) creates the spec. Generally
the reporter will not be expected or asked to do this. But every feature
needs a spec and doing this properly is work.
You wrote above: "such changes need[...]specification" I responded:
Nobody asked for such info. Then you said: You cannot expect the casual
submitter to understand what a spec is about, so I said: create a page
that explains all these (with informatin why a spec is needed, where to
get help creating one, etc).
I don't think casual submitters of RFEs are generally able to create a
spec, even if you give them more information. Only a more experienced
(e.g. in triaging RFEs) community member could do that. But they
shouldn't need to be told. So a 'community UE' group (analogous to
'community QA') could take on this responsibility.
But then you write this is an internal thing so again the problem was
not about missing informatin in the issue but the lack of decision from
Sun that the reporter/community could not influence.
Where do I say that this is internal?
In our process the i-Team is responsible for the spec, because all roles
represented there (UE, Dev, QA, Docs) are affected by the spec and must
contribute and ultimately affirm with their approval that the spec
fullfills the requirements and is sufficient for implementation,
creating tests and documenting the feature.
If you don't have a full i-Team, you can still do the initial writing.
But you should have an understanding of the development process and of
the target audience of the spec.
Ciao, Joerg
--
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer [EMAIL PROTECTED]
OpenOffice.org Configuration http://util.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
