Hello Sophie, I think that the way Christian and you have to work with the RFE has the merit to be very efficient and clear on the objectives. With this we could at least know the likelyhood of RFEs to be implemented, by Sun or by someone else, or not at all . But for this to happen, Sun needs to be really transparent this time, and the community, through the NLC needs to stay coordinated and motivated. I don't worry about the community, but I worry about the transparency. And this is not to criticize Sun, I know they're doing a lot, and I know things are improving. But still the handling of issues by Sun is not satisfactory.
Best, Charles. On Wed, 2005-05-04 at 23:19 +0100, Sophie Gautier wrote: > [Hi all, > > This is the 7th time I try to post on the list, I put Charles in copy in > case he could forward it, thanks] > > Hi Louis, all > > Louis Suarez-Potts wrote: > > > Friends, > > > > Earlier this year,[1] we held an emergency meeting whose purpose was to > > clarify the position of the NLC leads regarding changes made to OOo and > > to see about being included as early as possible in the process deciding > > those changes. It was understood by all that as Sun largely determines > > the shape of SO/OOo (OOo being the same codebase as SO), that we would > > have to negotiate with Sun marketing directly. > > > I'd like to recall here that this request was not only concerning RFEs, > but also existing features that are removed or changed without any > concertation. As a good example of our help and contributions I'd like > to point two of them (no, no this is not the Stylist ;) among others : > http://graphics.openoffice.org/servlets/ReadMsg?list=dev&msgNo=631 > http://qa.openoffice.org/issues/show_bug.cgi?id=48059 > related to this one > http://qa.openoffice.org/issues/show_bug.cgi?id=36372 (the feedback I > had from ministries is very strong here). > > > > > Late April, after numerous delays, an initial meeting was held by > > Erwin Tenhumbeg, Young Song, Iyer Venkatesan, and me, to discuss how to > > proceed. Iyer and Erwin are product managers involved with StarOffice > > and OOo; Young of course works with the l10n groups. This meeting, > > though, which focused on the NLC communities, goes beyond them. > > > Thanks to all for this meeting and thanks Louis for sharing this with us > > > > > The meeting was quite positive. We all want to include more of the > > community in deciding OOo's shape and roadmap. Equally, we also > > recognize the need of structure for any such inclusion. Because > > discussions on OOo affect StarOffice, and vice versa, we must approach > > the issue of including community input very early on carefully. NDAs > > may very well be needed for discussions that involve StarOffice > > marketing. StarOffice is of course a proprietary application and its > > roadmap and future is a thing of competitive interest. > > > > Meanwhile, OOo's efforts to systematize community interest in > > enhancements (RFEs) has stalled, as many are probably aware, though we > > are trying to get things going again. We made some attempts in this > > regard late last year but lack of interest and meaningful progress (and > > the holidays) arrested that development. > > > About RFE's process, I completly agree with Christian's point of view. > The way they are currently handled is a non sense and doesn't give you > any desire to participate to the triage. > > > > > So, a couple of proposals. > > 1. First, that we re-initiate the discussion of handling community input > > for 3.0. It's too early to set a date for when we should do this by, > > but it makes sense to start thinking of it. > > (Why is it too early? > > > Because there is no good sense even of what 3.0 will look like.) > > > This is not too early because with the 2.0, we are benifiting or will > benefit from a lot of feedback from users having needs that will not be > covered by 2.0 are no longer covered by it, so if the demand is strong > there might be considered for 3.0 or even sooner (my thoughts go to the > graphics module or some Calc functionalities). > > I'm sorry to insist but we also have a large users base that can benefit > to Sun. For information, I have put a wiki in place that will be > advertized for m100 to track those feedbacks more easily for external > users (not those already in the community and subscribed to the lists). > http://ooo.lab-project.net/wiki/tiki-index.php?page=Commentaires2.0 > > For > > > background, Sun has not previously included community input so early. > > Last year's Q-Concept document was issued after most major decisions had > > been made. It was a step in the right direction; this process is a much > > greater step. This proposal, of course, spans the breadth of the > > project, and is not specific to the NLC and the overall logic should be > > articulated by the ESC and CC. But we can start thinking about it in > > [EMAIL PROTECTED] > > > > 2. Second, and this proposal can work within #1 above, we discussed a > > model where representatives of the NLC leads might meet directly with > > StarOffice marketing and product management leads. The idea is to > > represent to SO product management the desires of the NLC users. As > > mentioned above, representative leads may have to sign NDAs with Sun, as > > they would be discussing proprietary information with the company. > > > > The second point is at best a half-way solution. I would prefer #1, of > > course, as it conforms with OSS ideals. But let's be pragmatic. What > > is needed now is for the application in development address the needs of > > major users, and the most major users are, i believe, represented by the > > NLC communities. What #2 provides is a way for the many users > > represented by the NLC to have their voices heard. It's not as > > democratic as #1 above, however, and should not be seen as a complete > > solution; it is a temporary compromise. But I think we should consider > > it. > > > imho both are needed to have a clear, understandable and sharing view of > what's going on for OOo. And this can solve some lack of answers that > put us in a very unconfortable position as project leads. > > > > > What to do now? > > I'd like for the NLC leads to consider this proposal. For number 1, > > we--the entire project but especially the proddev team--needs to devise > > protocols for managing RFEs, etc., and can discuss those in > > [EMAIL PROTECTED] But, please, read the archives, first. [2] > > > But who is the proddev team ? Erwin, Bettina ? who is involved in the > process once we have add the key 'eval_ok' and 'requirements' ? Could we > have a clear and real representation of the process ? Louis, I'm sure > that some of the 3.0 features are already planed (there is some specs), > and I can understand that Sun would keep some of them secret, but we > have no time to waste if we don't find a way to include the community > feedback in this planing. Proddev for me currently is not the way even > if we were hundreds to work on it. > So my proposal : > - decisions writen in Christian's previous mail (copy/paste for memo) : > -------< begin of copy >--------------- > Sun needs to decide early what features it wants/considers and which one > are unlikely to be implemented by Sun-developers. > > So the decisions are: > > * "We'll put it on our pile, we'll try to implement it" > * "We would very much like to implement it, but probably we'll run out > of time" > * "We'd love to see this feature, but we'll not be able to do it - has > to be done by external developers" > * "We reject this one. Even when a patch existed we would not like to > see this implemented." > --------< end of copy >----------------- > > - a real work on specs coming from NLC (the work :) and shared with > developers, and we have to set a workflow so that each community doesn't > come with a request/analysis already gave by another one. > > - a communication between Sun and NLC, under NDA if needed, when we ask > for features or propose resources (the developer of the feature :) that > could have commercial impact for Sun. > As you see this is a mix of your two points :) > > Kind regards > Sophie > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
