Hi,
Christian Lohmaier wrote:
On Wed, Jun 01, 2005 at 04:39:34PM +0200, Joerg Barfurth wrote:
Christian Lohmaier wrote:
These are two things.
1) Whether the feature is considered at all and
2) How the actual design of the feature will be
I think it is absolutly necessary to involve the community in step 2),
once the decision is taken.
What I meant to say is that for higher-level design step 2) is not
strictly after step 1), because you need to have an understanding about
the amount of work and the technical risk to decide whether to proceed
with a feature and for that you often need an initial design.
You can ask the community to come up with an initial design..
Surely the community cannot evaluate the technical risk, but I'm sure
the community can create a design spec that is usable and comprehensive.
Agreed. And I don't think anyone would keep you from doing this. I even
suppose that having an initial spec - even if it is incomplete in the
technical details - would raise the chances of getting a feature
considered or implemented.
1) Is the handling in issuezilla that currently lacks significantly. Not
on the QA-part of it, but on the decision side.
What exactly is lacking there? The most important source of information
about this kind of decision is the target milestone.
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.
Features/Enhancements with status New:
"---": 1654
"OOoLater": 1104
Between these two targets, ther is basically no difference at all.
The
same goes for "not determined". It depends on the one who reassignes the
issue on what target the issue will have.
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.
If this does not correspond to current TM assignments, then
- Either this accumulated historic cruft or
- Our target milstone definitions are not clear enough or
- Our target milestone usage has not been communicated well enough
The use of "not determined" is certainly underspecified. I can think of
at least two vastly different meanings.
The problem is:
An RFE gets filed.
-> it gets reassigned..
-> then <nothing happens for a long, long time>
-> then either
A) somebody stubles across the issue and realizes that it has fixed in
the meantime/does no longer appy and the closes it - or
B) it continues lying around
Checking whether old issues still apply for the next release is another
big task. And this is another reason why early decisions or evaluation
often are impossible: you need to look at feature issues from the POV of
the preceding release to decide whether they are worthwhile.
The only actions on RFEs are regular users adding their comments (mostly
complaints "This is so serious, how dare you to ignore this one")
The longer such comments accumulate the more time the handling will
require, so as a result less issues will be dealt with.
The problem is not the actual programming work - this has improved much.
The problem still is
* getting decisions (no visible reactions on RFEs in issueZilla)
In many cases there simply are no decisions yet - except that the
feature is not considered for the currently active release branches.
Yes! And that is exaclty the problems: No decisions.
Right. And my answer is: to get faster decisions, we need shorter
release cycles.
The 'comment' that shows that is, if target milestone 'OOo later' is
assigned.
I'm not sure whether I understand that one properly. Are you saying: TM
OOoLater means: not considered for active release branches"?
Sort of. Of course there are other target milestones that also imply
this. To me OOo later means: From todays view it makes sense to
implement this for OOo and the owner intends to do this sometime; noone
has committed to implement this for a currently active release branch
(atm those are OOo 1.1.x or OOo 2.0.x), but when work on the next
release starts the issue will be revisited.
If there is a decision to implement is, it will be assigned an
appropriate concrete target milestone. OTOH if a planned issue can't be
handled after all due to time constraints or changes in planning, it
will be reset to OOoLater.
Then I respond: Everything without a TM OOo 2.* is not considered.
Yes OOo 1.1.* and OOo 2.0.* are the only active release branches.
That by itself would not be a problem. The problem is that these not
considered issues reach back to the very beginnings of OOo. - That the
timeframe between reporting the issue and getting considered is huge.
The older issues get, the more sense it makes to either do or reject it.
But it may well be that an issue is no developer's priority although it
makes sense. Such issue may stay open very long.
The qa-Project is ready. What is needed is a process on how feedback on
the specs will be handled. (Here I come again with my review-system...)
http://qa.openoffice.org/servlets/ReadMsg?list=dev&msgId=1058032
http://marketing.openoffice.org/servlets/ReadMsg?list=proddev&msgNo=79
That might make sense. But apparently the proposal did not reach the
right people (yet).
Generally I'd think exchanging mail with
the i-Team and/or the relevant dev@<project> list is the way to provide
feedback. It then depends on the i-Team members what they do with the
feedback. Systematically we can provide guidelines or recommendations
for dealing with feedback but ultimately the team takes the decisions.
You mentioned the problem that votes on issuezilla and of feedback by
individuals would not be representative of the user-base. A set of
"reviewers" (e.g. representatives of the native-lang-project) would
certify with their approval that the issue is important - not only for a
handful of noisy individuals, but for many,many people.
Still the ones who do the work are free to do with the feedback what
they want. So we are back at the need of an appeal process to an
authority that is entitled to overturn decisions by individual developers.
Wrt. vetoing: yes, we probably need a defined process to appeal/escalate
arguments to project leads, CC or ESC.
here the review system again. The initial idea was that it should
accelerate getting a decision on lousy to fix RFEs, bypassing the
product-planning phases. The reviewers should make sure that the issue
really qualifies for an accelerated decision (small impact, really lousy
to fix) - But the same system can be applied to vetoing.
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.
It basically never started from Sun's (decision-taking) part. That's why
the evaluation of the RFEs slowed down.
Between feature freeze for one release and the time when work on the
next version seriously starts, there isn't much to decide, except
whether a certain RFE is so exceptionally important that it warrants a
freeze exception.
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.
And that process - maybe combined with your review idea - could also
yield the (few) issues that are so important that they should be fixed
on the existing stable release.
Again, I think that a shorter release cycle is the only way to
effectively address this feeling of futility.
Again: It is not about getting "our will", getting the feature
implemented. It is about getting a response, getting a decision in a
timely fashion. (I don't consider two years as an acceptable timeframe).
Neither do I. But that really is a problem of the long release cycle,
not of the RFE process. If even the start of the next release cycle is
months away, then there is not much point in taking decisions for
decisions' sake.
No. I disagree. Many things can simply be rejected - even without big
planning.
But almost every issue that is flagged rfe/feature is reassigned, no
matter how irrationale it is.
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.
They will likely be obsolete when the real work
commences.
Again I disagree. A decision like "Will never be part of OOo even when a
patch existed" or "Sounds interesting" should be possible at any time.
They still require a serious look at the issues.
Same for a evaluation like "Only useful to a handful of people" and
"affects almost everybody". Just pass these "only for a handful"-issue
to the community (close them with OOoPleaseHelp target)
The same.
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.
This doesn't need to be 100% correct everytime since it is only a quick
evaluation of the issue, but it will help to reduce the number of
unanswered issues.
As an user, I would appreciate an answer "We won't implement it" far
more than waiting forever without knowing what the status is.
I agree. I also agree that any state/target/owner change should be
accompanied by a comment that really indicates what is happening and
why. But we probbaly need to get agreement and commitment on this by the
people doing that work.
Most decisions are taken in the early phases of a release
cycle. I also hope we can find a way to get quicker release cycles to
work - that should solve the timeframe problem.
Again I disagree. For a release cylce the decision basically is "Hmm,
what features will we pick for implementation this time" and not "What
features do we want in our product":
Yes. But the latter question needs to be reevaluated basically after
each release, looking at where we have come meanwhile. I guess that is
the reason why the people doing it prefer to do both parts together at
the same time.
To me these are two very distinct types of decisions that are
unfortunatly taken at the same time with the current process.
Having different opinions is OK, not explaining them is not. The author
did not post his interpretation to the issue, did not try to explain why
he has a different interpretation/how he came to his interpretation.
I agree that it should be explained. In that [quickstarter] case, wasn't
the interpretation of the original author cited in the original spec?
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.
As I have said before, it is a worthwhile goal to improve this for the
next version. But things happened to late for the 2.0 feature cycle.
And I have been trying to say: It is not about the release-cycles, not
about getting the features implemented.
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.
I agree that it would be useful, if everyone took at least the time for
an explanatory comment.
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. 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.
As a result it may be underestimated what the community members behind
an issue could do themselves.
Maybe this could be addressed with a better process, that tells patch
submitter what they should or need do to get their patches in (creating
specs, assigning issues to right owners, asking the right people, ...)
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.
I can't really offer a quick solution to the problems. I guess it takes
more learning on both sides.
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]
