Re: [native-lang] Update: Sun/NLC meeting

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