Hi Louis,

On Tue, May 03, 2005 at 11:55:31PM -0700, Louis Suarez-Potts wrote:
> [...] 
> 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.

I disagree, the RFE-process did not stall - it never begun.

> We made some attempts in this
> regard late last year but lack of interest and meaningful progress (and
> the holidays) arrested that development.

RFE's have been evaluated by volunteers, but Sun's decision-taking
process just is not ready for this. Although not many people were
working on evaluating the RFEs according to the new proposal, there are
already 476 evaluated issues that haven't been touched since then.

Basically the new process did not help at all yet. RFEs still are put on
hold for years until a new set of RFE's will get picked by Sun's project
marketing.

That's why people loose interest in evaluating. There is no progress.
(See also my post on [EMAIL PROTECTED] that you cited recently). [1]
 
> So, a couple of proposals.  
> 
> 1. First, that we re-initiate the discussion of handling community input
> for 3.0. 

Don't talk about the community, talk about how Sun will evaluate the
RFEs. There alredy is enough input (issues).
Currently the whole process is directed towards Sun - virtually every
RFE issue waits for a "OK" by Sun-product-marketing.

But Sun only gives this OK when planning for the new version begins. And
between these phases there is a 2-year period when the RFEs are lying
around without any action at all.

The situation is worse with RFEs that have patches (although there has
been a slight improvement). These are put in the queue as well.

> 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.) 

No. It is not too early.

Many RFEs are just unrealistic, don't carry any benefit for anybody
except the reporter. Instead of passing these to "bh" or now
requirements, these issues should get closed as wontfix immediately.

> 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]

This process (publishing the "Plan") doesn't solve the problem with
issue handling at all.

> 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.

Much simpler would be: Ask the NLC-Leads/the whole community for
feedback on the specs before they are made final. This would help a lot
in preventing some of the big mistakes done with OOo 2.0
But again: This doesn't solve the issue-problem.

> [...] 
> 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]

The whole process of evaluating the RFEs is senseless when there is no
decision on whether to implement the feature or not.

We have 2900 RFEs laying around. Some of them from the very beginning of
OOo. 

There was no process regarding taking decisions at all.

RFEs still are thrown into the black hole and nobody can expect a
decision in a reasonable amount of time.

If new features are added, then not on behalf of existing issues, but
because of decisions taken elsewhere. Issues are fixed "by accident" if
you want.

What I expect/hope:

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."

I'll throw in my last year's proposal again:
"Proposal of a review-system to accelerate handling of easy to fix RFEs"
http://qa.openoffice.org/servlets/ReadMsg?list=dev&msgId=1058032
http://marketing.openoffice.org/servlets/ReadMsg?list=proddev&msgNo=79

[1]
http://marketing.openoffice.org/servlets/ReadMsg?list=proddev&msgNo=84

ciao
Christian
-- 
NP: Blind Guardian - The Script For My Requiem

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to