On Mon, Mar 18, 2013 at 7:03 AM, Jörg Schmidt <joe...@j-m-schmidt.de> wrote: > >> -----Original Message----- >> From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] >> Sent: Monday, March 18, 2013 11:41 AM >> To: dev@openoffice.apache.org >> Subject: Re: A question about existing practices >> >> Hi, >> >> sorry, for top-posting, but I have a general remark. >> >> From my point of view the discussion on this thread went >> into the wrong >> direction. >> I think Jörg just mentioned issue 3959 as an _example_ for >> feedback from >> users regarding feature requests via Bugzilla votes. I also >> think that >> Jörg mentioned Bugzilla votes also only as an _example_ for >> such kind of >> user feedback. > > Exactly. > > What is important for me to say that when we make promise users (directly or > indirectly) so we have to deliver. > > A vote button is an indirect promise (because why the user should vote, > except that it has the relevance).
A promise to do what? I think the existing practice is rather unambiguous. If we have 10 year old issues with high vote counts, that means that the project never treated votes as a promise to implement the requests. > Likewise, it is a promise that we BZ ever offer, because if we ask users to > tell us problems, we are also obliged to take care of their communications. > (not legally, but morally) > If a use has a problem with an existing feature, where it is not working as it was designed to work, or intended to work, then yes, we should help the user. If there is a bug, then we should fix the bug. Of course, with many defect reports we'll naturally focus on the most severe ones. And in practice this means that there may be some trivial bugs that never get fixed. But a feature request? I see zero obligation, legal, moral, social, or otherwise, for us to do anything other than say, "Thank you for the suggestion". > It is not the problem of the user in evaluating old Votes Votes unlike new, > because we have no contract with the user, but it's about credibility, our > credibility. > We need to set the right expectations. If we set expectations that we are all supermen and can write C++ code in our sleep, and our cats can write Java code while playing with balls of yarn, then yes we will lose credibility. But a different kind of credibility is the kind that attracts developers, which is saying that developers on the project work on the features that are important to them, and the direction of the project is determined by the collective priorities of those who are doing the actual work. That kind of credibility is a very important kind, since that is what helps us recruit developers. Of course, if we don't make a product that users want, then we become irrelevant. But a look at our popularity via download numbers shows that we are highly relevant, even though some 10-year old feature ideas are ignored. In any case, "volunteers" and "obligations" do not match. If we really want to lose volunteers then we should tell them that they have the obligation to follow the priorities of 10 year old votes. -Rob > > 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
