Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Rob Weir <robweir <at> apache.org>
Subject: Re: A question about existing practices
Newsgroups: gmane.comp.apache.openoffice.devel
Date: Tuesday 19th March 2013 16:04:20 UTC (over 4 years ago)
On Tue, Mar 19, 2013 at 11:19 AM, RGB ES  wrote:
> 2013/3/19 Rob Weir 
>
>> On Mon, Mar 18, 2013 at 9:21 PM, Guenter Marxen
>>  wrote:
>> > Hi,
>> >
>> > Am 18.03.2013 19:05, schrieb Dave Fisher:
>> >
>> >> 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.
>> >
>> >
>> > as a longtime "OpenOffice"-user (since StarWriter 2.0), I think that
in
>> this
>> > case, Rob is wrong and resetting the votes would be something like an
>> > offense to us, the "old" users, who wrote and commented issues or
voted
>> for
>> > issues for many years.
>> >
>> > I mainly used Writer, writing long texts with many images and many
>> > references (f.e. an SO-/OOo-manual, widely spread in the german
speaking
>> > universities) and in times before the turbulences around OOo I made
bug
>> and
>> > enhancement issues and also voted for issues.
>> >
>> > Look f.e. at issue 5608
>> > (https://issues.apache.org/ooo/show_bug.cgi?id=5608).
>> >
>> > It was raised in 2002 and the latest comment is dated 2012. (I did not
>> find
>> > "my votes" and the number of votes in bugzilla, but I think, I voted
for
>> it
>> > in 2004.)
>> > Although the issue is ten years old and nobody worked on it, it
remains a
>> > very important enhancement issue for all, who are writing long texts
with
>> > (many) references. The issue is not at all outdated!
>> >
>>
>> I suppose it depends on how you define "important".  Since issue 5608
>> was entered, back in 2002, we've fixed 36054 issues in Bugzilla.
>> (31064 defects, 3839 enhancements and 1151 features). So that many
>> bugs were fixed, or enhancements/features implemented, while issue
>> #5608 was not.  I don't know how you define "important", but to me
>> something that is behind 36,054 other items is as close to unimportant
>> as I can imagine.
>>
>> Remember, what things a developer chooses to code on is also a vote.
>> They vote with their time.  I count that kind of vote very highly,
>> since it is backed up by actions.  Those 36054 issues were important
>> enough for someone to actually invest their time into fixing it.
>>
>> I don't mean to offend anyone by telling them that their issue is not
>> important.  We're all entitled to our personal preferences, and if you
>> say something is important to you then I will gladly accept that.  But
>> from a project perspective, I think it is clear that an issue that was
>> bypassed by 36054 other issues for over a decade, that an issue like
>> this is certainly not a likely candidate for a"high priority"
>> designation.  The "votes" from project members, via their actions, has
>> put 36054 other issues ahead of it.
>>
>
> Rob, I think you are missing the point here. I agree that the choice of a
> developer is a sort of "vote", and a really important one, but it is NOT
> the same vote we are discussing here: votes on issues are cast by users,
> not by developers. Votes are not a measure of feasibility but of hope:
> there is a HUGE difference between saying "we are sorry, we don't have
the
> resources to implement this right now" and "because nobody implemented
this
> before, your issue is not that important for the community so we are
> forgetting your votes". After all, those users that voted ARE an
important
> part of the community.
>
> I insist: "we cannot do that now" is not the same of "we will not do that
> simply because nobody did it before".
>

But this is not a case of "we don't have someone right now to work on
it". It is not a case of "not today, but maybe next week".  This is
not a case of "Sorry, we can't fit it in this release, but maybe we'll
do it in the next release."  What this is is a case where no one,
absolutely no one, zero, zip, nada, gar nichts, nobody has cared to
deal with the issue in over a decade.  That screams out UNIMPORTANT.
Remember, there is such thing as false hope. And if ever there was an
example of false hope it is someone hoping for a decade old issue in
Bugzilla that has been passed by by thousands of other issues.

-Rob

> As Guenter said before, the fact that an old issue is still there does
not
> means that it is not important, it only means that it was not possible,
for
> whatever reason, to solve it.
>
> Regards
> Ricardo
>
>
>
>>
>> Regards,
>>
>> -Rob
>>
>>
>> > The same is valid for issue 11901
>> > (https://issues.apache.org/ooo/show_bug.cgi?id=11901)
and many others.
>> >
>> > I always have accepted, that the lack of ressources/developers
prevents
>> to
>> > solve some/many issues "in time", but I could hardly accept, that
"old"
>> > stuff in bugzilla is reset/deleted and hence forgotten. I think, that
>> some
>> > old users ("issuers") would be frustrated.
>> >
>> > Instead of resetting the votes, one could have a list of 'issues with
>> many
>> > votes', "weight" them (f.e. as proposed by a survey) and then let the
>> > volunteers/developers decide, if they want to work on their "most
>> important"
>> > issues in the list.
>> > And perhaps for another ten years nobody is found to work on some or
all
>> of
>> > them! But that does not change the importance of such issues (provided
>> that
>> > importance is not only measured by age).
>> >
>> > Special cases are concerns/issues by "users" like the city of Munich
(as
>> an
>> > "beacon project", Leuchtturmprojekt), which can weight more than 1000
>> > individual votes.
>> >
>> > If the process is transparent, users and "issuers" will understand
(and
>> be
>> > patient).
>> >
>> > --
>> > Grüße
>> >
>> > Günter Marxen
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [email protected]
>> > For additional commands, e-mail: [email protected]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
 
CD: 18ms