Hi J�rg, *,
On Wed, Jun 01, 2005 at 04:39:34PM +0200, Joerg Barfurth wrote:
> 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.
You can ask the community to come up with an initial design..
Surely the community cannot evaluate the technical risk, but I'm sure
the community can create a design spec that is usable and comprehensive.
> > [...]
> >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.
This kind of information is useless since almost all RFEs have the TM
"OOo later" or "---" which can be excachanged by each other without any
loss of information.
Features/Enhancements with status New:
"---": 1654
"OOoLater": 1104
Between these two targets, ther is basically no difference at all. The
same goes for "not determined". It depends on the one who reassignes the
issue on what target the issue will have.
The problem is:
An RFE gets filed.
-> it gets reassigned..
-> then <nothing happens for a long, long time>
-> then either
A) somebody stubles across the issue and realizes that it has fixed in
the meantime/does no longer appy and the closes it - or
B) it continues lying around
The only actions on RFEs are regular users adding their comments (mostly
complaints "This is so serious, how dare you to ignore this one")
> [...]
> >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.
Yes! And that is exaclty the problems: No decisions.
> The 'comment' that shows that is, if target milestone 'OOo later' is
> assigned.
I'm not sure whether I understand that one properly. Are you saying: TM
OOoLater means: not considered for active release branches"?
Then I respond: Everything without a TM OOo 2.* is not considered.
That by itself would not be a problem. The problem is that these not
considered issues reach back to the very beginnings of OOo. - That the
timeframe between reporting the issue and getting considered is huge.
> [...]
> >>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.
http://qa.openoffice.org/servlets/ReadMsg?list=dev&msgId=1058032
http://marketing.openoffice.org/servlets/ReadMsg?list=proddev&msgNo=79
> 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.
You mentioned the problem that votes on issuezilla and of feedback by
individuals would not be representative of the user-base. A set of
"reviewers" (e.g. representatives of the native-lang-project) would
certify with their approval that the issue is important - not only for a
handful of noisy individuals, but for many,many people.
> >>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.
> [...]
> Wrt. vetoing: yes, we probably need a defined process to appeal/escalate
> arguments to project leads, CC or ESC.
here the review system again. The initial idea was that it should
accelerate getting a decision on lousy to fix RFEs, bypassing the
product-planning phases. The reviewers should make sure that the issue
really qualifies for an accelerated decision (small impact, really lousy
to fix) - But the same system can be applied to vetoing.
> >[...]
> >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.
But this renders the RFE-process pretty useless.
> >
> >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.
No. I disagree. Many things can simply be rejected - even without big
planning.
But almost every issue that is flagged rfe/feature is reassigned, no
matter how irrationale it is.
> They will likely be obsolete when the real work
> commences.
Again I disagree. A decision like "Will never be part of OOo even when a
patch existed" or "Sounds interesting" should be possible at any time.
Same for a evaluation like "Only useful to a handful of people" and
"affects almost everybody". Just pass these "only for a handful"-issue
to the community (close them with OOoPleaseHelp target)
Another decision that can be taken easily almost everytime is
"needs a complete rewrite" vs "just like fixing a typo"
This doesn't need to be 100% correct everytime since it is only a quick
evaluation of the issue, but it will help to reduce the number of
unanswered issues.
As an user, I would appreciate an answer "We won't implement it" far
more than waiting forever without knowing what the status is.
> 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.
Again I disagree. For a release cylce the decision basically is "Hmm,
what features will we pick for implementation this time" and not "What
features do we want in our product":
To me these are two very distinct types of decisions that are
unfortunatly taken at the same time with the current process.
> >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.
Having different opinions is OK, not explaining them is not. The author
did not post his interpretation to the issue, did not try to explain why
he has a different interpretation/how he came to his interpretation.
> >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.
Sure. It was just meant to serve as a bad example.
> [...]
> >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.
It kind of was. I noticed that the database beamer did not contain the
mail-merge icons/that they were nonfunctional. This was fixed, the icons
where there - but then somewhere in the meantime the funkctionality of
the buttons was changed and nobody did notice until fr project filed an
issue. Unfortunatly the new Toolbar-design avoid solving this one by
just putting the old icon back (since this is not possible).
My initial issue:
"mo mail merge possible using database-beamer"
http://www.openoffice.org/issues/show_bug.cgi?id=36372
issue of fr-project:
"Ability to execute mailing from data view window without the wizard"
http://www.openoffice.org/issues/show_bug.cgi?id=48059
follow-up-issue:
"not possible to customize toolbar "Table Data" (for database beamer)"
http://www.openoffice.org/issues/show_bug.cgi?id=48146
> [...]
> 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.
And I have been trying to say: It is not about the release-cycles, not
about getting the features implemented.
> >[...]
> >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.
Nobody asked for such actions. And these things are old but still
unresolved (except the font in math's command-window)
> 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.
All the above mentioned patches were available before a specification
was written.
Now we have a Zoom-control in the toolbar, but it is not a listbox like
in the page-preview, but a launcher for the Zoom-dialog. Surely an
inferior solution, although the patch was available for years (feb
2003)
http://www.openoffice.org/issues/show_bug.cgi?id=11354 - it was closed
as duplicate of the PCD-issue
http://www.openoffice.org/issues/show_bug.cgi?id=20340 but apparently
this one was not the right one, so the patch got attached to issue
http://www.openoffice.org/issues/show_bug.cgi?id=30522 as well.
The Fixed-font in math's command window is a one-liner (code-wise). If
it needed a spec - one should have asked for it/pointed to the current
one.
http://www.openoffice.org/issues/show_bug.cgi?id=21351
It is a perfect example of the "black-hole" dilemma with RFEs. It was
reassigned to User experience and nothing happended for more than a
year.
I'm sure that when st would not have added a comment (and a handful of
dev-people to cc), it would still be in the queue with no additional
comment whatsoever.
Regarding the word-count: Adding a word-count for the current selection
to a spec shouldn't be to hard. Count words in the same way you
currently do for the whole document, but only consider the words in the
current selection. And adding a dialog to the menu so that the user can
query the result.
http://www.openoffice.org/issues/show_bug.cgi?id=1793
http://www.openoffice.org/issues/show_bug.cgi?id=17964
and many,many duplicates & issues for more wordcount features.
> [...]
ciao
Christian
--
NP: nichts
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
