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

Hi Sophie,

Sorry for the late reply. I was busy with other things.

Sophie Gautier wrote:

> I join Christian here, it's not about getting feature implemented but 
> influence the decisions that are taken.
> 

It is hard to find the right level at which this can happen and where 
this separation is possible.

The decision how much effort should be put into a feature can't really 
be separated, but that decision in turn is strongly interrelated with 
decisions about the feature itself and what shape it should take on a 
high level. OTOH many detailed decisions can only be taken when there is 
a solution design and maybe even a prototype, which means that the 
decision to address the feature has been taken already (otherwise who 
would do the work on the design or prototype).

>> OOo 2.0 had one big step forward in handling planned changes by making 
>> most of the work public. The 'Q concept' was published, specs were 
>> published and announced - sometimes well before implementation and 
>> most feature issues were entered in IZ instead of the Sun-internal bug 
>> tracking system. This already would have allowed community 
>> participation, but it was not explicitly solicited. It is my 
>> impression that this opportunity was not used very much.
> 

> I agree with you and here I wave between two feelings : 1) the community 
> was not mature enough to measure this level of sharing, 2) Q-concept and 
> specs have not been explained correctly to the community.



> As for EIS where informations about QA are missing, we need also to be 
> aware where and when we can intervene and when and where we can't.
> 

Understanding this probably requires a deeper understanding of the 
development process. I believe this was not very easy in the early 
stages of the OOo 2.0 release cycle. But thing should have improved 
since. We now have the CWS (child workspace) process open to community 
developers, so the way things get implemented is visible and documented 
for the non-Sun community.

Participating in this also requires a QA process that integrates the 
community QA and possibly a process to do early (pre-integration) 
feedback releases from child workspaces. Both of this isn't really there 
yet. This is probably something the qa project should try to set up.

But if you want to influence design decisions, this will probably have 
to start earlier, which means were are back at the RFE and specification 
process.

>> But now OOo 2.0 is approaching a close and now is the time to return 
>> to the things that were formerly postponed to 'post-2.0' and to 
>> consider any new ideas for the 3.0 release cycle. This is what Louis 
>> is doing here.
> 

> That is also where we are trying to help him and please, don't forget 
> why this conversation appeared :)
> 

Yes. I was only reinforcing this.

>> What did you foresee would happen with the RFE process? AFAICT the 
>> plan was to implement a better RFE process for the release after 2.0,
> 

> oups, I was not aware of that. We have begin to work on RFE process some 
> time ago now and nobody told me that it was postponed after 2.0. Anyway 
> I have postponed my participation because nothing was moving at all.
> 

Not sure if this was a formal decision. This was just my impression, but 
I really have nothing to do with the RFE process myself. I noticed that 
progress on the RFE process was stalled and when looking for reasons I 
had the feeling that everyone (i.e. at least the relevant Sun people) 
was very busy with 2.0. I also recall my impression that this work 
wasn't really productive at the time, because most 2.0 deadlines were 
passed already and planning for post-2.0 was still far away.

>> this is still possible and you can participate in making that a 
>> reality. If you don't participate, you shouldn't complain if it 
>> doesn't happen. And if you and others don't participate because you 
>> 'foresee' it not becoming a reality, then that may simply be a 
>> self-fulfilling prophecy.
> 
> 
> What if you participate (or try to) and been answered that your complain 
> is not the good one because you're not representative ? All the work we 
> are trying to do here is to answer this question.

I was really referring to participating in designing a RFE process. I 
have not heard of process suggestions being turned down because the 
proposer is not representative.

Of course such a process will have to deal with the fact that any given 
RFE may not be good for all users and that anyone who implements 
features (e.g. Sun) will value the perceived needs of their target group 
higher than those of the general community (representative or not).

>> Of course the very long release cycle we've been having is a large 
>> part of the problem and because of it most RFE submitted after the 2.0 
>> planning phase are still waiting in some queue. But that this is a 
>> problem is known and there is an ongoing discussion how this problem 
>> can be avoided - again for the time *after* 2.0.
> 

> Where is this ungoing discussion taking place ? Why aren't we part of it 
> or do I miss to subscibe to a list ? What about regressions that are not 
> RFEs and targeted to OOolater ?
> 

