On Aug 15, 2013, Dwight <[email protected]> wrote:
>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/76a6f7eb-02e4-491e-be2b-58017e9af9a8%40email.android.com. For more options, visit https://groups.google.com/groups/opt_out.
