Results of Community Research

Frédéric Buclin lpsolit at
Tue Jan 19 09:33:49 UTC 2010

Le 19. 01. 10 03:13, Max Kanat-Alexander a écrit :
> 	So my question was--what happened in 2005 that changed things so
> dramatically? After QUITE a bit of searching, I discovered the following:

I'm a bit surprised that nobody mentioned that 1) we have much less
visible bugs in our code since the QA team exists (July 2005:, and so it's much less obvious for
people to fix bugs they don't see unless they look at the code itself.
Also, I heard here and there that 2) Bugzilla pretty much does all what
some old contributors needed and so don't need to contribute any more.
Why would you contribute for a feature you don't need? My personal
opinion is that 2005-2006 also reflects some maturity of the product. I
don't try to minimize what you mentioned in 1)-3), don't take me wrong.

> 	Now, #2 and #3 above pretty much cover my recommendations on how we
> should behave toward new community members: be really, abnormally,
> really, really kind, and don't be mean.

<troll>I hope this doesn't involve sending flowers to all our
contributors with a greeting card.</troll> More seriously, "abnormally,
really, really" sounds excessive to me and is not something I will fall

> 	1. I personally have started to prioritize review requests from
> non-core contributors above anything else, including security work,

Wow, security work should have the highest priority, IMO, because they
often block releases (same for blockers). And we from time to time delay
checkins because we are near a release date and we don't want to mess
the code too late in the game. So having releases done faster would help
focusing on new contributors once we have security bugs and blockers out
of our plate. At least, that's my point of view. To be clear, I'm since
early December ignoring *all* requests for review which aren't about
blockers, security bugs or targeted 3.6 or older, no matter who the
requester is or how cool the new feature is. My remaining free time and
motivation are devoted to QA. The sooner 3.6rc1 and 3.6 are released,
the sooner I will accept looking at other contributions again.

> 	2. I think we should say that if you're a reviewer, it's your
> responsibility to receive the review-requests emails, and we should
> merge review-requests back into review at .

Please don't do that! reviewers@ and review-requests@ have different
goals. And I recently unsubscribed from review-requests@ for a reason
(after being 5 years in this mailing-list). Keep them separate, and just
email reviewers@ to subscribe to review-requests@ if they want to. I
don't see why you can/should/would be allowed to force them to read all
review requests. It's prone to be redirected to the trash bin directly.
And if you are the requestee, you already get review requests directly

> everybody would get every review request, and even review from the
> "wind" might start to work again.

Out of the current 46 pending reviews in the Bugzilla product (4 of
which are more than 5 months old!), we have only 4 requests from the
wind. That's a pretty weak excuse to spam all reviewers with all review

Oh, and thanks for this research! ;)


More information about the developers mailing list