Last Comment Bug 686998 - Tracking bug for making the Gfx team community-friendly
: Tracking bug for making the Gfx team community-friendly
Status: NEW
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla9
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 700825
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-15 16:41 PDT by Benoit Jacob [:bjacob] (mostly away)
Modified: 2012-03-23 17:34 PDT (History)
23 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Benoit Jacob [:bjacob] (mostly away) 2011-09-15 16:41:01 PDT
The demographics of the Gfx team are currently:
  * roughly 10 Mozilla employees
  * roughly 2 employees of other companies
  * 0 volunteers

If we extend "Gfx team" to include canvas 2D implementers then we find Ms2ger which ups the volunteers count to 1... arguably Ms2ger counts as 2 but still... we should try to do better.

Some ideas:

1. File bugs as early as we identify TODO items. Put mentor=yourbugzillaid in the Status Whiteboard field. Take 5 min to write a detailed explanation and give context (explain how it relates to other bugs) in the bug description. This mentor= syntax is standard, other teams are using it already.

2. Have a wiki page as 'portal' to get into Gfx development, learn tools, learn what our current projects are, who's working on what. The JS team has such a page already:
https://wiki.mozilla.org/JavaScript:New_to_SpiderMonkey

Note: 1. and 2. are from this email,
    http://groups.google.com/group/mozilla.dev.platform/browse_frm/thread/1687bf264252e153#
from Josh Matthews. Did you know he's "coding contributor engagement lead"? So he's the person to ask more questions to.

3. I attended a talk by Jono Bacon from Ubuntu today. I asked how to fix community involvement in areas where it's really bad. He mentioned the idea of Ubuntu Open Weeks:
    https://wiki.ubuntu.com/UbuntuOpenWeek/
They have IRC sessions, Q&A... been working well for them. Time consuming for us, though.
Comment 1 Benoit Jacob [:bjacob] (mostly away) 2011-09-16 17:32:03 PDT
Today I chatted with dboswell (in CC). The Mozillians Phonebook project is going to be very useful for point 2 in comment 0. But it is still monthes away. We should carry on with the wiki page idea for now and let the Phonebook team know about our needs so we can eventually merge into it.
Comment 2 Benoit Girard (:BenWa) 2011-09-16 17:44:33 PDT
(In reply to Benoit Jacob [:bjacob] from comment #0)
> 1. File bugs as early as we identify TODO items. Put mentor=yourbugzillaid
> in the Status Whiteboard field. Take 5 min to write a detailed explanation
> and give context (explain how it relates to other bugs) in the bug
> description. This mentor= syntax is standard, other teams are using it
> already.

This is very important and I would like to see more of these from us. I've started doing this and have had interest in a few bugs. Out of the 3 people I've answered questions one posted a promising patch:
https://bugzilla.mozilla.org/show_bug.cgi?id=678324
Comment 3 David Boswell 2011-10-03 16:22:02 PDT
There are definitely some good ideas already in this bug (such as tagging bugs with mentor= and keeping that list up to date) so we can spin those off as separate dependent bugs.

We may also want to work together with other people looking to make similar improvements.  As mentioned earlier, Josh Matthews has been doing a lot with onboarding people interested in coding and several other people have also expressed interest in being a coding Steward.  For reference see:

https://wiki.mozilla.org/Stewards/Coding

For example, if we do create a curated list of mentored Gfx bugs, that will give Josh a good list to choose from when people show up and are interested in having a specific task to start with.
Comment 4 Jeff Gilbert [:jgilbert] 2012-03-23 17:34:30 PDT
From bjacob's great intro on bug 728354, I threw together https://wiki.mozilla.org/Platform/GFX/WebGL/Contribute/Extensions instead of writing similar boilerplate for the handful of other extension mentor-bug opportunities we have.

Note You need to log in before you can comment on or make changes to this bug.