On 3/17/13 10:13 PM, Hagar Delest wrote: > Any attempt to reset the votes would mean that once more, high scores > are just ignored. > Of course, nobody would browse the whole list of existing bugs, even to > recast their own votes. So reseting the votes would only lead to forget > about old bugs or old RFE. > Have office suites really evolved so that most wanted features several > years ago are now not relevant at all? If so, why not take the top 20 > and have a vote on the dev list for each of them and keep them or close > them for the rationale that could emerge from the discussion? > > My feeling is that you're trying to change the AOO agenda about RFE. > Just ditch current history to rewrite your own history with OpenOffice. > Same with your other message in my other mail in this topic. Of course > old reports got more votes. If they had been closed earlier, the list of > active reports would be different. And since RFE cannot implemented > shortly, you'll always have this time bias. > > Anyway, I don't want to engage further in this discussion. I've given my > opinion, if the developers agree with your proposal then so be it. But > if the votes are reset, I'll take it as a huge setback for the users > decisions and won't hesitate to point to this topic in the forum to > explain why I've lost the least interest in BZ. I would not see the > point filing reports if in the future someone can delete the votes for > whatever reason. > If you want to go even further, why not just delete all the content of > BZ and start from scratch?
This would be a very interesting approach that of course is indeed not completely new. If we wouldn't have useful patches in BZ I personally would of course support such an approach. Having a clean and fresh BZ would be an opportunity to focus the real problems we have and find a good balance between feature development and bugfixing. But of course it's not really realistic :-( The main problem with votes at the moment is that we don't have a common understanding how to handle issue with votes. I would say at the moment these votes are useless. We had focused on issue with high votes in the past because it was the goal for developers at this time, managers pushed it but later on the priorities changed again and nobody really took care of these issues. If we want to make use of this BZ feature we should first think what we want to do with this issues and can we do it. Means we can't force developers to work on such high voted issues, we can only motivate to focus on these issues first. Or if some sponsors are interested to pay developers to work on such issues that could also work, I don't know. In general I think we should continue the discussion about our long term goals for the project and the product first. We can't do everything and it is important that we at least have all some common understanding about our strategy. We can start with thinking what office productivity suite really means and if we already fulfill these requirements... Juergen > > Hagar > > > Le 17/03/2013 15:32, Rob Weir a écrit : > >> On Sat, Mar 16, 2013 at 6:55 PM, Hagar Delest >> <hagar.del...@laposte.net> wrote: >>> Le 14/03/2013 15:10, Rob Weir a écrit : >>> >>>> But if only a small minority of users know about voting, and we have a >>>> large collection of ancient votes, then the votes are less meaningful >>>> and relevant. That's my main concern. I don't believe that the vote >>>> counts necessarily reflect current reality. Look at the requests we >>>> received when we did the Google Moderator feedback requests. To me >>>> that is more meaningful, since it is more current. >>> >>> >>> Argh, no! >>> The Google moderator was a total mess. At least the BZ is very >>> detailed, not >>> that difficult to use, you can subscribe and have a discussion about the >>> problem. >> >> Google Moderator was far easier to use for users than BZ is. That is >> why we received far more feedback with Moderator. I'm sorry that the >> troglodytes don't like that. >> >>> Voting in BZ is not more difficult than on Google Moderator. >>> Why should ancient votes be less valid? They are still the expression >>> of a >>> large install base. >>> >> >> They are less valid because they are ancient and do not necessarily >> reflect what today's users want. >> >>> >>> >>>> One way to improve this might be to remind users about voting via a >>>> blog post. If we have more users involved in voting it becomes more >>>> meaningful. Maybe even wipe out old votes, so we are looking at >>>> actual current user wants. Then make votes more visible by creating >>>> periodic reports on issues with the most votes. And when we fix an >>>> issue that had a lot of votes, maybe we blog about that. >>> >>> >>> What nonsense! So because ASF took hold of the code they should >>> restart from >>> scratch and annihilate all the previous feedback? >> >> Yes. That is an accurate statement of my belief here. Feedback from >> 2002 issues, no matter how many ancient votes were attached, is >> meaningless in 2013. >> >> Note: if you are correct, that these votes are still relevant, then >> new votes would quickly yield the same distribution and the same >> issues would quickly end up with the same prioritization. And if I am >> correct we would get a different distribution. But you must admit >> that if we did reset that votes and a different distributed emerged, >> then the new distribution would be the more accurate and more relevant >> one. So I don't see what you are afraid of. Why not get the most >> accurate feedback possible? >> >>> If we can't handle an issue, then let's tell it in the report itself >>> what is >>> lacking (manpower / expertise / ...). >>> What would be the advantage of a blog post? No attachment allowed I >>> guess, >>> so it would be a loss of interactivity with the users. >>> >> >> Read what I wrote. I suggested that we "remind users about voting >> via a blog post." I never said anything about collecting feedback via >> blog post comments. The idea would be to have a blog post that >> explains how voting works and inviting users to vote in BZ. In other >> words, making it so votes are not only filtered through forum >> volunteers and their recommendations. Open it up. >> >>> In the forums, we have always encouraged users to file reports and >>> vote for >>> the issues so that they get attention from the developers. It has always >>> been said that the only interface between devs and users should be >>> the BZ. >>> And even if it's not very user-friendly at first, I agree that this >>> is the >>> best way: it makes the reporters state clearly what they want and >>> this is >>> not that easy enough to filter the requests. Users who really wants >>> to make >>> their problem known do bother filing a report, the others don't and >>> it means >>> that it is not a really important idea. >>> How would a blog be analyzed by the devs exactly? >>> >> >> You misunderstand. We should still use BZ to collect feedback on BZ >> issues. My suggestions were aimed at making this feedback more >> relevant, so it is not just project insiders voting, but getting a >> greater representation of what users want. We have had over 40 >> million downloads. How many of these users having voted? How many >> even know they can vote. You asked why the votes are ignored. I'm >> suggesting that if the feedback is ancient and unrepresentative, that >> could be one reason. >> >>> Sometimes users wonder why bugs scoring many votes don't get any >>> attention. >>> Any attempt to cancel the votes or change the way users chose their >>> priorities would be detrimental to the project credibility. I would >>> personally be very annoyed by such a behavior and would stop filing >>> reports, >>> voting for bugs and I would also stop advising the use of BZ at all. >>> >> >> I'm telling you why I think the ancient votes are ignored. That's my >> belief. You're welcome to believe whatever you want. But I think we >> agree that the votes are ignored today. >> >>> If you consider the weeds as the myriad of reports with few votes, >>> then we >>> have some rocks to concentrate on (the top rated by votes). Once the >>> latter >>> are removed, then let's talk about how to handle the garden. >>> >>> Hagar >>> >>> >>> --------------------------------------------------------------------- >>> 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
