4 ms·

I have an online friend who contributes to firefox. They are fairly beginner-friendly, though you probably need to have some C++ skills. https://www.mozilla.or

I have an online friend who contributes to firefox. They are fairly beginner-friendly, though you probably need to have some C++ skills. https://www.mozilla.org/en-US/contribute/ https://www.mozilla.org/en-US/contribute/

k__ 12y ago
I contributed to Firefox. The Mozilla guys are awesome. But if you are used to Github/PRs their Bugzilla/Hg-Patches workflow feels like going back in time... way back to the old days.
- jordigh 12y ago
  Ignore anything about MQ. They have old docs on using MQ that we've been trying to wean them away from. Modern hg is far better than MQ, and in some situations, better than git. You can edit, you can rebase, you can amend, you can evolve.
  - k__ 12y ago
    MQ?
    - jordigh 12y ago
      Mercurial queues. I thought that's what you meant with "patches".
      - k__ 12y ago
        Ah yes. MQ was the plugin used to create those patches, now I remember. They stopped using? Even on the main Firefox repo?
        jordigh 12y ago
        Like git, Linux, Mercurial, and gcc development, they have a patch-based code review flow, but MQ is not needed to produce the patches that they expect. You can do the same without MQ, and they will never know the difference on their end. I actually rather like email-based code review. It's really easy to keep editing and rebasing your patch while people comment on it. If Mercurial Evolve picks up, this will be an awesome new way to work, especially if Kallithea or Bitbucket grows the features to support it. However, current Mozilla development, AIUI, is moving towards ReviewBoard, although I have heard a growing mutinous group in Mozilla who just wants to chuck all homegrown solutions and slap all of their code on github like everyone else.
- indygreg2 12y ago
  We know. One of those things that was established 10+ years ago and has a lot of built-up inertia keeping it going. It's part of my job role at Mozilla to bring this process into modernity. We're getting there. Slowly. GitHub pull requests will be supported in some form. Hopefully by July.
deleted 12y ago
[deleted]
jgraham 12y ago
You absolutely don't need C++ skills to contribute to Mozilla. They are of course required to contribute to gecko, but that's only one possible contribution option. Others are: * Firefox UI and devtools. Written in a combination of js, HTML and XUL, with some C++ in the backend. * Automation and tools. Mostly Python-based, this is the infrastructure used to test Firefox and related projects. * Servo. The next-generation browser engine being written in Rust. * Gaia UI. The Firefox OS interface and associated apps. All written in JS + HTML. * Firefox for Android UI. Written in Java like other android apps. * Various web tools. Typically written in HTML + JS + Python, but backends differ (there's an increasing amount of node.js, Bugzilla is in Perl, etc.) * QA and testing. Writing testcases for the web platform and other browser features. Typically requires HTML and JS skills, and well as the ability (for Platform tests at least) to read specifications. * MDN. Documentation of Mozilla projects and the Web platform. Requires writing (not necessarily in English!) and good technical understanding. That's just off the top of my head, I'm sure that there are a bunch more projects someone will be annoyed I've missed ;) There's a more detailed list of the projects by technology at [1]. I like to believe that Mozilla is quite good at welcoming new contributors; it's certainly something we work at, although there are of course always opportunities to improve. There's a page of getting-started tutorials at [2], a database of bugs with assigned mentors grouped by technology at [3], and a dedicated irc channel #introduction on irc.mozilla.org. It is true that not every Mozilla project uses a familiar GitHub workflow, but it true that many recent projects do. For example Servo and Gaia are both fully GitHub-centric. For the more aged projects using Mercurial, we are in the process of moving from a patch-based workflow to a more modern branch-based one, with review in ReviewBoard. So there is still a learning curve there, but it's at least getting better. And finally — because this is my own special interest — if you are tired of web browsers having troublesome incompatibilities and want to be part of the solution, consider contributing to the open-source web-platform-tests testsuite at the W3C [4], [5]. This is a expanding repository of tests covering the open web that are being run against every single commit to Gecko (and Servo!) so that the developers are aware of implementation errors before they become interoperability issues. [1] http://www.whatcanidoformozilla.org/ http://www.whatcanidoformozilla.org/ [2] http://codefirefox.com/ http://codefirefox.com/ [3] http://www.joshmatthews.net/bugsahoy/ http://www.joshmatthews.net/bugsahoy/ [4] https://github.com/w3c/web-platform-tests https://github.com/w3c/web-platform-tests [5] http://testthewebforward.org http://testthewebforward.org

