Merge pull request #6283 from AnalyticalGraphicsInc/now-cesiumjs

Rename Cesium to CesiumJS

CONTRIBUTING.md

@@ -1,4 +1,4 @@
-Thanks for contributing to Cesium.  You rock!  Are you
+Thanks for contributing to CesiumJS.  You rock!  Are you
 
 * [submitting an issue](#submitting-an-issue),
 * [getting started contributing](#getting-started-contributing), or
@@ -10,7 +10,7 @@ To ensure an inclusive community, contributors and users in the Cesium community
 
 If you have a question, do not submit an issue; instead, search the [Cesium forum](http://cesiumjs.org/forum.html).  The forum is very active and there are years of informative archives, often with answers from the core Cesium team.  If you do not find an answer to your question, start a new thread and you'll likely get a quick response.
 
-If you think you've found a bug in Cesium, first search the [issues](https://github.com/AnalyticalGraphicsInc/cesium/issues).  If an issue already exists, please add a comment expressing your interest and any additional information.  This helps us prioritize issues.
+If you think you've found a bug in CesiumJS, first search the [issues](https://github.com/AnalyticalGraphicsInc/cesium/issues).  If an issue already exists, please add a comment expressing your interest and any additional information.  This helps us prioritize issues.
 
 If a related issue does not exist, submit a new one.  Please be concise and include as much of the following information as is relevant:
 * Minimum amount of sample code (and data) shared through [Sandcastle](http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Hello%20World.html&label=Showcases) using a [GitHub gist](http://cesiumjs.org/2016/04/14/Share-Sandcastle-Examples-Easily-with-GitHub-Gists/).
@@ -22,9 +22,9 @@ If a related issue does not exist, submit a new one.  Please be concise and incl
 
 # Getting Started Contributing
 
-Everyone is welcome to contribute to Cesium!
+Everyone is welcome to contribute to CesiumJS!
 
-In addition to contributing core Cesium code, we appreciate many types of contributions:
+In addition to contributing core CesiumJS code, we appreciate many types of contributions:
 
 * Being active on the [Cesium forum](http://cesiumjs.org/forum.html) by answering questions and providing input on Cesium's direction.
 * Showcasing your Cesium apps on the [demos page](http://cesiumjs.org/demos.html) or writing a guest post blog on the [Cesium blog](http://cesiumjs.org/blog.html).  To do either, contact [Sarah Chow](http://cesiumjs.org/team/SarahChow.html), [email protected].
@@ -33,7 +33,7 @@ In addition to contributing core Cesium code, we appreciate many types of contri
 * Triaging issues.  Browse the [issues](https://github.com/AnalyticalGraphicsInc/cesium/issues) and comment on issues that are no longer reproducible or on issues which you have additional information.
 * Creating ecosystem projects for [glTF](https://github.com/KhronosGroup/glTF/issues/456), [CZML](https://github.com/AnalyticalGraphicsInc/cesium/wiki/CZML-Guide), and [3D Tiles](https://github.com/AnalyticalGraphicsInc/3d-tiles).
 
-For ideas for Cesium code contributions, see:
+For ideas for CesiumJS code contributions, see:
 
 * issues labeled [beginner](https://github.com/AnalyticalGraphicsInc/cesium/labels/beginner) and
 * issues labeled [roadmap](https://github.com/AnalyticalGraphicsInc/cesium/labels/roadmap).
@@ -55,26 +55,27 @@ Before we can merge a pull request, we require a signed Contributor License Agre
 * [individuals](Documentation/Contributors/CLAs/individual-cla-agi-v1.0.txt) and
 * [corporations](Documentation/Contributors/CLAs/corporate-cla-agi-v1.0.txt).
 
-This only needs to be completed once, and enables contributions to all of the projects under the [Analytical Graphics Inc](https://github.com/AnalyticalGraphicsInc) organization, including Cesium.  The CLA ensures you retain copyright to your contributions, and provides us the right to use, modify, and redistribute your contributions using the [Apache 2.0 License](LICENSE.md).
+This only needs to be completed once, and enables contributions to all of the projects under the [Analytical Graphics Inc](https://github.com/AnalyticalGraphicsInc) organization, including CesiumJS.  The CLA ensures you retain copyright to your contributions, and provides us the right to use, modify, and redistribute your contributions using the [Apache 2.0 License](LICENSE.md).
 
 Please email a completed CLA with all fields filled in to [[email protected]](mailto:[email protected]).  Related questions are also welcome.
 
 ## Pull Request Guidelines
 
-Our code is our lifeblood so maintaining Cesium's high code quality is important to us.
+Our code is our lifeblood so maintaining CesiumJS's high code quality is important to us.
 
-* Review the [Contributor Guides](Documentation/Contributors/README.md).  In addition to Cesium-specific topics, they contain a lot of general software development best practices.
-* If this is your first contribution to Cesium, add your name to [CONTRIBUTORS.md](https://github.com/AnalyticalGraphicsInc/cesium/blob/master/CONTRIBUTORS.md).
+* Review the [Contributor Guides](Documentation/Contributors/README.md).  In addition to CesiumJS-specific topics, they contain a lot of general software development best practices.
+* If this is your first contribution to CesiumJS, add your name to [CONTRIBUTORS.md](https://github.com/AnalyticalGraphicsInc/cesium/blob/master/CONTRIBUTORS.md).
 * For an overview of our workflow see [github pull request workflows](http://cesiumjs.org/2013/10/08/GitHub-Pull-Request-Workflows/).
 * Pull request tips
+   * After you open a pull request, the friendly [cesium-concierge](https://github.com/AnalyticalGraphicsInc/cesium-concierge) bot will comment with a short automated review.  At least one human will also review your pull request.
    * If your pull request fixes an existing issue, include a link to the issue in the description (like this: [#1](https://github.com/AnalyticalGraphicsInc/cesium/issues/1)).  Likewise, if your pull request fixes an issue reported on the Cesium forum, include a link to the thread.
    * If your pull request needs additional work, include a [task list](https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments).
    * Once you are done making new commits to address feedback, add a comment to the pull request such as `"this is ready"` since GitHub doesn't notify us about commits.
 * Code and tests
    * Follow the [Coding Guide](Documentation/Contributors/CodingGuide/README.md).
-   * Verify your code passes [ESLint](http://www.eslint.org/).  Run ESLint for all of Cesium with `npm run eslint` or automatically run ESLint when files are saved with `npm run eslint-watch`.  See the [Build Guide](Documentation/Contributors/BuildGuide/README.md).
+   * Verify your code passes [ESLint](http://www.eslint.org/).  Run ESLint for all of CesiumJS with `npm run eslint` or automatically run ESLint when files are saved with `npm run eslint-watch`.  See the [Build Guide](Documentation/Contributors/BuildGuide/README.md).
    * Verify that all tests pass, and write new tests with excellent code coverage for new code.  Follow the [Testing Guide](Documentation/Contributors/TestingGuide/README.md).
-   * If you added new identifiers to the Cesium API:
+   * If you added new identifiers to the CesiumJS API:
       * Update [CHANGES.md](CHANGES.md).
       * Include reference documentation with code examples.  Follow the [Documentation Guide](Documentation/Contributors/DocumentationGuide/README.md).
       * If the change is significant, add a new [Sandcastle](http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html) example or extend and existing one.

CONTRIBUTORS.md

@@ -1,4 +1,4 @@
-See [CONTRIBUTING.md](CONTRIBUTING.md) for details on how to contribute to Cesium.  The following people have contributed to Cesium, under the following agreements:
+See [CONTRIBUTING.md](CONTRIBUTING.md) for details on how to contribute to CesiumJS.  The following people have contributed to CesiumJS, under the following agreements:
 
 ## [Corporate CLA](Documentation/Contributors/CLAs/corporate-cla-agi-v1.0.txt)
 

Documentation/Contributors/BuildGuide/README.md

@@ -14,7 +14,7 @@
    * Recommended Git settings:
       * `git config --global pull.rebase preserve` - when pulling remote changes, rebase your local changes on top of the remote changes, to avoid unnecessary merge commits.
       * `git config --global fetch.prune true` - when fetching remote changes, remove any remote branches that no longer exist on the remote.
-* Have [commit access](https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Documentation/Contributors/CommittersGuide/README.md) to cesium?
+* Have [commit access](https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Documentation/Contributors/CommittersGuide/README.md) to CesiumJS?
    * No
       * Fork [cesium](https://github.com/AnalyticalGraphicsInc/cesium).
       * Use the [GitHub website](https://github.com/AnalyticalGraphicsInc/cesium/branches/all) to delete all branches in your fork except `master`.
@@ -118,7 +118,7 @@ Here's the full set of scripts and what they do.
       * `test-webgl-validation` - Runs all tests with Karma and enables low-level WebGL validation.
       * `test-release` - Runs all tests on the minified release version of built Cesium.
    * **Deployment scripts**
-      * `deploy-s3` - Deploys the built cesium files, the npm package, and the zip file to Amazon S3. This requires having credentials set up for the S3 bucket to which you are deploying.
+      * `deploy-s3` - Deploys the built CesiumJS files, the npm package, and the zip file to Amazon S3. This requires having credentials set up for the S3 bucket to which you are deploying.
       * `deploy-status` - Set the deployment statuses in GitHub, for use with Travis.
       * `deploy-set-version` - Sets the version of `package.json`, for use with Travis.
 
@@ -130,7 +130,7 @@ Travis triggers a build whenever someone opens a pull request or pushes code to
 
 ![Checks](checks_failed.jpg)
 
-You can also access the build of any branch of cesium by going to the [Cesium Branches](https://github.com/AnalyticalGraphicsInc/cesium/branches/all) page, and clicking the icon next to the branch name.
+You can also access the build of any branch of CesiumJS by going to the [Cesium Branches](https://github.com/AnalyticalGraphicsInc/cesium/branches/all) page, and clicking the icon next to the branch name.
 
 ![Branches](branches.png)
 

Documentation/Contributors/CodeReviewGuide/README.md

@@ -1,10 +1,10 @@
-All code in Cesium is publicly peer reviewed.  We review code to share knowledge, foster shared ownership, and improve code quality and consistency.
+All code in CesiumJS is publicly peer reviewed.  We review code to share knowledge, foster shared ownership, and improve code quality and consistency.
 
 This guide describes best practices for code reviewers.
 
 * [General](#general)
 * [Reviewing](#reviewing)
-* [Changes to the Public Cesium API](#changes-to-the-public-cesium-api)
+* [Changes to the Public CesiumJS API](#changes-to-the-public-cesium-api)
 * [Testing](#testing)
 * [Merging](#merging)
 * [Useful Git Commit Management](#useful-git-commit-management)
@@ -22,7 +22,7 @@ This guide describes best practices for code reviewers.
 ## Reviewing
 
 * See the forest through the trees.  Don't just review code one line at a time.  Consider the big picture and its implications.
-* _Comments are about code_, not the contributor who wrote the code.  Don't be offended by a reviewer's comments and don't aim to offend when commenting.  We all want the same thing: to improve Cesium.
+* _Comments are about code_, not the contributor who wrote the code.  Don't be offended by a reviewer's comments and don't aim to offend when commenting.  We all want the same thing: to improve CesiumJS.
 * Provide motivation when it isn't obvious.  Suggest why a change should be made.
 * Point contributors to a relevant part of the [Coding Guide](../CodingGuide/README.md) when useful.
 * _Be concise_.  Make every word tell.
@@ -31,9 +31,9 @@ This guide describes best practices for code reviewers.
 * Bring others into the conversation sparingly.  If someone has expertise with a particular language feature or problem domain under review, invite them to comment with an `@mention`.
 * If an experienced contributor makes a occasional whitespace or trivial mistake, just fix it to save on noise and speedup the review.
 
-## Changes to the Public Cesium API
+## Changes to the Public CesiumJS API
 
-* If new identifiers were added to the public Cesium API:
+* If new identifiers were added to the public CesiumJS API:
    * Verify there is new reference doc.  See the [Documentation Guide](../CodingGuide/README.md).
    * Verify that [CHANGES.md](../../../CHANGES.md) was updated.
    * Does the change warrant a new Sandcastle example?
@@ -43,13 +43,13 @@ This guide describes best practices for code reviewers.
 ## Testing
 
 * Don't just review the code; test it by running the unit tests and relevant Sandcastle examples.  See the [Testing Guide](../TestingGuide/README.md).
-* For some changes, it is useful to profile Cesium or step through the code in the debugger.
+* For some changes, it is useful to profile CesiumJS or step through the code in the debugger.
 * Read the new reference doc.  Build the reference doc if the changes are significant.
 
 ## Merging
 
 * When a reviewer hits merge, the ideal is that they have enough knowledge of the new code that they could support it in the future.  In practice, this isn't always realistic but we strive for it.
-* Cesium uses Travis CI for continuous integration.  Travis automatically builds Cesium, runs ESLint, and generates the documentation for each branch pushed to GitHub.  Before merging a pull request, verify that all Travis checks pass, indicated by the green check-mark and green "Merge pull request" button:
+* CesiumJS uses Travis CI for continuous integration.  Travis automatically builds CesiumJS, runs ESLint, and generates the documentation for each branch pushed to GitHub.  Before merging a pull request, verify that all Travis checks pass, indicated by the green check-mark and green "Merge pull request" button:
 
 ![Travis CI checks](Travis.jpg)
 

Documentation/Contributors/CodingGuide/README.md

@@ -1,9 +1,11 @@
 # Coding Guide
 
-Cesium is one of the largest JavaScript codebases in the world.  Since its start, we have maintained a high standard for code quality, which has made the codebase easier to work with for both new and experienced contributors.  We hope you find the codebase to be clean and consistent.
+CesiumJS is one of the largest JavaScript codebases in the world.  Since its start, we have maintained a high standard for code quality, which has made the codebase easier to work with for both new and experienced contributors.  We hope you find the codebase to be clean and consistent.
 
 In addition to describing typical coding conventions, this guide also covers best practices for design, maintainability, and performance.  It is the cumulative advice of many developers after years of production development, research, and experimentation.
 
+This guide applies to CesiumJS and all parts of the Cesium ecosystem written in JavaScript.
+
 :art: The color palette icon indicates a design tip.
 
 :house: The house icon indicates a maintainability tip.  The whole guide is, of course, about writing maintainable code.

Documentation/Contributors/CommittersGuide/README.md

@@ -13,4 +13,4 @@
 
 * If a contributor has _significant and sustained_ contributions and should have commit access, propose it on [email protected].  Following the [Apache Way](http://community.apache.org/newcommitter.html), they will be given commit access with three yes votes and no no's over a week.  To keep with the community spirit of the project, this is independent of affiliation; no one is entitled to commit access solely based on their affiliation.  See Producing Open Source Software: [Money Can't Buy You Love](http://producingoss.com/en/money-vs-love.html) and [Committers](http://producingoss.com/en/committers.html).
 * If a committer is inactive for one year, they lose commit access.
-* Everyone with commit access to the main Cesium repo must enable [two-factor authentication](https://help.github.com/articles/about-two-factor-authentication) on their GitHub account.
+* Everyone with commit access to the main CesiumJS repo must enable [two-factor authentication](https://help.github.com/articles/about-two-factor-authentication) on their GitHub account.

Documentation/Contributors/DocumentationGuide/README.md

@@ -1,10 +1,10 @@
 # Documentation Guide
 
-Cesium's reference documentation is one of the most popular sections of the Cesium website, and a critical resource for developers.  
+CesiumJS's reference documentation is one of the most popular sections of the CesiumJS website, and a critical resource for developers.  
 
 This guide describes best practices for writing reference doc.
 
-Always include doc for new identifiers (classes, functions, properties, constants) in the public Cesium API.
+Always include doc for new identifiers (classes, functions, properties, constants) in the public CesiumJS API.
 
 Generally, just follow the patterns that are already in comparable parts of the code, e.g., if you are documenting a new utility function in `Core`, look at a function in `Core` such as [`binarySearch`](https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Core/binarySearch.js); likewise, if you are documenting a new class in `Scene`, look at a similar class such as [`Model`](https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/Model.js).
 
@@ -28,13 +28,13 @@ Generally, just follow the patterns that are already in comparable parts of the
 
 ## Building the Doc
 
-The reference doc is written in JavaScript code comments using [JSDoc3](http://usejsdoc.org/index.html) tags.  At the command line, build the doc from the root Cesium directory by running the following:
+The reference doc is written in JavaScript code comments using [JSDoc3](http://usejsdoc.org/index.html) tags.  At the command line, build the doc from the root CesiumJS directory by running the following:
 ```
 npm run generateDocumentation
 ```
 This creates a `Build/Documentation` directory with the built HTML files.
 
-There is a link to the doc from Cesium's main `index.html` when running
+There is a link to the doc from CesiumJS's main `index.html` when running
 ```
 npm start
 ```
@@ -43,7 +43,7 @@ npm start
 
 ## Basics
 
-Consider one of the simplest functions in Cesium, `defined`:
+Consider one of the simplest functions in CesiumJS, `defined`:
 ```javascript
 /**
  * @exports defined
@@ -108,7 +108,7 @@ Matrix4.fromRotationTranslation = function(rotation, translation, result) {
 generates
 
 ![](fromRotationTranslation.jpg)
-The Cesium classes in the `Type` column are links to their doc.
+The CesiumJS classes in the `Type` column are links to their doc.
 
 ## `options` Parameters
 

Documentation/Contributors/README.md

@@ -1,13 +1,13 @@
 # Contributor Guides
 
 * [CONTRIBUTING.md](../../CONTRIBUTING.md) - Start here.  How to find something to work on, submit issues, and open pull requests.
-* [Build Guide](BuildGuide/README.md) - How to build and run Cesium locally.
-* **IDEs** - use any IDE you want for Cesium development.  Most contributors use WebStorm (commercial) or VSCode (open source).
+* [Build Guide](BuildGuide/README.md) - How to build and run CesiumJS locally.
+* **IDEs** - use any IDE you want for CesiumJS development.  Most contributors use WebStorm (commercial) or VSCode (open source).
    * [WebStorm Guide](WebStormGuide/README.md) - How to set up WebStorm.
    * [VSCode Guide](VSCodeGuide/README.md) - How to set up VSCode.
 * [Coding Guide](CodingGuide/README.md) - JavaScript and GLSL coding conventions and best practices for design, maintainability, and performance.
-* [Testing Guide](TestingGuide/README.md) - How to run the Cesium tests and write awesome tests.
+* [Testing Guide](TestingGuide/README.md) - How to run the CesiumJS tests and write awesome tests.
 * [Documentation Guide](DocumentationGuide/README.md) - How to write great reference documentation.
 * [Code Review Guide](CodeReviewGuide/README.md) - Best practices for reviewing code in pull requests.
 * [Presenter's Guide](PresentersGuide/README.md) - Tips for giving talks.
-* [Committer's Guide](CommittersGuide/README.md) - What to do with commit access to the main Cesium repo.
+* [Committer's Guide](CommittersGuide/README.md) - What to do with commit access to the main CesiumJS repo.