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

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