Hi *, On Thu, Jun 02, 2005 at 05:39:37PM +0200, Joerg Barfurth wrote: > Christian Lohmaier wrote: > >On Wed, Jun 01, 2005 at 04:39:34PM +0200, Joerg Barfurth wrote: > >>Christian Lohmaier wrote: > [...] > > >>>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. > > That shouldn't be the case. Before assigning any target milestone an > initial round of triaging should have taken place. Thus issues that are > incomprehensible, unacceptable or known to be duplicate should be closed > as INVALID, WONTFIX, WORKSFORME or DUPLICATE without ever getting a > target milestone.
I was only talking about issues in status "New" > >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. > > To me target milestone "OOo later" signifies that the issue is basically > accepted as "should/could be implemented", but that noone has comitted > to working on it for one of the active releases. This is true for defects, but not for RFEs (at least not in practice). > If this does not correspond to current TM assignments, then > - Either this accumulated historic cruft or Yes, some of the targets were not available all the time. > - Our target milstone definitions are not clear enough or > - Our target milestone usage has not been communicated well enough I cannot tell what the reasons is, I can only tell that I cannot determine any difference between these target milestones when it comes to RFEs. > The use of "not determined" is certainly underspecified. I can think of > at least two vastly different meanings. True. I for myself used that milestone for issues that I evaluated according to the new process, hoping that the evaluated issues would get handled sometime soon and get a real target (or rejected) But some clarification would be welcomed. > [...] > >>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. > > Right. And my answer is: to get faster decisions, we need shorter > release cycles. No objections from my part.. > [...] > >>>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...) > > >http://qa.openoffice.org/servlets/ReadMsg?list=dev&msgId=1058032 > >http://marketing.openoffice.org/servlets/ReadMsg?list=proddev&msgNo=79 > > That might make sense. But apparently the proposal did not reach the > right people (yet). Given the fact that I came up with this a couple of times and mailing lists (including the dedicated proddev-ML) I doubt it wil reach the "right" people ever. > >>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. > > Still the ones who do the work are free to do with the feedback what > they want. Sure. The only idea behind all this is to get a *timely* response. Again: All about decisions, not about the implementation or the implementation timeframe. > So we are back at the need of an appeal process to an > authority that is entitled to overturn decisions by individual developers. That is handled by "vetoing". > >>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. > > For vetoing you need someone or some group that has been given the > authority for such decisions. This could be ESC, CC or project lead(s). > I don't think a 'veto' by a loosely defined band of reviewers would be > considered authoritative by a developer. You missed the "super-reviewer" part of my proposal... > >>>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. > > No the triaging and cleanup process can go a long way to ensure that > there is good material when the next planning session starts. So when > the time comes everyone can work on the real meaty stuff instead of > having to sift through the accumulated junk. OK, it is not completely usesless, but bad RFEs should not have been reassigned to requirements/bh in the first place.. This "plan once for the whole release" is a big problem. It would be much easier, transparent, satisfying if this would be a more continuous thing with only the big changes planned beforehand (e.g. rewrite chart-module, get rid of table-row limit, change table-handling in writer, change toolbar concept,..) and leave room for decisions during the implementation of the big issues, depending on how fast (or slow) they proceed. A shorter release-cycle has similar effects, so I'm all in favor of shorter release-cycles (more minor releases, not only major (does take looong) and micro (only bugfixes)) > [...] > >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. > > Apparently everyone involved is simply too busy with work on the current > development version that new incoming RFEs are dealt with with minimal > effort. IOW noone feels they can invest the time to make even that decision. I think they (those reassigning the issues) just don't feel responsible or must not (are not allowed to) feel responsible for taking a decision... > >>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. > > They still require a serious look at the issues. I don't doubt that - but it is all about feedback to the reporter... (see below in my previous post) This is only meant as a quick evaluation. Why does a long release cycle imply ######---------------------------------------######------ ~~~~~~+++++++++++++++++++++++++++++++++++++++~~~~~~++++++ ### planning phase, RFEs are evaluated +++ implementation phase, ~ maintenance/bugfixing, - no progress on RFEs at all. Why can't it just be ######---##---#--#---##--#---#--#----##-----#-######--#--- ~~~~~~++++++++++++++++++++++++++++++++++++++++~~~~~~++++++ > [...] > >Another decision that can be taken easily almost everytime is > >"needs a complete rewrite" vs "just like fixing a typo" > > This one is an engineering judgement, not something a user experience > guy can necessarily judge. Not for every issue, that's true, but there are many, many issues that only affect the UI, some request a different wording or similar. Even this kind of issue is only part of the pile (=sits there forever) although you'd only have to replace the word "foo" by "bar". Same is true for the opposite. Implementing new chart types surely is more work than changing a string or resizing/reordering a dialog. > >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. Having such a preselection makes finalizing the issues more easier (=makeing it ready for implementation, assign ressources/set a target) > >As an user, I would appreciate an answer "We won't implement it" far > >more than waiting forever without knowing what the status is. > > I agree. I also agree that any state/target/owner change should be > accompanied by a comment that really indicates what is happening and > why. But we probbaly need to get agreement and commitment on this by the > people doing that work. I'd be happy if there were status changes at all. Most of the time the only action is reassigning. And to me it seems that everyting that is RFE or Feature is automatically reassigned, without having a look (apart from checking whether it applies to the selected component)... Any further handling, additional comments or looking for duplicates and then closing the issue unfortuanately is the exception. > >>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": > > Yes. But the latter question needs to be reevaluated basically after > each release, looking at where we have come meanwhile. I guess that is > the reason why the people doing it prefer to do both parts together at > the same time. Why would you appreciate a feature in one release and reject it for another? There surely are cases where other items obsolete or block another one, but these are only a few. The vast majority of issues should not have this effect. Doing it all at once only leads to wrong estimations, leading to features that have to be retargeted (these retargeted issues don't differ largely from the "features we want in our product, but not scheduled for this release" kind of issues) > [...] > I agree that it should be explained. In that [quickstarter] case, wasn't > the interpretation of the original author cited in the original spec? [Disclaimer: The following is only an explanation on why this issue was and is of such a big importance for me. In no way are the following comments meant to start a discussion about this very specific topic] Only the result of the interpretation, but not why he thinks that this interpretation is correct. I would not have expected this in the initial spec anyway - why would you explain your interpretation when you give a reference and when you're convinced that you're right?). But after citing the reference in context, demonstrating how one comes to the other, far, far more obvious (and IMHO the only correct way to interpret the MS-guideline) I would have expected either: * A correction of the spec ("my first interpretation was proven to be wrong/I misinterpreted the guideline") or * an explanation why he thinks his interpretation is correct ("although users interpret the guidelines differently, I'm still convinced that my interpretation is the right one because [explanation]") It is not clear whether the owner of the spec read another guideline with different wording, etc. but surely not "'even it it does not conform to the Windows guideline' we follow the will of the community" While this statement would perfectly be acceptable when the change would have been made promptly, after the issue was filed, voted on, compared with the feedback on the mailing lists (everybody, me included, thought that the ms-guideline did really say so as mentioned in the spec), it is not after the lengthy fight for the change (in which the interpretation was proven to be wrong and without any explanations from "the other side"). So this really made me angry. Just like the allmighty master of the spec shows his endless genorosity by throwing a piece of bread at the starving people. [Disclaimer: now this is subject to discussion again :-)] What really bothers me is the following: When you cannot change a small (implementation wise) point of a spec with clear arguments, how could you influence spec only by request, user-feedback, votes alone? > >>>This is something where I feel the community is not taken seriously. > > BTW. I can imagine that people who get swamped with loads of > inappropriate "me too" and "why don't you finally solve my pet issue" > issuezilla notifications can easily overlook the occasional more > well-reasoned IZ comment. The related issue: http://www.openoffice.org/issues/show_bug.cgi?id=30853 There are not that many me-too comments. The first one: Why do you follow MS even when it doesn't make sense? - most people did only read the OOo spec and did not have a look at the MS guidelines. It was peschtra who cited the MS-guideline and opened our eyes.. There are NO answers from dev-people. Before peschtra cited the spec, there were two comments "works as specified". Then the relieving comment from mba: "After some investigations it was decided to follow the community here: here we go..." At this time I was happy and thought "finally..." - until I had a look at the revised spec. > >>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. > > What I am trying to convey: most developers (including user experience > people) are so busy with the current release, that new stuff gets only a > quick check whether it must be considered for the current release. If > the decision is 'no' (=> target milestone "OOo Later") they will not > look at it again until work on the current release is finished. Even this kind of evaluation is only done for defects, not for RFEs. Every RFE is OOo later automatically. > [...] > >>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) > > If an issue is from an unfamiliar community member, I generally (have > to) assume that the submitter won't be able to do that themselves. Nobody is saying that the reporter should supply one. If this really is a problem, then a page "So you were asked for a spec..." could be created. > Of > course for patches that assumption is probably not warranted. But > feature issues get sent to the requirements people who can't themselves > judge the quality of a patch. But by the patch they can judge/estimate the impact and effort. > As a result it may be underestimated what the community members behind > an issue could do themselves. > > Maybe this could be addressed with a better process, that tells patch > submitter what they should or need do to get their patches in (creating > specs, assigning issues to right owners, asking the right people, ...) > > But it is probably true that many of the StarOffice developers are not > really prepared for accepting or even encouraging community > contributions. First contributions often need a lot of hand-holding to > get them into a shape that they can be accepted. >From my POV this hand-holding works sufficiently well for contributions for defects, but not for RFEs. Developers don't see RFEs -it seems- unless told by UE ("have a look"). ciao Christian -- NP: Manowar - Wheels Of Fire --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
