dojo · jacobroufa · Dec 7, 2016 · Dec 8, 2016
diff --git a/developer/bugs.rst b/developer/bugs.rst
@@ -16,7 +16,7 @@ These are some notes about the conventions we use when filing, closing, updating
 Logging In
 ==========
 
-The `bug tracker <http://bugs.dojotoolkit.org>`_ uses the LDAP information from the overall `Dojo Foundation <http://dojofoundation.org>`_. `Register for a Dojo Foundation account <http://my.dojofoundation.org>`_ and login to Trac via the auth dialog using those credentials. **note** this username/password combination will work on all Dojo Sites, eg: http://livedocs.dojotoolkit.org
+The `bug tracker <http://bugs.dojotoolkit.org>`_ uses the LDAP information from the overall Dojo projects account. `Register for a Dojo projects account <http://my.dojofoundation.org>`_ and login to Trac via the auth dialog using those credentials. **note** this username/password combination will work on all Dojo Sites, eg: http://livedocs.dojotoolkit.org
 
 Getting Notified
 ================

diff --git a/developer/github.rst b/developer/github.rst
@@ -23,9 +23,13 @@ The main GitHub Repositories for the Dojo 1.X code are:
 
 * `dojo/util <https://github.com/dojo/util>`_
 
-You will need a valid GitHub user account.  This should be tied to your Dojo Foundation user account and you should have
+You will need a valid GitHub user account.  This should be tied to your Dojo projects user account and you should have
 appropriate access to the Dojo Toolkit repositories.  This can be done by contacting one of the Toolkit project leads.
 
+You will need to have signed the `JS Foundation's CLA <http://js.foundation/CLA>`_. If your GitHub user id you are
+submitting your pull request from differs from the e-mail address which you have signed your CLA under, you should
+specifically note what you have your CLA filed under.
+
 You will need the appropriate tools to manage your GitHub code.  There are a few choices, but the two main ones are the
 standard ``git`` command line or the GitHub GUI:
 

diff --git a/developer/index.rst b/developer/index.rst
@@ -11,8 +11,6 @@ This section contains links to information useful to contributors or committers
 
 * :ref:`Style guide <developer/styleguide>` and :ref:`Dojo Inline Documentation Format <developer/markup>`
 
-* :ref:`Contributor list <developer/contributors>` - list of people that have signed the `CLA form <http://dojofoundation.org/cla/>`_ to contribute to Dojo
-
 * :ref:`Rules and Responsibilities for Dojo Committers <developer/rules>`
 
 * :ref:`Source control access <developer/svn>`

diff --git a/developer/release.rst b/developer/release.rst
@@ -20,7 +20,7 @@ Creating a Dojo Release/RC/Beta
 
    ``-b <branch>`` is the branch to use as the source for the release (e.g. 1.7). If unspecified, the master branch will be used
 
-   ``-u <username>`` is your Dojo Foundation username. If unspecified, auto-loading to the downloads server will be unavailable
+   ``-u <username>`` is your Dojo projects username. If unspecified, auto-loading to the downloads server will be unavailable
 
    ``<version>`` is the version number for the new release (e.g. 1.7.1rc1)
 

diff --git a/developer/rules.rst b/developer/rules.rst
@@ -13,15 +13,15 @@ Before you say "yes", there are some things you should know.
 
 Process
 =======
-**IP policy**: as you know, Dojo is one of the few OSS JavaScript projects which uses a CLA process to ensure that contributions to the toolkit are "clean" from an IP perspective. The policies which we follow are outlined in the IP policies (TODO: add link) and as a committer you are expected to help us observe them. Long story short, if you didn't write it or are unsure of the CLA status of the contribution, don't commit it. The list of people and companies with CLAs on file :ref:`is public <developer/contributors>`, so be sure to consult it when in doubt. Artwork can be particularly problematic from an IP cleanliness perspective, and difficult to judge. There are also times when integrating some chunk of code which you find out on the net somewhere seems a reasonable thing to do. In each of these cases, it's best to ask the Project Lead for guidance.
+**IP policy**: as you know, Dojo is one of the few OSS JavaScript projects which uses a CLA process to ensure that contributions to the toolkit are "clean" from an IP perspective. The policies which we follow are outlined in the IP policies (TODO: add link) and as a committer you are expected to help us observe them. Long story short, if you didn't write it or are unsure of the CLA status of the contribution, don't commit it. Artwork can be particularly problematic from an IP cleanliness perspective, and difficult to judge. There are also times when integrating some chunk of code which you find out on the net somewhere seems a reasonable thing to do. In each of these cases, it's best to ask the Project Lead for guidance.
 
 **Quality**: committers are expected to observe the :ref:`style guidelines for code <developer/styleguide>`, consult with the :ref:`accessibility requirements <developer/a11y-requirements>` when making visual and interaction changes, provide :ref:`unit tests <util/dohrobot>`, and write :ref:`inline documentation <developer/markup>` for the code they touch. As a contributor all of these things were also expected, but now it becomes your responsibility as a committer to ensure that your checkins meet the high standards of the project, even when you're merging patches that others might be contributing.
 
 **Getting Along**: most decisions in the project arise out of consensus in one way or another. When things are contentious, we try to find data, common ground, or expert opinions to settle things. Despite this, decisions get made which not everyone agrees with, and as a result it's possible for tensions to flare. You've been offered a spot as a committer in part because you've demonstrated that you work well with others to resolve issues, find data to support arguments or theories, and avoid personal attacks when disagreeing. These are important traits for a distributed project and we expect that you'll work to embody them. Remember: the person on the other end of The Tubes is, like you, trying to make things better.
 
 Community
 =========
