Hi,
Christian Lohmaier wrote:
On Fri, May 20, 2005 at 04:10:32PM +0200, Joerg Barfurth wrote:
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.
What I meant to say is that for higher-level design step 2) is not
strictly after step 1), because you need to have an understanding about
the amount of work and the technical risk to decide whether to proceed
with a feature and for that you often need an initial design.
Design considerations that occur as part of the RFE work (what RFE's can
or need be combined to be our new feature?) are at that level.
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.
What exactly is lacking there? The most important source of information
about this kind of decision is the target milestone.
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..
If the missing information really is the technical risk and the required
resources and effort, then 'people' won't generally be able to provide
this. Conversely features often need to be scoped to the available
resources, so it is difficult to completely separate sorting through the
RFEs we have on a certain area and consolidating them into one feature
specification from planning/deciding where to put the resources.
OTOH I agree that there also are many cases where it would be
appropriate to ask the submitter (or any other available community
members) to prepare a spec for the desired feature even before a
decision is taken.
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)
In many cases there simply are no decisions yet - except that the
feature is not considered for the currently active release branches.
The 'comment' that shows that is, if target milestone 'OOo later' is
assigned.
* 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).
Yes. I really hope the announced/published spec drafts can be used more
for the next release(s). Of course ultimately the i-Team has to take
decisions and proceed with the work, but I'd expect them to listen to
feedback.
There should be a way to influence these design bugs more easily (not by
having such a big fight like for the quickstarter entries).
Changing completed implementations of approved specs after 'feature
freeze' deadlines have passed will always require some sort of a fight
(i.e. very convincing arguments) - and for good reason. That in some
cases even good arguments are not accepted as valid by someone else is a
fact about human nature. But it should not become the rule.
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...)
Not sure what system you mean. Generally I'd think exchanging mail with
the i-Team and/or the relevant dev@<project> list is the way to provide
feedback. It then depends on the i-Team members what they do with the
feedback. Systematically we can provide guidelines or recommendations
for dealing with feedback but ultimately the team takes the decisions.
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).
Public discussion of the overall direction is good thing too.
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".
Yes, I meant that RFE handling (grouping, combining, aligning RFE's) and
initial specification work already involves important (high-level)
design decisions. Correcting things after the initial fact, especially
changing the fundamental concepts, may be much harder.
Wrt. vetoing: yes, we probably need a defined process to appeal/escalate
arguments to project leads, CC or ESC.
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.
Between feature freeze for one release and the time when work on the
next version seriously starts, there isn't much to decide, except
whether a certain RFE is so exceptionally important that it warrants a
freeze exception.
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.
But that is great. This way, when the time comes to seriously get into
the preparation for the next release, we have usable issues to base the
work on. That is about all that could be done in advance.
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).
Neither do I. But that really is a problem of the long release cycle,
not of the RFE process. If even the start of the next release cycle is
months away, then there is not much point in taking decisions for
decisions' sake. They will likely be obsolete when the real work
commences. Most decisions are taken in the early phases of a release
cycle. I also hope we can find a way to get quicker release cycles to
work - that should solve the timeframe problem.
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".
Apparently the author of the spec does not feel you overturned his
interpretation of the MS-guideline. Such disagreement may happen.
This is something where I feel the community is not taken seriously.
Even if the author took you seriously and considered your opinion, he
may still consider his original opinion to be correct. I don't think
community opinions are disregarded systematically, but it can happen
with individual people or individual issues.
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"
True. AFAICT this happened in a time-constrained frenzy close to feature
freeze, where nobody took the time to step back and notice that the
resulting, cut-down specification had this serious flaw, that it traded
an existing feature for essentially no benefit.
Acknowledging this - after it was implemented - does not change anything
though, if the responsible developer can't correct this shortly before
release due to resource constraints or high risk. An improved
specification process should reduce the risk of this happening, but I
don't think it can be completely avoided.
Another issue is the new mail-merge. Not the new mail-merge itself, but
the removal of the "classic" way.
I don't know anything relevant about this issue. But probably this is
another item that could have been addressed much easier before the
change was implemented - if anybody would have thought of that in that
phase.
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.
As I have said before, it is a worthwhile goal to improve this for the
next version. But things happened to late for the 2.0 feature cycle.
- 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.
Disclaimer: I don't know the details or background of any of these issues.
Such changes need not only a patch, but a specification - or an update
to the existing specification. Features and UI changes are a case where
it is important to get agreement - e.g. with the responsible project
lead - what to do and how to do it before you code. And they have to be
provided in time. Feature and UI freeze dates are there for a reason.
Sun developers have to cope with this as well. Additionally any such
patches of course need to be screened for quality.
I agree that simply ignoring patches is not acceptable. OTOH I suspect
that in some cases this is the result of issue handling errors. An
unconfirmed defect issue not assigned to a (relevant) developer may
simply go unnoticed.
- 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...
True. But there is a certain timeslot when most of these decisions are
bundled. And the perceived problem in large part stems from the long
release cycle, which results in long times without such decisions.
Ciao, Joerg
--
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]
