
I made a patch for Mozilla, and you can do it too - martius
http://marti.us/w/2014-07-19-Mozilla-BSP.html
======
paulrouget
I've been working with new contributors for some years now. Here are some
advices:

\- find a mentor. It will helps a lot (use
[http://www.joshmatthews.net/bugsahoy/);](http://www.joshmatthews.net/bugsahoy/\);)
\- for the first bugs, writing code is not usually the hard part.
Understanding bugzilla and writing tests are; \- ask for a commit access level
1 early to have access to the try servers (to run the tests); \- finish what
you start. Bug is fixed when it lands, not when a patch is attached; \-
mozilla hackers are nice people, ask questions on IRC. There's no stupid
questions (we all started from zero too);

Everything will get much easier after the first bug fix. And motivation grows
a lot once you have finally landed some code :)

~~~
dfabulich
It would be helpful if the Mozilla Bugzilla had some way of opting in to
identifying that you have a mentor, so that it would be easy for reviewers to
see, "hey, this person's working pretty hard on this bug, but he hasn't
declared a mentor. We should suggest that he find a mentor."

I say this as a person who wasted two years working on a Firefox patch, which,
in hindsight, would have landed in a month or two if I'd had a mentor. (Not
that I'm bitter.)
[https://bugzilla.mozilla.org/show_bug.cgi?id=347174](https://bugzilla.mozilla.org/show_bug.cgi?id=347174)

~~~
jgraham
As of a few weeks ago, bugzilla has a "mentor" field which is being used to
identify bugs that are good for new contributors to work on and the correct
person to mentor them. It would certainly make sense for someone looking to
work on a bug with no suggested mentor to ask for one. If you have any
suggestions for how to make this work well in the UI, it would be good to
hear; expecting people to notice "this bug doesn't have a mentor field so I
should ask for one" seems rather unlikely to work.

The bug that you worked on was a bit of an outlier in the sense that:

* It modified relatively complex parts of the code. * There was initially no (HTML) spec for the feature. * There was initially insufficient information to know what the spec for the feature ought to say.

So I think a mentor might well have told you "this is not a good first bug".
Of course that make it all the more impressive that you pushed through the
difficulties and got the patch landed and the spec fixed along the way. Thank
you for that! The main delays seem to have been waiting for review, which a
mentor may or may not have been able to help with depending on whether there
were other less-busy qualified reviewers, and waiting for the patch to land,
which these days we have a better process for and so which wouldn't happen
again.

~~~
dfabulich
I asked around on IRC after the fact; it was generally agreed that I should
have requested other reviewers rather than waiting months for feedback. If
only I'd known!

But that's kind of my point. "Mentored bugs" is an interesting approach, but
normally people have mentors, not bugs, and I think that having a
"mentor/mentee" field on user profiles may be the right approach for Mozilla;
the field would show up on comments/patches I post.

That way, the reviewer could have seen on my profile that I'm new to fixing
Mozilla bugs and unmentored, and in his first review, he could have suggested,
"I think you should fix these things, and BTW, I think you should find a
mentor to shepherd you through this process."

------
vasi
I did it!
[https://bugzilla.mozilla.org/show_bug.cgi?id=548763](https://bugzilla.mozilla.org/show_bug.cgi?id=548763)

Unfortunately it took quite a long time, the Mozilla process is quite
confusing to a newcomer, even one with a lot of open source project
experience. I definitely second the recommendation of finding a mentor.

~~~
agentultra
I don't think I would have been able to get my two patches into Mozilla if it
wasn't for the mentored bugs program. It's incredibly useful and I wish more
projects would implement it. _ahem_ openstack _cough_.

~~~
desipenguin
openstack is a "commercial" open source. Several (if not most) developers who
contribute are paid by "companies" \- so typically new "contributors" find
mentors within their "company"

------
Diastro
In your post you mentionned that a goo way to start working with open-source
project it to look for smaller scale projects to contribute on github. If been
working hard to make it easier for people to find interesting/smaller projects
on github by creating the /r/coolgithubprojects and the
[http://coolgithubprojects.com/](http://coolgithubprojects.com/) website
lately. It's not perfect but anyone who's looking to contribute and find
interesting will (I hope) find these tool useful. They're not perfect yet but
we'are working hard to making open source project sharing as easy as
possible!. My 2 cents.

~~~
bleakcabal
I have also created a site designed to help people find smaller scale Github
projects. You can find it here : [http://gilles-
leblanc.github.io/dispatcher/](http://gilles-leblanc.github.io/dispatcher/)

------
gluxon
I've done this a few times for bugs that have personally annoyed me. Gotta
say, it's easy to get started and the reviewers are amazing.

------
zokier
I wonder how much of his positive experience is due the fact that he decided
to contribute to Servo instead of one of the "main" Mozilla projects (Gecko,
SpiderMonkey, Firefox etc). Less hairy codebase, smaller community, github-
based, and probably lot more suitable low-hanging fruits.

~~~
__david__
I got a couple patches through to Firefox proper. One was a fairly easy
bugfix[1], but the other[2] took me lots and lots of iterations to get
correct. The mentor was _extremely_ patient, taking what I think was more time
to explain to me how to do it right than it would have taken him/her to just
do it themselves.

The worst part for me wasn't understanding the code (though following through
some of the XPCOM stuff is tough), but working with Mercurial. I was tempted
several times to abandon it and use a git mirror. Anyone that says patch
queues are equivalent to git rebase is crazy.

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=1006656](https://bugzilla.mozilla.org/show_bug.cgi?id=1006656)
[2]
[https://bugzilla.mozilla.org/show_bug.cgi?id=907310](https://bugzilla.mozilla.org/show_bug.cgi?id=907310)

~~~
daleharvey
If you dont need to actually push the code to the reposity (which you wont for
the first bunch of patches) it is totally fine to use git, the github mirror
is at

[https://github.com/mozilla/gecko-dev](https://github.com/mozilla/gecko-dev)

and you can just upload patches for review

~~~
cpeterso
Mozilla also hosts its own git server:
[http://git.mozilla.org/](http://git.mozilla.org/)

------
DomingesZ
What's kind of skills for programming with Mozilla?

~~~
padenot
Basically, anything. Have a look at
[http://www.whatcanidoformozilla.org](http://www.whatcanidoformozilla.org) to
have a glimpse on what you can do for the project.

~~~
gknoy
Thank you for sharing that. I had NO IDEA that the Mozilla team had such
diverse needs, and had always assumed that it was all over my head.

------
jonalmeida
I think the real take away is that this same experience can be applied to any
large open source project that seems daunting to new comers, not just for
Mozilla.

I had a similar experience with emscripten (yeah I know, Mozilla too)
initially. So I start working on a project with the following steps:

\- Download code \- Setup environment \- Run test suite (if exists) \- Play
with simple bits of code by hard coding changes and building it to see it's
effect. \- ... sleep? \- Attempt baby bug first

------
izietto
I made one single patch for Mozilla [1], and I love how it was easy for me to
receive informations about how to submit a patch correctly and how to improve
my fix, even if I have a big language disadvantage (my english is poor).

I hope I'll have the chance to contribute again to this great open source
browser.

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=935741](https://bugzilla.mozilla.org/show_bug.cgi?id=935741)

------
barkingllama
Too bad we can't patch IE.

~~~
_random_
...and JavaScript. And HTML.

------
terminado
...but can I patch the look and feel of the user interface, or are we not
permitted to patch superficial things that affect "branding" and user
experience?

I liked Firefox 28, not Firefox 29 and up.

~~~
rockdoe
Given that people have written add-ons to do just that, there's no need to
even make patches for it.

~~~
cpeterso
The "Classic Theme Restorer" add-on works pretty well and has a lot of
preference to tweak the UI to your liking:

[https://addons.mozilla.org/en-
US/firefox/addon/classicthemer...](https://addons.mozilla.org/en-
US/firefox/addon/classicthemerestorer/)

