Release 1.6

.circleci/config.yml

@@ -236,7 +236,7 @@ jobs:
           name: "Print environment"
           command: printenv
       - run:
-          name "Running self-test (2): Con-K"
+          name: "Running self-test (2): Con-K"
           command: |
             eval $PRE_TEST_COMMANDS;
             ./meteor self-test \

.github/ISSUE_TEMPLATE.md

@@ -9,7 +9,7 @@
 
 Before reporting a bug, please check for existing or closed issues
 first and read the instructions for filing a bug report:
-https://github.com/meteor/meteor/blob/devel/Contributing.md#reporting-a-bug-in-meteor
+https://github.com/meteor/meteor/blob/devel/CONTRIBUTING.md#reporting-a-bug-in-meteor
 
 ### This bug report should include:
 - [ ] A descriptive title

.github/PULL_REQUEST_TEMPLATE.md

@@ -15,7 +15,7 @@ Here are some important details to follow:
           please _try_ to add a test which verifies the fix.  If you cannot, you should
           still submit the PR but we may still ask you (and help you!) to create a test.
 * 📖 Contribution guidelines
-          Always follow https://github.com/meteor/meteor/blob/master/Contributing.md
+          Always follow https://github.com/meteor/meteor/blob/master/CONTRIBUTING.md
           when submitting a pull request.  Make sure existing tests still pass, and add
           tests for all new behavior.
 * ✏️ Explain your pull request

CODE_OF_CONDUCT.md

