Right -- I think we need to keep refining and enriching our vocabulary,
mental model, tooling, metrics, etc. for understanding our contribution
goals and the steps along the way.

As an example -- Labs has indeed has a variety of mechanisms for
collecting "ideas" and often places to "discuss ideas".  But it turns
out in practice that ideas is not what we're short of.  What "Labs" has
needed, it turns out, is much more subtle and _precise_ than that, which
is why we've in fact shut down all of those "generic idea pools", as
they were misleading -- people felt they were contributing, but in fact
nobody had the time (or focus) to extract value out of their efforts.

What Labs needs in fact depends a lot on the project -- some need
feedback on a product concept; some need user testing; some need
architectural review/critique; some need design feedback; some need
performance analysis; some need regulatory input!  For each of these
kinds of contribution types, it turns out, we need to build explicit,
carefully designed, contribution models, each with its own pipeline,
communication mechanisms, selection criteria, etc.  I'll be the first to
admit that we're very, very early in that process. And it's also clear
that some of the modes of contribution map more or less well a) to our
past practices, and b) to the utopian default of "anyone's input is
equally valued".

As an example, I had an idea recently for how we could make it easier
for websites to safely build webapps for kids.  While I could start a
wide open thread about that, and it would likely gather hundreds of
messages, and at some point we will, the odds of getting the maximally
useful feedback from that thread is low.  Because the problem here isn't
"having ideas" but "figuring out whether the idea is compatible with US
and European laws-in-the-making", that would be a waste of my time _and
the contributors'_ time.  Instead, I should find contributors who are
experts in the field - legal scholars, kids-website-makers, carefully
chosen kids & parents, politicians even.  Once I understand the
regulatory model better, if the idea has any hope, then we'd broaden the
ways of participating in that proto-project, in particular to see how
much we can extend the concept to other jurisdictions, for example.

The point is not to be opaque (it'll all be on public wikis etc.), but
that for any project to succeed one should be thoughtful about what kind
of contribution you _need_, what contributions you _want_, and what
percentage of your time you can afford to spend managing contributions
as opposed to doing.

In many, many areas, we should not shy from saying "you must be this
tall" to participate.  That "height" should be intentional though:
thoughtful, and explicitly avoid biasing for things that aren't
relevant, like employment status, and hopefully geography, timezone,
age, etc.

To be clear: I'm a _huge_ believer in the statement that Mozilla needs
to figure out how to massively increase the number of people that
contribute meaningfully to our success.  I also think that we've learned
a lot over the years (both within Mozilla and in other participatory
efforts from open source to elections and other environments) about the
need to _architect_ participation models (cue Tim O'Reilly).  I'm
personally hoping to spend a good chunk of Q2 thinking about that, and
getting people to help me do that for some of the Labs "architecture of
participation" in particular.

The point that I was trying to make was in (positive) response to
David's suggestion that there could be "product management office hours"
-- I think that in general all leaders (not just PMs/drivers) need to
have explicit, easy to understand engagement models -- those need to be
"reasonable" and "efficient" -- we don't want people who have a _lot_ of
work to _do_ to spend all their time hearing "constituent complaints".  
And for the record, I think that the vast majority of Mozilla leaders
already spend a huge amount of time hearing and listening -- but we're
maybe not good enough about being clear a) how/where to "speak" so that
you'll be heard, b) that we're indeed hearing the input.  We also need
to be clear that our jobs involve making decisions and moving things
forward, and that while we must hear the feedback, we need not agree,
not even with the majority.

--david