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 [EMAIL PROTECTED] 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
