On a personal note I think we have been behaving too careful about this
kind of stuff and as result we have been becoming more and more closed
"just in case" and that has been a problem for community participation.
Let’s go back to be open by default if we want to avoid losing the
essence of what we are
That is entirely possible, and this is what I have been doing generally (e.g. with my “Re-dreaming Firefox blog series”), but I felt that this topic was more touchy. Ah, well, we’ll see.
Oh, were you thinking of doing this in private? I was assuming this would be out in the open, for all to see.
Yeah - the topic body could be the suggestion itself, and people could vote for it by liking it, and comment by replying. I don’t think it would take killer amounts of code to add a more prominent like count somewhere (like on the topic list page for the category), if deemed necessary.
I may be misunderstanding, but don’t likes (the heart you can press below a Discourse post) do exactly that: minimize the noise? I find it’s incredibly useful in existing discussions to signify your support for something, or acknowledge somebody else’s point, without having to create a new post.
No, I was clarifying that it’s possible to restrict stuff to vouched mozillians only. For example, a public category where only vouched can create topic/like.
I think that if we’re waiting for the project managers to go through these then we’ll definitely have way too many proposals for them to use their time wisely going through them. Ideally proposals would get moderated (like bug triage) for completeness and to look for spam.
After that I think it makes sense that people who can actually implement the proposal need to champion them. Rather than the project manager saying “hey team, I think this is a good idea” a developer says “hey, I like this idea and I’d like to work on it.” It could also allow volunteer developers to step up and say “I want to work on this, will it be well received?”
I also think we could take a page out of Participation’s strategy and start with a pilot. We need to not be afraid to iterate as new problems or good ideas come along.
Ah, we’re not talking about the same noise. I was talking about minimizing the number of proposals that are bad for some reason (e.g. incomplete, or not useful for users, or not aligned with Mozilla’s mission) and that Product Management would have to read through.
Can Discourse be configured for something a bit more sophisticated than Like? i.e. voting on several criteria?
I didn’t know that Discourse could do that. I believe that this would be useful.
It would be possible with a plugin. What type/range of criteria were you thinking of?
I don’t think it’s quite as fine grained as use being able to control who can like or not, but we can definitely restrict who can post, reply or see in a category.
I think that if you can post, you can like.
Question: What’s the lightest weight, fastest, simplest and most data driven way to test this idea?
I ask because I don’t think the tool or process matters much at this point – or at least it’s certainly way less important than testing the benefits and efficacy of the core idea:
- making Mozilla more visibly transparent;
- improving morale;
- improving community interactions;
- surfacing good ideas;
- surfacing ideas specific to locales that are not currently represented by Product Management (i.e. most of the world).
All of these are totally unproven. And we can’t prove them through thinking them out. So let’s find a way to test them, quickly, and with minimum effort.
I think previous suggestions are super quick (we already have the tool and requires 0 development), a Discourse category where anyone can read but only vouched mozillians group can create a topic and like other topics.
We would just need to write a template an set it as pinned topic there on what the topic should include, like a clear topic subject and a few lines explaining it in the body.
OK, probably we would just need to apply something like this to sort by likes:
And we can just show open topics, so once something is implemented or discarded the topic can be closed and won’t be displayed.
Edit: This is exactly how the Discourse dev team gathers feature requests from forum users:
I don’t think testing the tool or an open process is what we need to test. I think we need to test, narrowly, the concept of Mozillians providing product ideas, and product teams sifting through those for value.
Here’s what that would look like to me:
Yes, I agree, I was just commenting on how we can test that voting process with almost no effort with the current tools we have right now. Maybe in the future we decide to use other tool or just discard everything because it wasn’t a success.
This is an interesting point. We have to assume that the majority of proposals are not going to be adopted. Will enough be adopted that people will get the morale boost from knowing that the community at large was listened to and gets a say?
Regarding collecting the ideas, I believe you’re saying not to solicit more ideas, but to approach people who have already made suggestions and invite them to participate in the trial. That way we can compare if they felt more satisfied with the proposal process or if they feel like it ends up being more hoops to jump through to still get turned down.
On the product team side, I’m curious what the current process is for deciding what to work on. Is the current process very similar to the proposal, but is mostly done internally? Or is it done in a totally different way? It could be that for the teams this would also be an experiment in using proposals at all.
Then we should clarify very well that having a proposal with a lot of support doesn’t mean that it’s going to be implemented, but we should make sure that at least they are evaluated from the product side and for the “highly supported” ones at least a reply from the team about the decision.
@george how easy do you see to have this kind of support from product side?
My guess is that the product people would be open to this, if we could help
frame it in a lightweight way for them.
So, what would be the next steps for this? Define a proposal draft with the concept of Mozillians providing ideas and product teams checking them?
I think the next step would be to find a product team willing to participate. Without that, everything else is moot.
This initiative seems to have gone dormant 
I think we’ll need a champion to lead this and work with all stakeholders (specially product teams) to frame the conversation.
Who has time and want to lead this?
Hi
I really like this idea and I agree with @majken that getting support from the product teams is vital. They often have roadmaps already in place for future releases, but they may find this process useful for a) helping to prioritise and b) for new ideas that are currently off the plan.
I also agree with point made by @yoric that it would get the community more involved. If you think of the vouched Mozillian community as “super users” we are in a good place to help guide Mozilla software development. Just think of the range of possible areas from coding to GUI that contributors could have ideas in relation to.
Let us not get too carried away though. The idea of a trial process makes a lot of sense, but I would suggest that it is limited to one product (for example Firefox for Android) so that the trial can work with, and get feedback from, one product team. This will give good feedback to either build on this for a possible wider role out. As with any good idea, people need to appreciate that this channel/forum/thing may not work - failure is not bad, it just means people need to find a different approach.
As someone that is a member of the vouched Mozillian community and has no coding skills, but who has experience of pitching good ideas in a non IT setting, I may be willing to help wrangle this, however, I would need to hold fire on doing anything until mid-May at the earliest due to other (non Mozilla/SUMO) volunteering commitments.