On Aug 12, 2013, Joel Azaria <[email protected]> wrote: ÷The bugs/requests themeselves should ÷be stored/prioritized/etc. in a private ÷bug tracking (e.g. a ticket system,÷Kanban board (eg. Trello) or something ÷similar) for internal usage and tracking ÷through dev and QC to release
Joel, I'm happy to inform you that the devs are using JIRA for this purpose, internally with the private beta testing team. ÷Without the red dots, you only get ÷half the picture. I agree with you. UserVoice was selected and set up by a user. When I complained at the time that I could not vote against a popular proposal that I opposed, he challenged me to find something that (a) was free, (b) forced users to prioritize by limiting the number of votes, (c) supported votes against a propo -Dwight MLO Betazoid & Moderator Via k@mail on sgn2 On Aug 12, 2013, Joel Azaria <[email protected]> wrote: >Not to be a wet blanket and many thanks to those who work to keep the >community going but I have to add my 2c here: > >Uservoice is an extremely flawed model to use for feature suggestions. > >Drknight's post illustrates this well: > > >On Friday, January 7, 2011 6:27:43 PM UTC-5, drknight wrote: >> >> ... Traditionally this come from >> dot voting, where people in a room are given 10 green dots and 10 red > >> dots. People would put green dots on topics/ideas they supported and >> red dots on items they opposed. Without the red dots, you only get >> half the picture. What if an idea has 47 green votes but 289 red >> votes. You wouldn't do it. Right now all we get is the green dots >> making it sound like the idea is a compelling, good, and valid one. >> >> >The concept of giving out 10 green dots and 10 red dots begets there >being >a limited scope/number of issues to vote with them on. As the sheer >number >of Uservoice requests continues to grow, each persons 10 votes becomes >more >and more diluted in reference to the size of the request pool. >This is compounded by what I call 'amorphous blob' requests that are >too >broad to be considered just a 'feature' request and so too easily >vacuum up >votes that might be better spent to flesh out actual 'feature' requests > >that now may go unnoticed. > >A simple (generic) example would be if i wanted an enhancement to the >way a >view is handled for instance, this might be a good idea that impacts a >fair >little percentage and so could garner some user votes if it's seen and >explained well so that others understand the request. >However if it's competing for attention against a blob request like "we > >want an iPhone app" it's going to get lost. Clearly just about EVERY >mlo >user with an IOS device will HAVE TO vote for the ios app. And so 3 >votes >are 'stolen' from bringing attention elsewhere. > >Why is the iPhone app a blob you ask? Because it's not a single >*feature*, >it's a whole host of 'features' (actually HUGE TON of features..) >True, many ppl will want it, just likely not all for the same reasons >('features'?) which is why this one 'request' alone could (would) >support >an entire uservoice forum all it's own. >I understand the need for people to express there want of such things >but >to shoehorn them into the same forum where I'm supposed to request my >little View enhancement greatly tilts the scale to my request getting >buried under the mountains of a few amorphous blobs. > > >For uservoice to be effective imo, it must have a limited number of >issues >to be voted on. In other words a fairly well curated and condensed >list of >features for users to vote on. >Which is not what the MLO UV is now and not even something the UV >format >encourages which is why I called it flawed. >It's absolutely a big reason why I (and I would guess others) simply >don't >bother with it. > > >yes it's easy to tack on +1 to a passing post. If you're following >along >(the devs teams that is) you could engage that poster easily enough by >asking a question. That helps flesh out the request and also helps >gauge >poster's 'commitment' to that request. Not perfect, but better than >the UV >option imho. > >The bugs/requests themeselves should be stored/prioritized/etc. in a >private bug tracking (e.g. a ticket system, Kanban board (eg. Trello) >or >something similar) for internal usage and tracking through dev and QC >to >release. > > >-- >You received this message because you are subscribed to the Google >Groups "MyLifeOrganized" group. >To unsubscribe from this group and stop receiving emails from it, send >an email to [email protected]. >To post to this group, send email to [email protected]. >Visit this group at http://groups.google.com/group/mylifeorganized. >To view this discussion on the web visit >https://groups.google.com/d/msgid/mylifeorganized/fe554393-61d2-46ab-a67f-d765dc9ab5a1%40googlegroups.com?hl=en. >For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mylifeorganized. To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/7d437d40-42eb-402a-9699-866b048bdb5c%40email.android.com. For more options, visit https://groups.google.com/groups/opt_out.
