I think the politicking was a big factor in killing the voting system. I
remember many times when people would post to the list, urging others to
cast a vote for an issue so it would rise to the top. Those voters may
never have seen the bug but it sounded important and they had a vote or two
to spare.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 8, 2019 12:15:23 AM Richard Gaskin via use-livecode
<use-livecode@lists.runrev.com> wrote:
Terry Judd wrote:
> I'd totally forgotten about the Bugzilla voting system. I liked that
> approach as well and agree that bringing it back could help both us
> and LC to prioritise fixes.
Voting is one of those things that has a certain ring of rightness about
it (who doesn't love democracy?), and it's technically easy to do - so
why not?
It turns out that people are much more complicated than the systems we
create. :)
I had extensive discussion about the Bugzilla voting system with Kevin,
Mark Waddingham, and others there at LiveCode Ltd., in response to the
reactions many members of our community (including yours truly)
expressed when the voting was removed from the bug DB.
What I learned was that although it seems like a good idea, in practice
it winds up being a less useful indicator of the "importance" of a bug
than one might intuitively think.
In dry terms, one of the issues with it is that it conflates two very
different signals: one for the severity of a bug to the individual
experiencing it, and another for the number of people affected by the bug.
In practice, these are some of how it played out:
If I happen to feel a bug is super important, but five others think it's
merely worth reporting but isn't shutting down their work, my single
five-vote click doubles the number of votes. What does that mean?
We know it doesn't mean ten people find it unimportant. And it doesn't
mean that two people find it extremely important.
To fully understand exactly what a given tally score means requires
looking at the vote distribution, and also at the individual voters and
the details of their comments in the report.
So if I feel like casting five votes against it there's no way to know
whether I'm actually having an urgent need, or just having a mood to
make a point about the age of the report, or any number of things. I
might have also contributed a comment or example which could explain my
intention, or no further information at all.
And from time to time we may have a bug that's really critical, but so
far seen by fewer people. Such a report may have far fewer votes than
one that has little harmful effect but has been seen more frequently.
And then there are the times one of us will get particularly incensed
about a pet issue (some of you may recall times I've done this myself),
and we rant about it here and encourage votes for the pet issue. I'm
sure some of those votes were people who actually experienced the issue,
but I'm equally sure some of those were just friendly people being
supportive, and not votes that would have arrived there organically
without the politicking.
Give it some time and each of us can imagine other scenarios that muddy
the clarity of that vote signal.
By the time a developer working on the bug looks at the various aspects
relevant to understanding what the vote tally really means, there's
enough familiarity with the details that an assessment of priority can
be made just as easily without it.
There remains at least one element which could loosely be seen as a sort
of voting: a bug's CC list.
Usually an address will wind up there after that person has experienced
the bug, searched the DB for it, and found that it had been reported.
When that happens organically, the number of people subscribing to a bug
can be a useful addition that, with the other details of the report,
help the team evaluate priority.
And being a single value per user, it's a single signal rather than a
conflation of two different signals as the old form with multiple votes
did, so it's more immediately clear what it's signifying.
--
Richard Gaskin
LiveCode Community Liaison
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
