How to Contribute¶

Thank you for your interest in contributing to Mozillians! There are always bugs to file; bugs to fix in code; improvements to be made to the documentation; and more.

The below instructions are for software developers who want to work on Mozillians code.

Git workflow¶

When you want to start contributing, you should follow the installation instructions, then…

(Optional) Set your cloned fork to track upstream changes (changes to the main repository), then fetch and merge changes from the upstream branch:
```
$ git remote add --track master upstream git://github.com/mozilla/mozillians
$ git fetch upstream
$ git merge upstream/master
```
Set up a branch for a particular set of changes and switch to it:
```
$ git branch my_branch
$ git checkout my_branch
```
Commit changes to the code!
Code!
Lint the code:
```
$ flake8 mozillians
```
and fix any errors.
Run the tests:
```
$ ./manage.py test
```
and make sure that all tests pass.

Learn more about testing.
Commit changes to the code!
When you’re done, figure out how many commits you’ve made:
```
$ git log
```
Squash all those commits into a single commit that has a good git commit message. (Example assumes you made 4 commits):
```
$ git rebase -i HEAD~4
```

Use the interactive editor that pops up to pick/squash your commits:

pick 01d1239 [fix bug 893291] Make it go to 11
squash 32as32p added the library and made some minor changes
squash 30ame3z build the template
squash 91pcla8 ugh fix a semicolon bug in that last commit

Push your changes to your fork:
```
$ git push origin my_branch
```
Issue a pull request on GitHub
Wait to hear from one of the core developers

If you’re asked to change your commit message, you can amend the message and force commit:

$ git commit --amend
$ git push -f origin my_branch

If you need more Git expertise, a good resource is the Git book.

Templates¶

Mozillians.org uses Jinja templates, which are similar to Django templates but have some differences.

Some helpers are available in all Jinja templates in Mozillians.org.

display_context¶

Return a marked-up chunk of content containing the items in the template context, if settings.DEBUG is True. Otherwise returns an empty string.

By default, callables are omitted. Pass include_callables=True to include them.

The format of the result is:

<dl class="jinja-context">
  <dt>key</dt><dd>value</dd>
  <dt>key</dt><dd>value</dd>
  ...
</dl>

repr is applied to the values to format them.

Example usage:

{{ display_context() }}

{{ display_context(include_callables=True) }}

get_context¶

Provide access to the Jinja Context object in case you want to do more complicated things with it. Typically, display_context() is easier to use.

If settings.DEBUG is not True, returns an empty dictionary.

Example usage:

{% set context=get_context() %}
{% for k, v in context|dictsort %}
    {% if not is_callable(v) %}
        {{ k }}: {{ v }}<br/>
    {% endif %}
{% endfor %}

is_callable¶

Return True if thing is callable.

See get_context() for example usage.

Server architecture¶

Stage

URL: https://web-mozillians-staging.production.paas.mozilla.community/
Deploy: Manual (Chief)

Production

URL: http://www.mozillians.org/
Deploy: Manual (Chief)

You can check the currently deployed git commit by checking https://www.mozillians.org/media/revision.txt.

Pushing to production¶

In 2013 Mozillians code is released on Thursdays, after QA and developers agree that code is ready to push to production. The list of code scheduled for any particular release is here: https://wiki.mozilla.org/Mozillians#Releases

What to work on¶

Mozillians development follows a schedule and a roadmap managed by the Mozillians product and development team. Bugs that the team has committed to work on are generally given a target milestone and are assigned to a developer. Other bugs are fair game; but they’re not all aligned with the product’s current evolution. So if you are not familiar with the project and its roadmap, you may want to find one of the core team in IRC and ask before working on a particular bug.