Personally, I'm a fan of voting for features on bugzilla. It's already integrated into tools (ie. bugzilla), it is clearly measurable, and it requires very little overhead from participants. I agree that the results can be somewhat skewed because of things like reddit links, but I see that as a validation of voting rather than a problem. If someone cares enough about a feature to write a blog post (or reddit self post), and then a lot of people go to bugzilla and "+1" it, well this is crowd-sourcing in action. Also, I think the results become less skewed the more we promote the voting feature within our participation channels.
On Tue, Nov 24, 2015 at 3:56 AM, Peter Dolanjski <[email protected]> wrote: > I suppose the ideal for me is "members of the community post >> well-reasoned arguments for why a feature matters", and we evaluate the >> feature request on its merits. The upside to this is that it can't be >> skewed just because someone posted a link to Reddit. If done well, I >> think it can also foster a better sense of community, because developers >> and triagers are replying directly to members of the community (either >> saying "yes, this is a good idea and we should give it X priority", "no, >> this doesn't fit in with our vision", or "we're not sure, can you >> elaborate?"). >> >> However, this has some downsides: there's no longer a metric people can >> track to see what issues people care about. Instead, we all have to be >> vigilant and refuse to let bugs ever get stuck in limbo. That makes it >> harder to figure out if we're doing a good job, but not impossible. One >> thing we can do is to make sure there aren't any open bugs that haven't >> been updated in a long time (you could exclude bugs explicitly tagged >> with "backlog" or something). It can be pretty discouraging if you post >> a feature request, idea, bug, etc, and then no one replies at all. I've >> been working to remedy this in the Music component, but it's quite a bit >> of work to clean up all the bugs. However, once we're caught up, it >> should be a simple matter to spend a few minutes a week triaging and >> categorizing incoming bugs. > > > I suppose the main thing I'm trying to solve for is bringing visibility to > features/ideas that many people care about - for two audiences: 1) Mozilla > employees for us to assign our resources and 2) the community in order to > highlight items that many people care about as an identifier of things that > community members can pick up and run with (with impact). > I agree that reasoned discussion is needed for each idea, but it would be > ideal to know how many people care. Perhaps that can be judged indirectly > from bug comment activity, but I'm wondering if there is a lower touch way > to help surface this. > > Peter > > On Mon, Nov 23, 2015 at 9:09 PM, Jim Porter <[email protected]> wrote: > >> On 11/23/2015 07:33 PM, Peter Dolanjski wrote: >> > *Voting for Feature Requests* >> > We originally introduced this as some way to gauge the desire for new >> > features from our foxfooder audience (rather than try to aggregate email >> > based feedback or +1s). It's definitely not perfect and can be skewed. >> > Is there an alternate approach that others have seen work for the >> > desired purpose here (to act as aggregate voice for the community on >> > what they'd like to see in the product)? >> >> I suppose the ideal for me is "members of the community post >> well-reasoned arguments for why a feature matters", and we evaluate the >> feature request on its merits. The upside to this is that it can't be >> skewed just because someone posted a link to Reddit. If done well, I >> think it can also foster a better sense of community, because developers >> and triagers are replying directly to members of the community (either >> saying "yes, this is a good idea and we should give it X priority", "no, >> this doesn't fit in with our vision", or "we're not sure, can you >> elaborate?"). >> >> However, this has some downsides: there's no longer a metric people can >> track to see what issues people care about. Instead, we all have to be >> vigilant and refuse to let bugs ever get stuck in limbo. That makes it >> harder to figure out if we're doing a good job, but not impossible. One >> thing we can do is to make sure there aren't any open bugs that haven't >> been updated in a long time (you could exclude bugs explicitly tagged >> with "backlog" or something). It can be pretty discouraging if you post >> a feature request, idea, bug, etc, and then no one replies at all. I've >> been working to remedy this in the Music component, but it's quite a bit >> of work to clean up all the bugs. However, once we're caught up, it >> should be a simple matter to spend a few minutes a week triaging and >> categorizing incoming bugs. >> >> - Jim >> _______________________________________________ >> dev-fxos mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-fxos >> > > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
