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

Reply via email to