I feel like there are plenty of ways that a point system that avoids some of
these issues with the previous one could be implemented - fewer total votes per
person, single votes per bug only, no or reduced value votes for community
users, forced re-allocation of votes on a regular basis...
Yep, comments are a useful measure too - give them a value as well, maybe even
allow someone who has used up all their votes to 'mine' some new ones that way
- I reckon it shows they are engaged and contributing.
Terry...
On 8/10/19, 4:34 pm, "use-livecode on behalf of J. Landman Gay via
use-livecode" <use-livecode-boun...@lists.runrev.com on behalf of
use-livecode@lists.runrev.com> wrote:
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
