mozilla / webdev-bootcamp

INACTIVE - http://mzl.la/ghe-archive - How to be a Web developer at Mozilla

Mozilla Webdev Bootcamp

View this document at mozweb.readthedocs.org

A roadmap to success as a web developer contributing to Mozilla. Now with 80% more success!

Patches are always welcome! If you'd like to contribute, fork and make a pull request.

Building locally

The instructions below assume you have Python and pip installed. It is also strongly recommended that you create and activate a virtualenv first.

If you'd like to build the bootcamp locally:

pip install -r requirements.txt
make html

The resulting docs can be located under the _build/html directory.

You can also run make livehtml to launch a web server on http://127.0.0.1:8000 to rebuild the documentation automatically when any files are changed.

Licensing

Feel free to fork this repo or adapt its work for your own bootcamp. All work is licensed under a Creative Commons Attribution license.

webdev-bootcamp's Issues

Add git submodule details

Since all of our projects use a -lib repos as a submodule at vendor/ we should add submodule details to our docs.

Esp. "Common scenarios" - Add a library, Update a library, Remove a library, Change a library origin, Fork and/or branch a library submodule, etc.

CODE_OF_CONDUCT.md file missing

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

Add info about getting a blog on planet

File a bug; give them a URL to/off a feed. Use a category/tag so you can opt in per-post.

Keeping master in sync is confusing

We had someone ask about the .gitconfig example in http://mozweb.readthedocs.org/en/latest/git.html#keeping-master-in-sync. I have to admit that it confused me as well. The example there is probably not clear and we need to make it less confusing. Open this issue to start a discussion on how to make it more clear. Suggestions welcome, I'm happy to give a pull request.

What about educating webdevs about CSP?

I would actually like to help doing this.
(I am mostly filing this because I want to help with this and make sure I'm not forgetting ;))

Outline Bugzilla r? -> SVN workflow

Lots of legacy tools are in SVN and require to attach a patch to a bug, r? then hopefully r+, followed by a commit to SVN (mentioning the bug number in the commit message) and then RESOLVED/FIXED in bugzilla (while mentioning the revision number in the bug).

Improve docs for github pull workflow

Currently, in terms of github workflow we have this:

http://mozweb.readthedocs.org/en/latest/git.html#working-on-projects

I think two things are missing:

1. A slightly more elaborate explanation of these steps and/or weblinks with more information. The goal is to be able to point people (contractors, perhaps) at this and they should know how to get their code reviewed on an ongoing basis.
2. There's no mention of rebasing/squashing commits before sending a pull request or landing it. There are different opinions on this, so we shouldn't go straight for the strictest option, but "squash your list of commits down to a few commits" or so is probably an agreeable opinion across webdev.

explain "avoid merge commits"

Git doc says "Most projects avoid merge commits unless they are necessary." but doesn't explain how to do so. GitHub's merge button always generates a merge commit (https://github.com/blog/843-the-merge-button) so it would be helpful to explain how to merge pull requests without a merge commit. I think the process is like http://help.github.com/send-pull-requests/ but instead of

$ git fetch <remote>
$ git merge <remote>/<branch>

is it

$ git fetch <remote>
$ git pull --rebase <remote>/<branch>

?

Obviously I'm not the one to write the doc on it.