k__ 12y ago

I contributed to Firefox. The Mozilla guys are awesome. But if you are used to Github/PRs their Bugzilla/Hg-Patches workflow feels like going back in time... way back to the old days.

jordigh 12y ago
Ignore anything about MQ. They have old docs on using MQ that we've been trying to wean them away from. Modern hg is far better than MQ, and in some situations, better than git. You can edit, you can rebase, you can amend, you can evolve.
- k__ 12y ago
  MQ?
  - jordigh 12y ago
    Mercurial queues. I thought that's what you meant with "patches".
    - k__ 12y ago
      Ah yes. MQ was the plugin used to create those patches, now I remember. They stopped using? Even on the main Firefox repo?
      - jordigh 12y ago
        Like git, Linux, Mercurial, and gcc development, they have a patch-based code review flow, but MQ is not needed to produce the patches that they expect. You can do the same without MQ, and they will never know the difference on their end. I actually rather like email-based code review. It's really easy to keep editing and rebasing your patch while people comment on it. If Mercurial Evolve picks up, this will be an awesome new way to work, especially if Kallithea or Bitbucket grows the features to support it. However, current Mozilla development, AIUI, is moving towards ReviewBoard, although I have heard a growing mutinous group in Mozilla who just wants to chuck all homegrown solutions and slap all of their code on github like everyone else.
indygreg2 12y ago
We know. One of those things that was established 10+ years ago and has a lot of built-up inertia keeping it going. It's part of my job role at Mozilla to bring this process into modernity. We're getting there. Slowly. GitHub pull requests will be supported in some form. Hopefully by July.

deleted 12y ago

[deleted]

jgraham 12y ago

You absolutely don't need C++ skills to contribute to Mozilla. They are of course required to contribute to gecko, but that's only one possible contribution option. Others are: * Firefox UI and devtools. Written in a combination of js, HTML and XUL, with some C++ in the backend. * Automation and tools. Mostly Python-based, this is the infrastructure used to test Firefox and related projects. * Servo. The next-generation browser engine being written in Rust. * Gaia UI. The Firefox OS interface and associated apps. All written in JS + HTML. * Firefox for Android UI. Written in Java like other android apps. * Various web tools. Typically written in HTML + JS + Python, but backends differ (there's an increasing amount of node.js, Bugzilla is in Perl, etc.) * QA and testing. Writing testcases for the web platform and other browser features. Typically requires HTML and JS skills, and well as the ability (for Platform tests at least) to read specifications. * MDN. Documentation of Mozilla projects and the Web platform. Requires writing (not necessarily in English!) and good technical understanding. That's just off the top of my head, I'm sure that there are a bunch more projects someone will be annoyed I've missed ;) There's a more detailed list of the projects by technology at [1]. I like to believe that Mozilla is quite good at welcoming new contributors; it's certainly something we work at, although there are of course always opportunities to improve. There's a page of getting-started tutorials at [2], a database of bugs with assigned mentors grouped by technology at [3], and a dedicated irc channel #introduction on irc.mozilla.org. It is true that not every Mozilla project uses a familiar GitHub workflow, but it true that many recent projects do. For example Servo and Gaia are both fully GitHub-centric. For the more aged projects using Mercurial, we are in the process of moving from a patch-based workflow to a more modern branch-based one, with review in ReviewBoard. So there is still a learning curve there, but it's at least getting better. And finally — because this is my own special interest — if you are tired of web browsers having troublesome incompatibilities and want to be part of the solution, consider contributing to the open-source web-platform-tests testsuite at the W3C [4], [5]. This is a expanding repository of tests covering the open web that are being run against every single commit to Gecko (and Servo!) so that the developers are aware of implementation errors before they become interoperability issues. [1] http://www.whatcanidoformozilla.org/ http://www.whatcanidoformozilla.org/ [2] http://codefirefox.com/ http://codefirefox.com/ [3] http://www.joshmatthews.net/bugsahoy/ http://www.joshmatthews.net/bugsahoy/ [4] https://github.com/w3c/web-platform-tests https://github.com/w3c/web-platform-tests [5] http://testthewebforward.org http://testthewebforward.org