-**Voting**: As a committer on Dojo you will have a vote in both project-level and Foundation-level issues. Every project at the Dojo Foundation is potentially run differently, but most have some sort of "Benevolent Dictator For Live" or "Project Lead" who sets the agenda. Dojo as a project is organized in this style, but most decision making is made by consensus. That said, voting is part of the Dojo culture and your participation as a committer is required.
+**Voting**: As a committer on Dojo you will have a vote in both project-level and Foundation-level issues. Every project at the JS Foundation is potentially run differently, but most have some sort of "Benevolent Dictator For Live" or "Project Lead" who sets the agenda. Dojo as a project is organized in this style, but most decision making is made by consensus. That said, voting is part of the Dojo culture and your participation as a committer is required.
 
 Any committer can start a vote on matters relating to Dojo (the project) or the Foundation as a whole at any time.
 Only committers on Dojo itself may vote in project-level issues.

diff --git a/dijit/Dialog.rst b/dijit/Dialog.rst
@@ -322,7 +322,7 @@ This example shows a Dialog that will ask the user to accept or decline the term
             <h1>Agreement Terms</h1>
 
             <div style="width:400px; border:1px solid #b7b7b7; background:#fff; padding:8px; margin:0 auto; height:150px; overflow:auto;">
-                Dojo is available under *either* the terms of the modified BSD license *or* the Academic Free License version 2.1. As a recipient of Dojo, you may choose which license to receive this code under (except as noted in per-module LICENSE files). Some modules may not be the copyright of the Dojo Foundation. These modules contain explicit declarations of copyright in both the LICENSE files in the directories in which they reside and in the code itself. No external contributions are allowed under licenses which are fundamentally incompatible with the AFL or BSD licenses that Dojo is distributed under. The text of the AFL and BSD licenses is reproduced below. ------------------------------------------------------------------------------- The "New" BSD License: ********************** Copyright (c) 2005-2010, The Dojo Foundation All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
+                Dojo is available under *either* the terms of the modified BSD license *or* the Academic Free License version 2.1. As a recipient of Dojo, you may choose which license to receive this code under (except as noted in per-module LICENSE files). Some modules may not be the copyright of the JS Foundation. These modules contain explicit declarations of copyright in both the LICENSE files in the directories in which they reside and in the code itself. No external contributions are allowed under licenses which are fundamentally incompatible with the AFL or BSD licenses that Dojo is distributed under. The text of the AFL and BSD licenses is reproduced below. ------------------------------------------------------------------------------- The "New" BSD License: ********************** Copyright (c) 2005-2010, The JS Foundation All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
             </div>
 
             <br />

diff --git a/index.rst b/index.rst
@@ -11,8 +11,8 @@ Welcome
 =======
 
 The Dojo Toolkit Reference Guide is designed to be an in-depth resource regarding the Dojo Toolkit. The Reference Guide
-is a community effort and can be contributed to by anyone who has a `CLA <http://dojofoundation.org/about/cla>`_ in
-place with the Dojo Foundation.
+is a community effort and can be contributed to by anyone who has a `CLA <http://js.foundation/CLA>`_ in
+place with the JS Foundation.
 
 If you are looking for an introduction to the Dojo Toolkit, it is better to utilize the 
 `tutorials <http://dojotoolkit.org/documentation>`_, and then use this reference guide.  If you are looking for 
@@ -56,4 +56,4 @@ information:
   related transition notes.
 
 * :ref:`Developer Notes <developer/index>` - Several documents that are used to document Dojo contributor and committer
-  guidelines.
+  guidelines.
diff --git a/quickstart/introduction/history.rst b/quickstart/introduction/history.rst
@@ -6,4 +6,4 @@ A Brief History of Dojo
 
 In early 2004 Alex Russell (original creator of netWindows) began looking to hire a collaborator on DHTML projects at Informatica. In the process many members of the DHTML community were contacted, culminating in the April 25, 2004 email titled "Selling the future of DHTML". David Schontzler (Stilleye) spent a summer working at Informatica, and Dylan Schiemann also joined Informatica at that time. The first lines of code contributed to Dojo were done by Alex and Dylan with the support of Informatica. There were many other community members that were active participants in shaping the direction of Dojo, including Joyce Park, Tom Trenka, Mark Anderson, Leonard Lin (who suggested the name Dojo), Aaron Boodman, Simon Willison, Cal Henderson, and Dan Pupius.
 
-After several months of discussions on the ng-dhtml (now dojo-developer) mailing list about licensing, choosing a name, coding conventions, build tools, server configuration, and requirements, work began and the Dojo Foundation was formed. The foundation is a 501(c)6 entity designed to house the code and IP rights and today hosts several other projects as well. By March 2005 contributions from the community began to outweigh those of the core development team and today 8 major releases have been made with over 1 million downloads of Dojo to date. Contributions and code have come from more than 60 developers and companies and major users such as IBM, AOL, Sun, SitePen, Bloglines, Google, Nexaweb and others continue to keep Dojo's quality high and the community vibrant.
+After several months of discussions on the ng-dhtml (now dojo-developer) mailing list about licensing, choosing a name, coding conventions, build tools, server configuration, and requirements, work began and the Dojo Foundation (now merged into the JS Foundation) was formed. The foundation is a 501(c)6 entity designed to house the code and IP rights and today hosts several other projects as well. By March 2005 contributions from the community began to outweigh those of the core development team and today 8 major releases have been made with over 1 million downloads of Dojo to date. Contributions and code have come from more than 60 developers and companies and major users such as IBM, AOL, Sun, SitePen, Bloglines, Google, Nexaweb and others continue to keep Dojo's quality high and the community vibrant.