Hi *, On Fri, May 20, 2005 at 04:10:32PM +0200, Joerg Barfurth wrote: > 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.
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. On 1), there's nothing the community can do, Sun pays for it so Sun decides where to spend its ressources. 1) Is the handling in issuezilla that currently lacks significantly. Not on the QA-part of it, but on the decision side. > 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). When a prototype or whatever information is missing the situation is the following: * the issue just sits there forever (like the other ones) But it should be like this: * people should be asked to provide the necessary information, spec, etc.. > [...] > >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. 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) * listening to/getting/asking for input from the community on the specifications The problem is that most of the feedback on the specs arrives once the feature appears in the product since nobody really knows about the spec beforehand. (This may improve once this is stated more prominently). There should be a way to influence these design bugs more easily (not by having such a big fight like for the quickstarter entries). > 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. 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...) > 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. If you mean with design "the direction the product is heading to", then no, the community doesn't need to be involved. It is Sun's decision on what it will implement and what things to reject (but again it should communicate the decision). If you mean with design "shaping the implementation of that paricular feature", then yes, the community should be involved; it should have some kind of "veto". > [...] > >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 It basically never started from Sun's (decision-taking) part. That's why the evaluation of the RFEs slowed down. Without getting the decisions on the issues the whole process doesn't make any sense. It is just shoveling the issues from one pile to another (reassign from bh to requirements). The only advantage of the process is that those issues got looked at at all, that the issues with rfe_eval_ok have a clear description. But that's all that was achieved. > [...] > 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. Well, I tried, but a process doesn't help if it is not followed. > 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). 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). Taking the quickstarter as example: Even after citing the specs and explaining why the specification did interpret microsoft's guideline wrong the "answer" was still "OOo works as designed", nobody tried to explain why this design decision was taken. Still the spec reads something like "in contradiction to the MS-guidelines OOo will have the startup-entries". This is something where I feel the community is not taken seriously. Another point is the saving of cursorposition (or now the lack thereof). The spec itself lists concerns by developers - but these notes are unanswered, the same for the issue. Only answer is "works as designed". The cursor-positioning-thing is a spec that I consider "badly designed" Another issue is the new mail-merge. Not the new mail-merge itself, but the removal of the "classic" way. > [...] > >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. Again we have to differentiate between two things: As you said: Sun pays the developer, has customers. Sun sets its priorities according to Sun's customers. I have no problem with that. Avoiding mistakes while implementing new features by including the community. While it is desireable if the community can influence Sun's priority (i.e. by votes or other means), this is by far not necessary. The second part however is a pressing problem, esp. when existing Features are affected or even dropped. > >- 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). Unfortunaltely, when the effort is not a bugfix, it is very hard to get it accepted (included into the product). While this has somewhat improved, this still lacks decisions. (Zoom in toolbar, word-count macro, fixed fonts in formula-editor, etc.) All were with patches, working solutions. > >- 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). I like to stress that indeed it is not about manipulating Sun's decisions, to force Sun to implement a certain feature (although this is of course a wish) - it is about /how/ to implement the feature and getting a response & early decisions on RFEs. This involves rejecting RFEs (and there is a lot of things that can easily be rejected or "delegated" to OOo-community-developers). But for this delegation to work, we're again at the decisions problem. You cannot reject or pass issues when you did not decide upon them... ciao Christian -- NP: Ill Ni�o - Liar --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
