> > 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