This discussion is also moving slowly. There was some visible activity 
on OOoCon 2004 (e.g. a presentation by Matthias Huetsch). Since then 
there wasn't much public discussion on this. I assume that the ESC 
and/or the CC may still have this on their agenda. Again this release 
cycle discussion is something that should be revisited now for post-2.0 
planning. Actually this has to happen anyhow, as we need to decide how 
big our next release(s) will be...

>>> Honestly saying, I don't really know, why I care about issues, that 
>>> could be resolved within minutes .. 
>>

>> How do you know that? If you know, why don't you resolve them 
>> yourself? Do you have examples? Do you consider that changing the user 
>> interface requires more than changing the code (e.g. specifications, 
>> documentation, translation).
> 

> Most leads here are aware about documentation, translation and so on :)
> 

Yes. But people who suggest that UI changes may be simple and take 'only 
a few minutes' apparently are not.

>> There certainly were problems with how some issues were handled. But 
>> all participants occasionally make mistakes (e.g. some issues remain 
>> unhandled, because they have the wrong owner, component, status or 
>> target milestone. If you see some systematic problem, then you should 
>> attempt to get the process improved. For RFEs the need to improve the 
>> process is known and has just been sleeping.
> 

> Well, hard to hear when a new process has been put in place in July and 
> that you have take some time during your vacation to work on it !

Not sure what you are referring to here.

> And yes there are some systematic problems that either the community and 
> Sun have to adress, this is what we are trying to do, I guess

I think the main point is that the non-Sun community and the involved 
Sun people need to get *together* to figure out how they can collaborate 
here.

> This is why I don't want to see new categories in IZ, or anything else 
> where we try to work on that anyhow will be ignored. As I said, we have 
> no time and energy to waste on a process that leads nowhere.
> 

Are you sure it won't lead somewhere eventually? I can understand that 
you are reluctant to put effort into the first parts of a process when 
the next steps and the entire picture are not yet clear. So probably 
finishing the process should have priority now, even if it means holding 
off on actual work on RFEs even longer.

> I recognize that we have missed the specs publication. So now we will 
> work with them, a team is already in place in my project and I've asked 
>  Christian Jansen to add a target for all projects specs when he will 
> have time.

There have been ideas floated to track spec handling and QA tasks in IZ, 
like implementation tasks are tracked today. Maybe that would help get a 
visible handle on them.

> I know that we shouldn't discuss about this on issues, going on the 
> dev@project list and speak to the developper in charge is a possibility, 
> but this is not a clear and good process when :
> - the developper is already working on the features, it's too late
> - each time you have to proove that you are speaking for a community and 
> not on your own name,

I don't think you have to prove that. But if you are convinced that you 
solution is better than his, that yours is important to many people or 
that his is detrimental to many people, you surely need arguments. 
Actually I think that numbers like votes or duplicate issues are not the 
best arguments, because they may be the input of a vocal minority.

> - each time you have to proove that the feedback you've got from your 
> community is as important as the one Sun has. This is exhausting.

If the developer is paid by Sun, he is obliged by his job description to 
implement what Sun customers need (however Sun determines that). Thus he 
must to care about requirements he received through Sun-internal 
processes. For anything beyond that you need to convince him that doing 
the extra work is in the interest of Sun or the OpenOffice.org project. 
I don't really see a way around that. The same applies analogously for 
other implementors or project leads, if you want them to change their 
plans.

> - there is no way here for us to imply companies that want to implement 
> a complete feature,

I'm not sure I understand this sentence. Companies (e.g. Ximian/Novell) 
already have implemented entire features. If you don't have such a 
company for your feature, you may try to get together a group of 
individuals that can complete the task. In any case it is best to 
communicate with the responsible project lead before you start to avoid 
duplicate or contradicting efforts and to make sure the feature will be 
accepted (i.e. does not contradict OOo plans or concepts).

> - there is no way for us to give a clear representation of the needs of 
> our users base.
> 

Why? That would be up to you wouldn't it?

The point that is unclear is how you can feed that into OOo processes so 
that it will be heard (and hopefully implemented, even though you said 
you didn't care about that).

Ciao, Jörg

-- 
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         [email protected]
OpenOffice.org Configuration          http://util.openoffice.org