Hi Christian,
Christian Lohmaier wrote:
On Thu, Jun 02, 2005 at 05:39:37PM +0200, Joerg Barfurth wrote:
Christian Lohmaier wrote:
This kind of information is useless since almost all RFEs have the TM
"OOo later" or "---" which can be excachanged by each other without any
loss of information.
That shouldn't be the case. Before assigning any target milestone an
initial round of triaging should have taken place. Thus issues that are
incomprehensible, unacceptable or known to be duplicate should be closed
as INVALID, WONTFIX, WORKSFORME or DUPLICATE without ever getting a
target milestone.
I was only talking about issues in status "New"
I meant that issue that are NEW *and* have an assigned target milestone
(even if it is OOoLater), should be in much better shape and have
undergone an initial screening whether and when to address them, than
issues without target milestone.
To me target milestone "OOo later" signifies that the issue is basically
accepted as "should/could be implemented", but that noone has comitted
to working on it for one of the active releases.
This is true for defects, but not for RFEs (at least not in practice).
It should be. If this isn't true in practice, we need to (a) clearly
define and communicate the meaning and workflow for RFE states and (b)
clean up the backlog of issues that don't fit the rules. For the first
point: afaik there is an RFE workflow document on the qa site. Maybe it
needs to be improved or communicated better. For the second point: it is
tedious to do this, but the rfe_eval flag/process can be the vehicle to
do it.
- Our target milstone definitions are not clear enough or
- Our target milestone usage has not been communicated well enough
I cannot tell what the reasons is, I can only tell that I cannot
determine any difference between these target milestones when it comes
to RFEs.
There clearly is a difference between, "we hope we can do this later"
and "noone has taken any decision on whether or when this should be
done". Which also applies to RFEs. If past practice did not honor this,
we should change that practice instead of giving up the definitions.
The use of "not determined" is certainly underspecified. I can think of
at least two vastly different meanings.
True. I for myself used that milestone for issues that I evaluated
according to the new process, hoping that the evaluated issues would get
handled sometime soon and get a real target (or rejected)
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.
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).
That might make sense. But apparently the proposal did not reach the
right people (yet).
Given the fact that I came up with this a couple of times and mailing
lists (including the dedicated proddev-ML) I doubt it wil reach the
"right" people ever.
If you know who the relevant people are, you might try PM. The link you
gave to proddev hat this buried at the end of a mail deep into a thread.
For vetoing you need someone or some group that has been given the
authority for such decisions. This could be ESC, CC or project lead(s).
I don't think a 'veto' by a loosely defined band of reviewers would be
considered authoritative by a developer.
You missed the "super-reviewer" part of my proposal...
OK. That is a first step.
OTOH, waiting for super-reviews used to be one of the main bottlenecks
in contributing to mozilla, iirc.
But this renders the RFE-process pretty useless.
No the triaging and cleanup process can go a long way to ensure that
there is good material when the next planning session starts. So when
the time comes everyone can work on the real meaty stuff instead of
having to sift through the accumulated junk.
OK, it is not completely usesless, but bad RFEs should not have been
reassigned to requirements/bh in the first place..
True. But then again, the difference should really be whether a target
milestone is assigned. Having this special owner helps monitor all RFEs
in the queue, including those where initial triage is still in progress.
This "plan once for the whole release" is a big problem. It would be
much easier, transparent, satisfying if this would be a more continuous
thing with only the big changes planned beforehand (e.g. rewrite
chart-module, get rid of table-row limit, change table-handling in
writer, change toolbar concept,..) and leave room for decisions during
the implementation of the big issues, depending on how fast (or slow)
they proceed.
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.
A shorter release-cycle has similar effects, so I'm all in favor of
shorter release-cycles (more minor releases, not only major (does take
looong) and micro (only bugfixes))
A shorter release cycle should also mitigate the effect of the long
freeze phases.
Apparently everyone involved is simply too busy with work on the current
development version that new incoming RFEs are dealt with with minimal
effort. IOW noone feels they can invest the time to make even that decision.
I think they (those reassigning the issues) just don't feel responsible
or must not (are not allowed to) feel responsible for taking a decision...
Of course the first step towards a decision is to route the issue to the
people who are responsible for the decision.
Why does a long release cycle imply
######---------------------------------------######------
~~~~~~+++++++++++++++++++++++++++++++++++++++~~~~~~++++++
### planning phase, RFEs are evaluated
+++ implementation phase, ~ maintenance/bugfixing,
- no progress on RFEs at all.
Why can't it just be
######---##---#--#---##--#---#--#----##-----#-######--#---
~~~~~~++++++++++++++++++++++++++++++++++++++++~~~~~~++++++
I think reality is more like
######----#---##---#----X-------------------#--|######---
~~~~++++++++~+~+++~+++++X+~++~~+~+~~~~~~~~~~~~~|~+~++++++
where X marks feature/UI freeze and | marks the release. So the long
freeze phase is part of the problem. And prior to the freeze most
community efforts still concentrated on the stable version and trying to
get stuff added there (which again is due to the long release cycle).
AFAICT many of the disputed issues came up after or very shortly before
the freeze(s).
Another decision that can be taken easily almost everytime is
"needs a complete rewrite" vs "just like fixing a typo"
This one is an engineering judgement, not something a user experience
guy can necessarily judge.
Not for every issue, that's true, but there are many, many issues that
only affect the UI, some request a different wording or similar. Even
this kind of issue is only part of the pile (=sits there forever)
although you'd only have to replace the word "foo" by "bar". Same is
true for the opposite. Implementing new chart types surely is more work
than changing a string or resizing/reordering a dialog.
True. But the latter two involve more than meets the eye: linguistic
review, usability review, localization, documentation. That is why there
is a UI freeze (which implies string freeze). And after that freeze such
changes take extra effort (and may incur extra cost), so there is high
resistance against such changes.
What really bothers me is the following:
When you cannot change a small (implementation wise) point of a spec
with clear arguments, how could you influence spec only by request,
user-feedback, votes alone?
Try changing/influencing it *before* feature/UI freeze!
This is something where I feel the community is not taken seriously.
BTW. I can imagine that people who get swamped with loads of
inappropriate "me too" and "why don't you finally solve my pet issue"
issuezilla notifications can easily overlook the occasional more
well-reasoned IZ comment.
The related issue:
http://www.openoffice.org/issues/show_bug.cgi?id=30853
There are not that many me-too comments. The first one: Why do you
follow MS even when it doesn't make sense? - most people did only read
the OOo spec and did not have a look at the MS guidelines.
But the owner may own more issues that get similar (but less well
reasoned) comments.
What I am trying to convey: most developers (including user experience
people) are so busy with the current release, that new stuff gets only a
quick check whether it must be considered for the current release. If
the decision is 'no' (=> target milestone "OOo Later") they will not
look at it again until work on the current release is finished.
Even this kind of evaluation is only done for defects, not for RFEs.
Every RFE is OOo later automatically.
This is not entirely true. But yes, after initial planning - and even
more stringent when feature freeze is near or past - the defaukt target
for enhancement requests is OOoLater. I agree that we should leave more
room for manoeuvering during initial planning and be more flexible, at
least until feature freeze. But I'm not doing the planning ...
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.
Thus, if an advanced contributor wants to influence and contribute to a
feature, they can create one on their own account and then try to find
someone to implement it. This should be somewhat easier now, because a
noticeable part of the work is already done. Another benefit of creating
a spec is that it can be used to consolidate and reconcile multiple RFEs
concerning the same area.
But unless you can summon a complete i-Team and get approval from the
project lead, there is no guarantee that your spec will actually be
realized. Because of this, and because it is not the standard process,
you won't usually be asked to do this.
Maybe we should state this somewhere in the RFE process: to help an RFE
to get realized as a non-programmer, you can provide an initial
specification.
btw: In issue #i1820# there were requests for clear specifications of
the desired feature and some actual contributions which surely helped
clarify the request.
Of
course for patches that assumption is probably not warranted. But
feature issues get sent to the requirements people who can't themselves
judge the quality of a patch.
But by the patch they can judge/estimate the impact and effort.
The impact really can only be judged by a developer working in that
area. Unfortunately in some (older) parts of the OOo code base things
are so tightly coupled that the smallest change can have enormous side
effects. We work on untangling that, but we have to tread slowly and
carefully.
I've seen one-liners break almost the entire office. And I've seen very
small proposed initial patches, that required much larger and much more
distributed changes to make the feature complete and cover all aspects
of it.
But it is probably true that many of the StarOffice developers are not
really prepared for accepting or even encouraging community
contributions. First contributions often need a lot of hand-holding to
get them into a shape that they can be accepted.
From my POV this hand-holding works sufficiently well for contributions
for defects, but not for RFEs. Developers don't see RFEs -it seems- unless
told by UE ("have a look").
That certainly is part of it. It is the task of UE to bring RFEs into a
shape that the entire application behaves and looks consistent and is
usable. This includes bundling and reconciling multiple RFEs pertaining
to one area. As we have these experts for that task, I won't usually
start working on an RFE until it has gone through this process. If they
need a technical opinion on something in my realm they'll ask me. But I
agree that there are many cases where it would be useful to have the
developers of the affected module involved much earlier. In such cases
posting to the dev@<project> lists is generally much more effective than
working within IZ.
Ciao, J�rg
--
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]