@@ -0,0 +1,69 @@
+# Meteor Project Code of Conduct
+
+### Community and Diversity
+
+We want to build a productive, happy and agile community that welcomes new ideas, constantly looks for areas to improve, and fosters collaboration. 
+
+The project gains strength from a diversity of backgrounds and perspectives in our contributor community, and we actively seek participation from those who enhance it. This code of conduct exists to lay some ground rules that ensure we can collaborate and communicate effectively, despite our diversity. The code applies equally to founders, team members and those seeking help and guidance.
+
+### Using This Code
+
+This isn’t an exhaustive list of things that you can’t do. Rather, it’s a guide for participation in the community that outlines how each of us can work to keep Meteor a positive, successful, and growing project. 
+
+This code of conduct applies to all spaces managed by the Meteor project or company. This includes Slack, GitHub issues, and any other forums created by the Meteor team which the community uses for communication. Breaches of this code outside these spaces may affect a person's ability to participate within them. We expect it to be honored by everyone who represents or participates in the project, whether officially or informally.
+
+If you believe someone is violating the code of conduct, please report it by emailing [community@meteor.com](mailto:community@meteor.com). 
+
+### We Strive To:
+
+- **Be open, patient, and welcoming**
+
+    Members of this community are open to collaboration, whether it's on PRs, issues, or problems. We're receptive to constructive comment and criticism, as we value what the experiences and skill sets of contributors bring to the project. We're accepting of all who wish to get involved, and find ways for anyone to participate in a way that best matches their strengths.
+
+- **Be considerate**
+
+    We are considerate of our peers: other Meteor users and contributors. We’re thoughtful when addressing others’ efforts, keeping in mind that work is often undertaken for the benefit of the community. We also value others’ time and appreciate that not every issue or comment will be responded to immediately. We strive to be mindful in our communications, whether in person or online, and we're tactful when approaching views that are different from our own.
+
+- **Be respectful**
+
+    As a community of professionals, we are professional in our handling of disagreements, and don’t allow frustration to turn into a personal attack. We work together to resolve conflict, assume good intentions and do our best to act in an empathic fashion. 
+
+    We do not tolerate harassment or exclusionary behavior. This includes, but is not limited to:
+  - Violent threats or language directed against another person.
+  - Discriminatory jokes and language.
+  - Posting sexually explicit or sexualized content.
+  - Posting content depicting or encouraging violence. 
+  - Posting (or threatening to post) other people's personally identifying information ("doxing").
+  - Personal insults, especially those using racist or sexist terms.
+  - Unwelcome sexual attention.
+  - Advocating for, or encouraging, any of the above behavior.
+  - Repeated harassment of others. In general, if someone asks you to stop, then stop.
+
+- **Take responsibility for our words and our actions**
+
+    We can all make mistakes; when we do, we take responsibility for them. If someone has been harmed or offended, we listen carefully and respectfully. We are also considerate of others’ attempts to amend their mistakes.
+
+- **Be collaborative**  
+
+    The work we produce is (and is part of) an ecosystem containing several parallel efforts working towards a similar goal. Collaboration between teams and individuals that each have their own goal and vision is essential to reduce redundancy and improve the quality of our work. 
+
+    Internally and externally, we celebrate good collaboration. Wherever possible, we work closely with upstream projects and others in the free software community to coordinate our efforts. We prefer to work transparently and involve interested parties as early as possible.
+
+- **Ask for help when in doubt**
+
+    Nobody is expected to be perfect in this community. Asking questions early avoids many problems later, so questions are encouraged, though they may be directed to the appropriate forum. Those who are asked should be responsive and helpful.
+
+- **Take initiative** 
+
+    We encourage new participants to feel empowered to lead, to take action, and to experiment when they feel innovation could improve the project. If we have an idea for a new tool, or how an existing tool can be improved, we speak up and take ownership of that work when possible. 
+
+### Attribution
+
+Sections of this Code of Conduct were inspired in by the following Codes from other open source projects and resources we admire:  
+
+- [The Contributor Covenant](http://contributor-covenant.org/version/1/4/)
+- [Python](https://www.python.org/psf/codeofconduct/)
+- [Ubuntu](http://www.ubuntu.com/about/about-ubuntu/conduct)
+- [Django](https://www.djangoproject.com/conduct/)
+
+*This Meteor Code of Conduct is licensed under the [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/) license. This Code was last updated on August 28, 2017.* 

Contributing.md → CONTRIBUTING.md

@@ -4,18 +4,18 @@ We are excited to have your help building Meteor — both the platform and t
 
 ## Project overview
 
-Before we jump into detailed guidelines for opening and triaging issues and submitting pull requests, here is some information about how our project is structured and resources you should refer to as you start contributing. 
+Before we jump into detailed guidelines for opening and triaging issues and submitting pull requests, here is some information about how our project is structured and resources you should refer to as you start contributing.
 
 ### Ways to contribute
 
 There are many ways to contribute to the Meteor Project. Here’s a list of technical contributions with increasing levels of involvement and required knowledge of Meteor’s code and operations.  
-- [Reporting a bug](Contributing.md#reporting-a-bug-in-meteor)
-- [Triaging issues](IssueTriage.md)
-- [Contributing to documentation](https://github.com/meteor/docs/blob/master/Contributing.md)
-- [Finding work](Contributing.md#finding-work)
-- [Submitting pull requests](Contributing.md#making-changes-to-meteor-core)
-- [Reviewing pull requests](Contributing.md#reviewer) 
-- [Maintaining a community package](Contributing.md#community-package-maintainer)
+- [Reporting a bug](CONTRIBUTING.md#reporting-a-bug-in-meteor)
+- [Triaging issues](ISSUE_TRIAGE.md)
+- [Contributing to documentation](https://github.com/meteor/docs/blob/master/CONTRIBUTING.md)
+- [Finding work](CONTRIBUTING.md#finding-work)
+- [Submitting pull requests](CONTRIBUTING.md#making-changes-to-meteor-core)
+- [Reviewing pull requests](CONTRIBUTING.md#reviewer)
+- [Maintaining a community package](CONTRIBUTING.md#community-package-maintainer)
 
 There are also several ways to contribute to the Meteor Project outside of GitHub, like organizing or speaking at [Meetups](https://www.meetup.com/topics/meteor/) and events and helping to moderate our [forums](https://forums.meteor.com/).
 
@@ -31,51 +31,51 @@ Any issue which does not have the `confirmed` label still requires discussion on
 
 ### Project roles
 
-We’ve just begun to create more defined project roles for Meteor. Here are descriptions of the existing project roles, along with the current contributors taking on those roles today. 
+We’ve just begun to create more defined project roles for Meteor. Here are descriptions of the existing project roles, along with the current contributors taking on those roles today.
 
-#### Issue Triager 
+#### Issue Triager
 
-Issue Triagers are members of the community that meet with us weekly to help triage Meteor’s open issues and bug reports. Once you’ve begun triaging issues regularly on your own, we will invite you to join our dedicated Slack channel to participate in these regular coordination sessions. 
+Issue Triagers are members of the community that meet with us weekly to help triage Meteor’s open issues and bug reports. Once you’ve begun triaging issues regularly on your own, we will invite you to join our dedicated Slack channel to participate in these regular coordination sessions.
 
-Current Issue Triagers: 
+Current Issue Triagers:
 - [@hwillson](https://github.com/hwillson)
 - [@laosb](https://github.com/laosb)
 - [@abernix](https://github.com/abernix)
 - [@lorensr](https://github.com/lorensr)
 
 #### Reviewer
 
-Our most regular and experienced Issue Triagers sometimes move on to doing code reviews for pull requests, and have input into which pull requests should be merged. 
+Our most regular and experienced Issue Triagers sometimes move on to doing code reviews for pull requests, and have input into which pull requests should be merged.
 
 Current Reviewers:
 - [@hwillson](https://github.com/hwillson)
 - [@lorensr](https://github.com/lorensr)
 - [@abernix](https://github.com/abernix)
 
-#### Core Committer 
+#### Core Committer
 
 For now, the only contributors with commit access to meteor/meteor are employees of Meteor Development Group, the company that sponsors the Meteor project. We're actively exploring adding non-MDG core committers who have distinguished themselves in other contribution areas.  
 
 Project Lead: [@benjamn](https://github.com/benjamn)
 
-Current Core Committers: 
+Current Core Committers:
 - [@abernix](https://github.com/abernix)
 - [@glasser](https://github.com/glasser)
 - [@stubailo](https://github.com/stubailo)
 
 #### Documentation Maintainer
 
-Documentation Maintainers are regular documentation contributors that have been given the ability to merge docs changes on [meteor/docs](https://github.com/meteor/docs). 
+Documentation Maintainers are regular documentation contributors that have been given the ability to merge docs changes on [meteor/docs](https://github.com/meteor/docs).
 
 Current Documentation Maintainers:
 - [@abernix](https://github.com/abernix)
 - [@lorensr](https://github.com/lorensr)
 
 #### Community Package Maintainer:
 
-Community package maintainers are community members who maintain packages outside of Meteor core. This requires code to be extracted from meteor/meteor, and entails a high level of responsibility. For this reason, community maintainers generally (and currently) must first become an advanced contributor to Meteor core and have 4-5 non-trivial pull requests merged that went through the proper contribution work-flow. At that point, core contributors may make the case for breaking out a particular core package, and assist in the technical process around doing so. 
+Community package maintainers are community members who maintain packages outside of Meteor core. This requires code to be extracted from meteor/meteor, and entails a high level of responsibility. For this reason, community maintainers generally (and currently) must first become an advanced contributor to Meteor core and have 4-5 non-trivial pull requests merged that went through the proper contribution work-flow. At that point, core contributors may make the case for breaking out a particular core package, and assist in the technical process around doing so.
 
-Current Community Package Maintainers: 
+Current Community Package Maintainers:
 - [@mitar](https://github.com/mitar) for [Blaze](https://github.com/meteor/blaze)
 
 #### Community Manager
@@ -137,14 +137,14 @@ A reproduction recipe works like this:
 
 If you want to submit a pull request that fixes your bug, that's even
 better.  We love getting bugfix pull requests.  Just make sure they're
-written with the [correct style](Development.md#code-style) and *come with tests*.  Read further down
+written with the [correct style](DEVELOPMENT.md#code-style) and *come with tests*.  Read further down
 for more details on proposing changes to core code.
 
 ## Feature requests
 
 Feature requests are tracked in the [meteor/meteor-feature-requests](https://github.com/meteor/meteor-feature-requests) repository, and include a label that corresponds to the Meteor subproject that they are a part of.
 
-Meteor is a big project with [many sub-projects](https://github.com/meteor/meteor/tree/devel/packages). 
+Meteor is a big project with [many sub-projects](https://github.com/meteor/meteor/tree/devel/packages).
 There aren't as many [core developers (we're hiring!)](https://www.meteor.io/jobs/)
 as there are sub-projects, so we're not able to work on every single sub-project every
 month.  We use our [roadmap](Roadmap.md) to communicate the high-level features we're currently prioritizing.
@@ -164,7 +164,7 @@ Finally, you can show your support for (or against!) features by using [GitHub r
 
 ## Triaging issues
 
-A great way to contribute to Meteor is by helping keep the issues in the repository clean and well organized. This process is called 'issue triage' and the steps are described [here](IssueTriage.md).
+A great way to contribute to Meteor is by helping keep the issues in the repository clean and well organized. This process is called 'issue triage' and the steps are described [here](ISSUE_TRIAGE.md).
 
 ## Documentation
 
@@ -214,7 +214,7 @@ same time is hard but incredibly rewarding.  We hope you come to feel the same w
 
 ### Understanding the core
 
-For more information about how to work with Meteor core, take a look at the [Development](Development.md) document which explains many important details, including how to [run from a checkout](Development.md#running-from-a-git-checkout), [run tests](Development.md#tests), and more.
+For more information about how to work with Meteor core, take a look at the [Development](DEVELOPMENT.md) document which explains many important details, including how to [run from a checkout](DEVELOPMENT.md#running-from-a-git-checkout), [run tests](DEVELOPMENT.md#tests), and more.
 
 ### Proposing your change
 
@@ -244,9 +244,9 @@ Once you've come up with a good design, go ahead and submit a pull request (PR).
  * Include tests that prove your code works.
 
  * Follow appropriate style for
-   [code contributions](Development.md#code-style)
+   [code contributions](DEVELOPMENT.md#code-style)
    and
-   [commit messages](Development.md#commit-messages)
+   [commit messages](DEVELOPMENT.md#commit-messages)
 
  * Be sure your author field in git is properly filled out with your full name
  and email address so we can credit you.

Development.md → DEVELOPMENT.md

@@ -1,12 +1,12 @@
 # Development
 
-This document is intended to provide instructions and helpful information for developers who are [contributing](Contributing.md) [pull-requests](https://github.com/meteor/meteor/pulls/) (or otherwise making changes) to **Meteor Core itself (not Meteor apps)**.
+This document is intended to provide instructions and helpful information for developers who are [contributing](CONTRIBUTING.md) [pull-requests](https://github.com/meteor/meteor/pulls/) (or otherwise making changes) to **Meteor Core itself (not Meteor apps)**.
 
 As the first suggestion to the reader of this document: If, during the course of development, a Meteor-specific process is revealed which is helpful and not documented here, please consider editing this document and submitting a pull-request.  Another developer will be thankful!
 
 ## Running from a Git checkout
 
-If you want to run on the bleeding edge, or [help contribute to Meteor](Contributing.md), you
+If you want to run on the bleeding edge, or [help contribute to Meteor](CONTRIBUTING.md), you
 can run Meteor directly from a Git checkout using these steps:
 
 1. **Clone from GitHub**
@@ -55,7 +55,7 @@ can run Meteor directly from a Git checkout using these steps:
 The following are some distinct differences you must pay attention to when running Meteor from a checkout:
 
   * You cannot pin apps to specific Meteor releases or change the release using `--release`.
-  
+
 ## The "Dev Bundle"
 
 The "dev bundle" (identified as the `dev_bundle` in the folder structure) is a generated bundle of code, packages and tools which are essential to providing the functionality of the Meteor tool (`meteor`) and the app bundles which it builds.
@@ -94,7 +94,7 @@ This will generate a new tarball (`dev_bundle_<Platform>_<arch>_<version>.tar.gz
 
 ### Submitting "Dev Bundle" Pull Requests
 
-It's important to note that while `dev_bundle` pull requests are accepted/reviewed, a new `dev_bundle` can only be published to MDG's Meteor infrastructure by an MDG staff member. This means that the build tool and package tests of submitted `dev_bundle` pull requests will always initially fail (since the new `dev_bundle` hasn't yet been built/published by MDG, which means it can't be downloaded by Meteor's continuous integration environment). 
+It's important to note that while `dev_bundle` pull requests are accepted/reviewed, a new `dev_bundle` can only be published to MDG's Meteor infrastructure by an MDG staff member. This means that the build tool and package tests of submitted `dev_bundle` pull requests will always initially fail (since the new `dev_bundle` hasn't yet been built/published by MDG, which means it can't be downloaded by Meteor's continuous integration environment).
 
 Pull requests that contain `dev_bundle` changes will be noted by repo collaborators, and a request to have a new `dev_bundle` built/published will be forwarded to MDG.
 
@@ -140,14 +140,6 @@ For more fine-grained control, if you're interested in running only the specific
 
 While TinyTest and the `test-packages` command can be used to test internal Meteor packages, they cannot be used to test the Meteor Tool itself. The Meteor Tool is a node app that uses a home-grown "self test" system.
 
-#### Prerequisites
-
-To reduce the size of the Meteor distribution, some parts of the self-test system must be installed separately, including `phantomjs-prebuilt` and `browserstack-webdriver`.
-
-A notification will be displayed when attempting to use the `self-test` commands if these dependencies are not installed.  Make sure to install them into your checkout when prompted:
-
-    ./meteor npm install -g phantomjs-prebuilt browserstack-webdriver
-
 #### Listing available tests
 
 To see a list of the tests which are included in the self-test system, list them with the `--list` option: