Top post. There is no consensus here to eliminate or reset the votes. Some who are more in touch with users have stated that it would be harmful. I trust their judgement.
Issues that are recent that get votes should be discernible by developers looking at BZ. Any issue with a lot of votes might be interesting for a new developer. Reveal codes could become reveal ODF someone with a C++ programming dog and a java programming cat might do it someday. Sent from my iPhone On Mar 18, 2013, at 10:08 AM, Jürgen Schmidt <jogischm...@gmail.com> wrote: > On 3/18/13 5:34 PM, Rob Weir wrote: >> On Mon, Mar 18, 2013 at 11:32 AM, RGB ES <rgb.m...@gmail.com> wrote: >>> 2013/3/18 Rob Weir <robw...@apache.org> >>> >>>> On Mon, Mar 18, 2013 at 10:11 AM, RGB ES <rgb.m...@gmail.com> wrote: >>>>> 2013/3/18 Jörg Schmidt <joe...@j-m-schmidt.de> >>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rob Weir [mailto:robw...@apache.org] >>>>>> >>>>>>> I'd say, "Thanks for the suggestion. We take all suggestions >>>>>>> seriously, and user suggestions are often the source of ideas that >>>>>>> make it into the product. Thank you for using AOO." >>>>>> >>>>>> Sounds fine for me. >>>>>> >>>>>>> The title of the tread is "A question about existing practices". I >>>>>>> think the facts are quite clear. If we have many 10 year old >>>>>>> untouched BZ issues then fixing these issues is not part of our >>>>>>> existing practice, whether you define that as mandatory, voluntary or >>>>>>> whatever. >>>>>> >>>>>> No problem. >>>>>> >>>>>>> "Practice" is what we do, not what we talk about doing. >>>>>> >>>>>> Yes, but what we must be as clearly defined this user can foresee it. >>>>>> >>>>>> Why? >>>>>> If I as a user know any bug in the program, it may be important for me >>>> to >>>>>> know _approximately_ when this will be fixed. >>>>>> >>>>>>> you want to argue that we talk a lot about fixing old issues, and say >>>>>>> many solemn things about how important they are, then I would agree >>>>>>> with you 100%. But we don't actually do anything about them. >>>>>> >>>>>> I do not know how to define something should, but I know that you have >>>> to >>>>>> make it transparent. >>>>>> >>>>>> For example, a road map for developing the program is important because >>>> it >>>>>> clarifies what new features AOO will have in the future. That's right, >>>>>> that's a good thing. >>>>>> >>>>>> But it is also important to clarify how to deal with bugs and feature >>>>>> wishes of users. >>>>>> There was the suggestion to delete all old votes, only we must still >>>>>> clarify how we handle new votes. I think. >>>>>> >>>>> >>>>> +1. >>>>> >>>>> There is an old joke: "I'm only responsible for what I say not for what >>>> you >>>>> understand", but the fact is that being AOO an end user application what >>>>> our users understand IS important for us. And what will people understand >>>>> if they know all those votes are being deleted? IMO, users will take this >>>>> as "they do not care about our votes, why should I vote again? Why >>>> should I >>>>> fill a bug report that nobody reads?" and that's a really bad thing. >>>>> >>>> >>>> They'll believe what we tell them. If we say that we're "resetting" >>>> the vote counts in order to determine what is most relevant to users >>>> today, starting with an unbiased and fresh view of today's users >>>> priorities, and not to over-advantage the dead hand of decade-old >>>> votes from users who may or may not even still be using OpenOffice >>>> today, then this will be seen as a good thing. >>>> >>>>> If you want to know how relevant old issues are, once we have a working >>>>> survey system we can start a series of surveys about most wanted features >>>>> requests. IMO, the only valid way to delete votes, the only way that show >>>>> respect to our users is to close the corresponding issues. >>>>> >>>> >>>> The fact that there are decade old issues demonstrates that they are >>>> not relevant at all. >>> >>> >>> The fact that there are decade old issues only demonstrate they are still >>> unresolved: nothing more, nothing less. Are you saying the request to >>> provide support for opentype features is obsolete only because nobody >>> solved it since the issue was filled on 2003, and that we need to trash the >>> more than 200 votes for it? Sorry, but that makes no sense... >> >> >> Yes, that is exactly what I am saying. If you want to argue the >> contrary you would need to explain what the relevance is of issues >> that are 10-years old and have not been touched and probably never >> will be. I might as well keep in a box my letters to Santa Claus from >> when I was a child, in hopes that they may be someday delivered. If >> something has not been touched for 10 years this is an extremely >> strong indication that it is irrelevant. Things that are important >> tend to be done. Things that are not important do not get done. I >> know of no other measure for determining this. > > I don't think that it help us forward if we nitpicking further about > different understanding if something is still relevant or obsolete. > > The point is that Rob is correct to assume that if a 10 year old > issue/RFE is not yet addressed it will be likely not addressed in the > next 10 years if not a huge bunch of developers fall down of heaven. > > The question is if we want to use the voting feature in the future if it > is useful to reset the current votes or at least review the current > issues with high votes and mark them as invalid/won't fix or whatever to > get a clean start point. > > In general I would like to make use of the voting feature but with the > current state I am not sure if it make sense. Many issues that probably > nobody will fix in the near future. > > For example issues with 2 votes of the same person are completely > irrelevant to me. The fall in the category of hey my issue is the most > important one, why don't you fix it. What is more important than my > issue ... > > > Juergen > > >> >> -Rob >> >> >>> >>> The lack of a split view is also a very old issue that's still relevant, as >>> well as the "reveal codes" mentioned by Dennis (even if I do not need it, >>> many people want it and every now and then someone ask for that on the >>> forums). Styles for tables? And for Math objects?... may I continue? >>> >>> The point is that all the above mentioned request are really difficult >>> tasks, and that alone justify the fact they are still unresolved. Even if >>> there are requests that are not valid any more, and it's quite possible >>> that there are lots of such requests, dropping a nuke to kill user's >>> feedback on every single old issue is not a good thing to do, IMO. >>> >>> Just my last 2¢ from today (taking a break from this thread) >>> >>> Regards >>> Ricardo >>> >>> >>> >>>> I can't think of any test of irrelevancy more >>>> accurate than pointing out that they have been ignored for over 10 >>>> years. >>>> >>>> My suggestion was merely a way of getting feedback that might be more >>>> relevant. But that's fine. If we're more comfortable claiming that >>>> decade-old untouched issues are sacred to the project, then that's OK. >>>> They can just as easily be ignored for another decade. We have >>>> better means, like Google Moderator, or surveys, for finding out what >>>> users actually think today. >>>> >>>> -Rob >>>> >>>>> Just my 2¢ >>>>> >>>>> Regards >>>>> Ricardo >>>>> >>>>> >>>>>> >>>>>> >>>>>> Greetings, >>>>>> Jörg >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
