Changes

Webmaker is a big project, and it can take some time to get set up and contributing. The following is a guide to our workflow, technologies, repositories, etc. Please read this documentation to help you get started, and ask follow-up questions on [irc://irc.mozilla.org/webmaker irc] or the [https://mail.mozilla.org/listinfo/webmaker-dev webmaker-dev list].

==1. Set up Getting a working Webmaker Development Environmentdevelopment environment==

Before you can test or make improvements to Webmaker, you is composed of a number of apps that work together. You'll need to get it running locally. This , which involves setting up your OS to host the Webmaker servers and apps, and installing various development tools you'll need. We strongly recommend a Unix-like OS, such as Linux or OS X, but it is also possible to use Windows.

Webmaker relies on ==2. Opening a number of technologies and toolsBugzilla account, which must first be installed. The following list needs to be installed and working before you can run or test Webmaker locally:understanding our bug-tracking system ==

* [http://nodejs.org node.js All the Webmaker work that has been done, and npm]* [http://bower.io/ bower]: after you install npmneeds to be done, you can type <code>npm install -g bower</code> (may require admin/sudo rights)* [http://gruntjs.com/ grunt]: after you install npm, type <code>npm install -g grunt-cli</code> (may require admin/sudo rights)* is tracked in an instance of [http://www.pythonbugzilla.org/ python 2.7Bugzilla]* located at [http://wwwbugzilla.pip-installermozilla.org/en/latest/installing.html pip]* [http://wwwbugzilla.mongodbmozilla.org/downloads MongoDB ] (NOTE: there is some discussion about dropping MongoDB altogether. This includes patches, but at the time of writingfeature updates, this hasn't happened yet)* [http://wwwerror & security fixes and documentation updates.oracleIdeally, it should include anything that can be thought of as a Webmaker-related task.com/technetwork/java/javase/downloads/index.html Java]* [http://www.elasticsearch.org Elastic Search]

A number of node "modules" (or libraries) that we use also require a working C/C++ toolchain. You should make sure that you have a working build environment for your OS (see the [https://github.com/mozilla/webmaker-suite#os-specific-information section of the Webmaker Suite docs] on this issue).  ===Setup Option 1: Webmaker Suite=== By far the easiest way to get all of Webmaker set up and installed locally, on any platform, is to use [https://github.com/mozilla/webmaker-suite Webmaker Suite]. This is a set of automation scripts written in node.js by one of our lead developers, and is meant to provide turn-key installation by automatically downloading all the code, and setting default environment variables. Note that this won't install external dependancies above automatically.  Complete instructions are available in the [https://github.com/mozilla/webmaker-suite#webmaker-suite-bootstrapinstallation-script README for Webmaker Suite] on github. ===Setup Option 2: Local Native Installation===Each server that makes up a part of the Webmaker.org ecosystem is configured with <code>.env</code> or ''environment'' files. The servers come with a sample version of this file that is fully functional, assuming that the sample files are used for all the servers in the local installation. Instructions on configuring these manually can be found in the Github repository of each server.  ==== Setting up your dev environment in Mac OS X ==== This is the easiest method of setting up a Webmaker dev environment in Mac OS X, but requires the use of the [http://brew.sh/ Homebrew] package manager.  # Install [https://developer.apple.com/xcode/ Xcode] command line tools by running <code>xcode-select --install</code> from the terminal# Install the [http://brew.sh/ Homebrew] package manager by following the instructions at their website.# Run <code>brew doctor</code> to complete Homebrew's installation# Install NodeJs with <code>brew install node</code># Install the [http://www.oracle.com/technetwork/java/javase/downloads/index.html JDK (Java Development Kit)] from their website# Install elasticsearch with <code>brew install elasticsearch</code># Install mongodb with <code>brew install mongodb</code> ==== Setting up your dev environment in Ubuntu Linux ====This is the easiest way to setup a Webmaker dev environment on Ubuntu Linux, but requires that NodeJS be compiled from source. # Install git and a C/C++ toolchain with <code>sudo apt-get -y -q install git g++</code># Install the Java Development Kit with <code>sudo apt-get -y -q install openjdk-7-jre-headless</code># Install the MongoDB server## Install the package with <code>sudo apt-get -y -q install mongodb-server</code>## Ensure MongoDB is running with <code>service mongodb status</code>## Otherwise, start MongoDB with <code>sudo service mongodb start</code> # Install Elasticsearch ## Download [http://www.elasticsearch.org/download/ Elasticsearch] as a <code>.deb</code> file and install from the software centre## Ensure Elasticsearch has started with <code>service elasticsearch status</code>## Otherwise, start Elasticsearch with <code>sudo service elasticsearch start</code># Install Nodejs from source## Clone Node using <code>git clone git://github.com/ry/node.git`</code>## Navigate Understanding how to the new directory with <code>cd node</code>## Checkout the latest stable version of Nodejs (currently v0.10.22) with <code>git checkout v0.10.22</code>## Run <code>./configure</code>## Run <code>make > output.txt</code>## Run <code>sudo make install > output.txt</code> ==== Set up NodeJS dependancies ====Once your Development environment is set up, you must install some global NPM packages. # Install [http://bower.io/ bower] with <code>sudo npm install -g bower</code># Install [http://gruntjs.com/ grunt] with <code>sudo npm install -g grunt</code> ==== Installing Webmaker Core ====Webmaker's core apps are the ''Login'', ''MakeAPI'' and ''Webmaker.org'' servers. These three must be run together in order to function properly with each other, and the other apps that make up Webmaker. You can find installation instructions in the <code>readme</code> file in each server's Github repository: * '''Login''' - [https://github.com/mozilla/login.webmaker.org/blob/master/README.md https://github.com/mozilla/login.webmaker.org/blob/master/README.md]* '''MakeAPI''' - [https://github.com/mozilla/MakeAPI/blob/master/README.md https://github.com/mozilla/MakeAPI/blob/master/README.md]* '''Webmaker.org''' - [https://github.com/mozilla/webmaker.org/blob/master/README.md https://github.com/mozilla/webmaker.org/blob/master/README.md] ==== Installing Webmaker Tools ====Webmaker's tools (''Thimble'', ''Goggles'' and ''Popcorn Maker'') follow similar procedures for installation and configuration. Keep in mind that they won't function properly without the '''Webmaker Core''' services running. You can find installation instructions in the <code>readme</code> file in each server's Github repository: * '''Popcorn Maker''' - [https://github.com/mozilla/popcorn.webmaker.org/blob/master/README.md https://github.com/mozilla/popcorn.webmaker.org/blob/master/README.md]* '''Thimble''' - [https://github.com/mozilla/thimble.webmaker.org/blob/master/README.md https://github.com/mozilla/thimble.webmaker.org/blob/master/README.md]* '''Goggles''' - [https://github.com/mozilla/goggles.webmaker.org/blob/master/README.md https://github.com/mozilla/goggles.webmaker.org/blob/master/README.md] ==== Staying Up-bugs to-date ====As we improve features (day-to-day), we release them into the wild almost immediately! For this reason, it's important to keep your servers running the latest code. These commands will use <code>git</code> to pull the latest updates from the Mozilla repo, and then reinstall the node ''modules'' (or libraries). If you followed each server's installation instructions exactly, <code>[mozilla upstream remote]</code> should be replaced with <code>origin</code>. Otherwise, replace it with whatever you labeled the Mozilla [http://git-scm.com/book/en/Git-Basics-Working-with-Remotes remote].  * Dirty update (try this first): <code>git checkout master && git pull [mozilla upstream remote] master && npm install</code>* Clean update (time intensive) <code>git checkout master && git pull [mozilla upstream remote] master && rm -rf node_modules && npm cache clear && npm install</code> ===Setup Option 3: Using Vagrant (i.e., Ubuntu-based VM)=== TODO ===Setup Option 4: Heroku=== TODO ==2. Find or File a Webmaker Bug== All the work we do is tracked in Bugzillaon, and knowing how to find exiting file bugs , and how to file new bugs is important. ===Why use Bugzilla?=== This question comes up sometimes, and it's worth understanding our reasons for choosing Bugzilla over Github Issues or some other tool--we have gone through a long process of discussing and exploring other options, and Bugzilla is what works best for our use case. Webmaker isn't developed as a single code-base. This is partly due to historic reasons (i.e., Webmaker was assembled out of different, existing projects) and partly due to our deployment needs (i.e., needing to be able to scale parts of Webmaker differently in production). Webmaker record your progress is also larger than the sum of its code, and encompasses a large teaching, mentoring, and event-based community, all of which is tied into the development of the tools and apps. As a result of the highly distributed yet interconnected nature of the Webmaker code, taking a per-repository view of of the issues/bugs has proven difficult. First, a bug might touch multiple parts of the product, and need to be spread across many repositories--it's not uncommon for a single bug to touch 5 or 6 different repositories. Second, often a bug that appears to belong to a tool like Thimble actually needs to get filed and fixed in a repository that isn't named Thimble at all, and users vital (and many developers not familiar with the coderequired) can't find their way through all the Webmaker repositories. We have taken a philosophy that favours users and bug-fillers over developers, and one which tries to provide a wide net for collecting feedbackcontributing. People filing Webmaker bugs, unless they are on the development team, typically don't know our code or where bugs belong. If a bug gets filed in Github Issues, it's not possible to move it to another repository. In Bugzilla this is trivial, and it means that we can triage bug reports, CC the right people, and get our work done faster across For all of Webmaker. We also favour an approach that allows us to lump bugs about code, content, and community activities into a single bucket, since Webmaker is more than just HTML, CSS, and JavaScript. Another advantage to using the Mozilla's Bugzilla has been the opportunity to interface with other areas of Mozilla. A good example is the Security Team, who routinely helps us with security-critical bugs. In Bugzilla one can flag these such that they aren't open to the public, and therefore don't document exploits. This isn't (currently) possible in Github. When it comes to issue trackers, there is no silver bullet, and it's impossible to please everyone. By using both Github and Bugzilla, the former for pull requests and code review, and the latter for global projecct issue tracking, we think we've struck the right balance. ===Using Bugzilla=== If you haven't used Bugzilla before, information you need to create an account. A good first guide smoothly transition into this mindset, make sure to Bugzilla for Webmaker users is available here: http://blog.webmaker.org/bugzilla. You should also watch [http://blog.johnath.com/2010/02/04/bugzilla-for-humans/ Bugzilla for Humans], and read [http://blog.margaretleibovic.com/post/36893756730/bugzilla-101 this post]. There are many good resources on learning Bugzilla. Bugzilla is organized into '''Products''', which in turn have '''Components'''. All Webmaker bugs live under the through our [https://bugzillawiki.mozilla.org/page.cgi?id=productdashboard.html&product=Webmaker '''Webmaker''' product], and in one of its components (see the [https:/Code/bugzilla.mozilla.orgDev/describecomponents.cgi?product=Webmaker complete list and description of eachBugs Bug Guide]). Developers often watch particular components, which means an email will be sent for all bugs filed or updated in that component. New bugs can be filed here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Webmaker. There are many bugs across all Webmaker components. You can see all open bugs for [https://bugzilla.mozilla.org/buglist.cgi?product=Webmaker&bug_status=__open__&component=webmaker.org webmaker.org], [https://bugzilla.mozilla.org/buglist.cgi?product=Webmaker&bug_status=__open__&component=Popcorn%20Maker Popcorn Maker], [https://bugzilla.mozilla.org/buglist.cgi?product=Webmaker&bug_status=__open__&component=Thimble Thimble], [https://bugzilla.mozilla.org/buglist.cgi?product=Webmaker&bug_status=__open__&component=X-Ray%20Goggles X-Ray Goggles], [https://bugzilla.mozilla.org/buglist.cgi?product=Webmaker&bug_status=__open__&component=MakeAPI Make API], etc. or you can see [https://bugzilla.mozilla.org/buglist.cgi?product=Webmaker&bug_status=__open__ all open Webmaker bugs]. Here are '''NEW''' (i.e., bugs not yet assigned to anyone) that need someone to look into: <bugzilla>{"product": "webmaker","include_fields": "id, component, summary, status, assigned_to","maxrows":"50","status":"NEW","order": "bug_id"}</bugzilla> TODO:* good-first-bug flags?

The Webmaker code is spread across a large number of repositories, modules, libraries, apps, and web sites. Trying appearing to locate the code for a particular part of Webmaker can be a challenge. The following is a high level introduction to the code. ===Technical Overview of Webmaker=== Users typically begin at https://webmaker.orgsingle, and so our discussion will start there too. The webmaker.org site has four main features, including: # allowing users to access Webmaker tools, including '''Popcorn Maker''', '''Thimble''', and '''X-Ray Goggles'''. # allowing users to search for and browse various "makes," which are objects in the '''Make API''' made with one of the Webmaker tools, or by a third-party complex web tool.# allowing users to create or find Webmaker Events, using a Google Maps driven sub-application often referred to as '''Webmaker Events''' or just '''Events'''.# allowing users to create a Webmaker (and by extension, Persona) account. Beginning with account creation, webmaker.org (and other tools via the common navigation header) connects to the Login server (i.e., login.webmaker.org). Webmaker uses [http://www.mozilla.org/en-US/persona/ Mozilla Persona] for user authentication and sign-in. Additional code has been written on top of Persona to allow single-sign-on across all Webmaker tools and sites (e.g., [https://github.com/jbuck/node-webmaker-sso webmaker-sso]). When a new Webmaker account is created, the Persona email is stored, along with extra information about the user (e.g., name, email notification preferences, etc.). The username is also used to create a new (virtual) domain on '''makes.org''' (or '''mywebmaker.org''' in our staging environment). For example, user donald would get donald.makes.org. All published makes for this user (i.e., things created with Webmaker tools) will be available at ''username''.makes.org/''something''. The choice to use makes.org for hosting user content was done in order to provide origin-isolation from our Webmaker apps and code, which lives on webmaker.org (or mofostaging.net in our staging environment). The ''username''.makes.org page is actually the '''Webmaker Profile''' app. Here all the user's makes are displayed, along with various widgets for creating new UI components in the profile. The Profile app, like webmaker.org, uses the '''Make API''' and '''Login''' servers in order to find all the makes for a particular user--in fact most Webmaker apps work this way. Communication between the Make API, Login server, and other node apps happens over HTTP APIs within in the production (or staging) deployment network. Users create "makes" using Webmaker tools. All tools allow authenticated Webmaker users (i.e., must have account in the Login server) to publish what they make. Publishing means made of a number of things. First, user generated content from the tools (e.g., HTML) is saved to an [http://aws.amazon.com/s3/ Amazon S3 bucket]. A unique URL is also created, such smaller apps that users can access their content again via their makes.org domain. The '''Make Valet''' app provides the routing and logic work together to map a URL to the content in S3, and common UI for details about a make (i.e., metadata from the Make API)perform those complex functions. Second, publishing means inserting a record To really dig into the Make API, which includes metadata about the make, like URL, date info, which tool was used, tags, etc. The Make API indexes makes using [http://www.elasticsearch.org/ Elastic Search] so work that they can be found again easily. Each of the Webmaker tools is a complex thing in its own right. Popcorn Maker publishes embeddable web pages, which are meant to be included via iframes. Thimble allows arbitrary HTML, CSS, and JavaScript to be combined into a single page. X-Ray Goggles allows the live DOM of a web page to be altered and then re-serialized to HTML so it can be published. All of the tools use the Login server for user authentication, S3 for publishing (each app does this step on its own, and in slightly different ways), and the Make API for indexing and metadata storage. Where possible common libraries and modules have been written and are shared across the tools, apps, and servers. ===A Tour of Webmaker Code=== For the most part, Webmaker code lives in one of many repositories hosted under the [https://github.com/mozilla Mozilla Github Organization]. We also contribute to a number of upstream projects, not all of which are listed below (e.g., node.js modules or libraries we use, but don't maintain directly). There are a few exceptions, but we try to graduate repositories we rely on to the Mozilla Organization instead of hosting them under individual github accounts. For more information about any of these repositoriesre doing together, you are encouraged to consult each their READMEs. * '''[https://webmaker.org Webmaker.org]''': https://github.com/mozilla/webmaker.org - the node.js app and front-end code for https://webmaker.org, including things like Events and the Web Literacy Standard. * '''[https://thimble.webmaker.org Thimble]''': a friendly real-time updating code editor, includes:** thimble.webmaker.org: https://github.com/mozilla/thimble.webmaker.org - the node.js app and main/shell front-end code.** friendlycode: https://github.com/mozilla/friendlycode/ - the code editor used by Thimble** slowparse: https://github.com/mozilla/slowparse - an HTML5 parser with extra metadata and error handling** togetherjs: https://github.com/mozilla/togetherjs/ - TogetherJS real-time collaboration library * '''[https://popcorn.webmaker.org Popcorn Maker]''': ll need a web-based media editing tool, includes:** popcorn.webmaker.org: https://github.com/mozilla/popcorn.webmaker.org - the node.js app and front-end for Popcorn Maker** popcorn.js: https://github.com/mozilla/popcorn-js - the Popcorn.js HTML5 media library** mediasync: https://github.com/mozilla/webmaker-mediasync - sync/query services for media APIs * '''[https://goggles.webmaker.org X-Ray Goggles]''': https://github.com/mozilla/goggles.webmaker.org - the node.js app and front-end bookmarklet code for X-Ray Goggles, a tool for visually exploring and changing the underlying structure grasp of web pages * '''Login (aka [https://login.webmaker.org login.webmaker.org])''': https://github.com/mozilla/login.webmaker.org - node.js single-sign-on (SSO) server and identity provider for Webmaker apps, as well as front-end UI components for authentication, based on [https://developer.mozilla.org/en-US/Persona?redirectlocale=en-US&redirectslug=Persona Mozilla's Persona] * '''[https://makeapi.webmaker.org MakeAPI]''': https://github.com/mozilla/makeapi - node.js metadata server for storing and indexing information about "makes" (e.g., things made on the web with Webmaker tools or 3rd party tools).  * '''Make Valet''': https://github.com/mozilla/make-valet - node.js app for hosting information about makes (e.g., Make Details). * '''Webmaker Profile''': https://github.com/mozilla/webmaker-profile - node.js app and front-end for ''username''.makes.org profile pages, includes:** webmaker-profile-service: https://github.com/mozilla/webmaker-profile-service - RESTful API for profile * Common Node/JS Modules used by many Webmaker apps and code:** webmaker-sso: https://github.com/jbuck/node-webmaker-sso - Single-Sign-On solution for Persona** makeapi-client: https://github.com/mozilla/makeapi-client - node.js and browser-js client lib for communicating with the MakeAPI** webmaker-i18n: https://github.com/mozilla/node-webmaker-i18n - Localization and Internationalization code for node.js and HTML.** webmaker-loginapi: https://github.com/mozilla/node-webmaker-loginapi - client lib for accessing Login server from node.js** webmaker-postalservice: https://github.com/mozilla/node-webmaker-postalservice - Webmaker mailer for apps requiring email services** mox-server: https://github.com/Pomax/mox-server - mock implementation of the Amazon S3 service in node. ===Webmaker Style Guide=== Anyone working on Webmaker's front-end, or otherwise altering aspects of user-facing UI/UX should be aware of the [https://wiki.mozilla.org/Webmaker/styleguide Webmaker Style Guide]. The Style Guide provides important information about Webmaker's design philosophy and branding, typography, logos, colours, thumbnails, etc. For Webmaker Logos and other branding marks, see http://www.mozilla.org/en-US/styleguide/identity/webmaker/branding/ ===Localization (l10n)=== Webmaker is a global product, focused as much on non-English speakers as English, and used around the world. We have localized how our apps and tools using technology works at a mix of serverhigh-side and client-side localization. The details about how we do this is available in the [https://github.com/humphd/node-webmaker-i18n Webmaker I18N README]. If you are interested in localizing Webmaker, you can join the [https://www.transifex.com/projects/p/webmaker/ Webmaker Transifex project], more details are available in [https://support.mozilla.org/en-US/kb/translate-webmaker this SUMO article]level.

Even if you donNervous? Don't plan to translate strings, you'll probably have to make yourself aware be! Get a simple explanation of how localization Webmaker works, since any change to code that touches the front-end or UI will likely trigger an l10n changein our [https://wiki.mozilla. See the workflow section for more detailsorg/Webmaker/Code/Dev/Tech Technology Guide].

Every project has its own way of working, and we're no exception. This guide will help you navigate our development workflow so you can be successful as a new contributor. ===1. Get a bug Filed and Assigned to you=== Fixing bugs or adding new features begins in Bugzilla. Whatever you are going to work on, you need to have a bug. Bugs in Bugzilla don't just mean something is broken. A bug is a unit of work, and that might mean fixing a problem in code, but could also mean adding something new, configuring a system differently, setting up an account for someone, etc. If there isn't a bug filed for the work you'll be doing, you should [https://bugzilla.mozilla.org/enter_bug.cgi?product=Webmaker file a new one]. If you're not sure which component it belongs in, you can use '''General''', and someone will help you move it to the right place. Once a bug exists, you need to get it assigned to you. This is important because it lets other people in the community know that someone is already working on this. When you create a new Bugzilla account, you won't have privileges yet to assign bugs to yourself. However, if you ask on irc or the the webmaker-dev list, someone will gladly help you out. ===2. Fix the bug and create Development follows a Pull Request=== All Webmaker code is in github. You'll need intermediate level understanding set of git and github to work on Webmaker, and if you ever get stuck, make sure you ask for help. There are also many good resources online for learning more about git, for example the [http://progit.org/book/ Pro Git, online book].  A typical workflow looks like this: # Fork the appropriate repo into your own github account# Clone your fork locally: <code>git clone --recursive {url to your github repo}</code>. NOTE: many Webmaker repos have submodules, so it's wise to clone recursively.# Add Mozilla's repo as an upstream remote, so you can stay in sync: <code>git remote add upstream {url to Mozilla's github repo}</code>. NOTE: you can call it anything you like, but '''upstream''' is a common convention.# Create a new branch off master, using the bug number as the name: <code>git checkout -b bug12345</code># Work on the code, committing as you go. Don't worry about keeping your branch's commit log tidy, since we [http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html rebase and squash] before merging into master.# When you're at a point where you'd like feedback or review (see below for more details), push your branch up to your forked repo: <code>git push origin bug12345</code># Create a [https://help.github.com/articles/creating-a-pull-request Pull Request] in github from your bug12345 branch to Mozilla's master branch.# Copy the URL for your pull request, for example: https://github.com/mozilla/webmaker.org/pull/420# Go back to Bugzilla, and your bug, and '''Add an attachment'''. You will be given the option to "'''Enter the path to the file on your computer (or paste text as attachment)'''", and since we don't have a file, click '''paste text as attachment'''. Now paste your pull request URL into the textbox.# For the attachment's '''Description''', once again paste the pull request URL.# Under '''Flags''' you have a number of options. If your code is ready for review, you can select '''?''' in the drop-down beside '''review''' and then enter the name of the person (i.e., bugzilla email address) procedures that you'd like to look at this code. If it's not ready for review, but you would like feedback, you can do the same thing with '''feedback'''. See the section on code review for more details # Click '''Submit''' and wait for your reviewer to carry out the review. ===3. Get your code Reviewed=== Code review is a [http://vocamus.net/dave/?p=1569 critical component of the Mozilla project]. Code review increases code quality, distributes knowledge of changes across a team, allows for mentorship of new developers, etc. All changes in Webmaker need review, from a single line change to a 5,000 line feature addition. There are no exceptions, and no one is "good enough" to skip having their code reviewed. In order to get your code reviewed, you first need to find an appropriate reviewer. There are a few strategies. The first is to ask in the bug, on irc, or the dev list. The second is to look at <code>git blame {filename}</code> information, which will show you who touched the code you're working in last, and often who did the review (e.g., the commit message or bug that changed it will have that info). Your reviewer will use a mixture of inline Github code comments and comments in the Bugzilla bug. Generally speaking, issues relating to the code itself will go in Github, and general comments in Bugzilla. As your code is being reviewed, you will likely be asked designed to make fixes. This will include fixing errors, adding comments, adhering to prevailing styles, etc. Here is how you do it: # Go back to your bug fix branch: <code>git checkout bug12345</code># Make your changes, commit, and push to your remote repo. The existing pull request will get updated.# If your reviewer has given you an '''r-''', you may need to ask for review again. You can do this by clicking '''Details''' beside your attachment in Bugzilla, then resetting the '''review''' flag to '''?''' from '''-'''. Don't update your branch to the latest code in Mozilla's master branch yet--we'll do that when it's ready to land and we rebase (see below). Don't be discouraged when this process takes multiple tries. All developers make mistakes, or lack knowledge kind of the entire project sufficient to catch issues outside the particular code in question. It's common for a bug to take many updates before the code is ready to get checked in (aka.asynchronous, ''landed''). When it's time to land your code, your reviewer will likely ask you to '''rebase'''. It is highly recommended that you ask for help your first time, unless you have experience doing this, as it will alter your branch's commit history. We prefer rebase over merge so that our repositories have clean, singleoften long-change master branchesdistance, which makes reverting and bisecting much collaboration easier. A rebase generally goes like this: # Switch to your master branch and pull the latest changes from Mozilla: <code>git checkout master && git pull upstream master</code># Switch back to your bug branch: <code>git checkout bug12345</code># Do a rebase, and ideally an interactive rebase so you can squash and fix your commit message: <code>git rebase master -i</code>. Now your editor will open and you can squash or fixup your separate commits, and redo your original commit message if you don't like it. A common commit message form is: '''Fix Bug 12345: Details about this bug r=person_who_did_review'''.# Once the rebase is finished, and any conflicts dealt with, push your branch back up to github. You'll need to use the '''-f''' flag while maintaining quality in order to force github to take it, since your history has now changed: <code>git push origin bug12345 -f</code> At this point you can ask your reviewer to land your changes, either via irc, or in a comment in the bug. TODO: document whiteboard flags* l10n changes* sumo or other doc changes* other? ===4our work. Verify your code on Staging=== TODO* tagging* pushing to staging/production

<center>httpThe entire process is well documented in our [https://farm8wiki.staticflickrmozilla.comorg/7340Webmaker/9337213776_d77d88eb89.jpg<Code/Dev/center>Workflow Workflow Guide]