Tracking bug for making the Gfx team community-friendly

NEW
Unassigned

Status

()

Core
Graphics
6 years ago
5 years ago

People

(Reporter: bjacob, Unassigned)

Tracking

Trunk
mozilla9
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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.
(Reporter)

Comment 1

6 years ago
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.
(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

6 years ago
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.
Target Milestone: --- → mozilla9
Version: unspecified → Trunk
(Reporter)

Updated

6 years ago
Depends on: 700825
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.
You need to log in before you can comment on or make changes to this bug.