Merged in copy2018-fixes (pull request #124)

Changed copyright years, freud capitalization, updated links.

Approved-by: Vyas Ramasubramani <vramasub@umich.edu>
Approved-by: Bradley Dice <bdice@bradleydice.com>

.mailmap

@@ -0,0 +1,29 @@
+Eric Harper <harperic@umich.edu> harperic <harperic@umich.edu>
+Eric Harper <harperic@umich.edu> harperic <eharp1126@gmail.com>
+Vyas Ramasubramani <vramasub@umich.edu> Vyas <vramasub@umich.edu>
+Vyas Ramasubramani <vramasub@umich.edu> Vyas Ramasubramani <vyas.ramasubramani@gmail.com>
+Richmond Newman <newmanrs@umich.edu> Richmond <newmanrs@umich.edu>
+Richmond Newman <newmanrs@umich.edu> newmanrs <newmanrs@umich.edu>
+Richmond Newman <newmanrs@umich.edu> Richmond Newman <rsnewman@seattlecca.org>
+Antonio Osorio <aosorio@umich.edu> Antonio Osorio <antonio.f.osorio@gmail.com>
+M. Eric Irrgang <eirrgang@umich.edu> Eric Irrgang <eirrgang@umich.edu>
+Erin Teich <erteich@umich.edu> Erin G Teich <erteich@umich.edu>
+Chrisy Du <xiyudu@umich.edu> Chrisy Du <xiyudu@horton.engin.umich.edu>
+Chrisy Du <xiyudu@umich.edu> Chrisy Du <xiyudu@colavito.engin.umich.edu>
+Chrisy Du <xiyudu@umich.edu> Chrisy Du <xiyudu@Chrisys-MacBook-Pro.local>
+Chrisy Du <xiyudu@umich.edu> Chrisy Du <xiyudu@host-180.subnet-108.med.umich.edu>
+Ryan Marson <rmarson@umich.edu> Ryan <rmarson@umich.edu>
+Ryan Marson <rmarson@umich.edu> rmarson <rmarson@hornsby.engin.umich.edu>
+Benjamin Schultz <baschult@umich.edu> Ben Schultz <benjamin.a.schultz@gmail.com>
+Benjamin Schultz <baschult@umich.edu> Benjamin Schultz <benjamin.a.schultz@gmail.com>
+Joshua A. Anderson <joaander@umich.edu> Joshua A Anderson <joaander@umich.edu>
+Joshua A. Anderson <joaander@umich.edu> Joshua Anderson <joaander@umich.edu>
+Tom Grubb <tgrubb@umich.edu> tgrubb <tgrubb@lolich.engin.umich.edu>
+James Antonaglia <jamesaan@umich.edu> Jim <jamesaan@umich.edu>
+Rose Cersonsky <rosecers@umich.edu> rosecers <rosecers@umich.edu>
+Carolyn Phillips <phillicl@umich.edu> phillicl <phillicl@Pedroia.local>
+Carolyn Phillips <phillicl@umich.edu> phillicl <phillicl@dhcp-interpro-chry8.public.engin.umich.edu>
+Mayank Agrawal <amayank@umich.edu> Mayank Agrawal <amayank@whitaker.engin.umich.edu>
+Mayank Agrawal <amayank@umich.edu> Mayank Agrawal <amayank@whitaker.local>
+Jens Glaser <jsglaser@umich.edu> Jens-Steffen Glaser <jsglaser@umich.edu>
+Bryan VanSaders <bvansade@umich.edu> Bryan Vansaders <bvansade@umich.edu>

CONTRIBUTING.md

@@ -1,18 +1,18 @@
-Contributions are welcomed via pull requests on Bitbucket. First contact the Freud developers prior to beginning
+Contributions are welcomed via pull requests on Bitbucket. First contact the freud developers prior to beginning
 your work to ensure that your plans mesh well with the planned development direction and standards set for the project.
 Then implement your code.
 
-Submit a pull request on bitbucket. Multiple developers and/or users will review requested changes and make comments.
-This The rest of this file will be used as a checklist to review the pull request. The lead developer will merge into
-the mainline after the review is complete and approved.
+Submit a pull request on Bitbucket. Multiple developers and/or users will review requested changes and make comments.
+This The rest of this file will be used as a checklist to review the pull request. The lead developer(s) will merge into
+the master branch after the review is complete and approved.
 
 # Features
 
 ## Implement functionality in a general and flexible fashion
 
-Freud provides a lot of flexibility to the user. Your pull request should provide something that is applicable
-to a variety of use-cases and not just the one thing you might need it to do for your research. Speak to the lead
-developers before writing your code, and they will help you make design choices that allow flexibility.
+The freud library provides a lot of flexibility to the user. Your pull request should provide something that is
+applicable to a variety of use-cases and not just the one thing you might need it to do for your research. Speak to the
+lead developers before writing your code, and they will help you make design choices that allow flexibility.
 
 ## Do not degrade performance of existing code paths
 
@@ -21,15 +21,15 @@ existing code.
 
 ## Add dependencies only if absolutely necessary
 
-In order to make Freud as widely available as possible, we try to keep the number of dependencies to a minimum. If you
+In order to make freud as widely available as possible, we try to keep the number of dependencies to a minimum. If you
 need a feature present in an external library, follow the following steps:
 
-1. Add to Freud itself if it's simple or if other modules would benefit:
+1. Add to freud itself if it's simple or if other modules would benefit:
     * Example: Added simple tensor math for CubaticOrderParameter
-2. Add via submodule if the code exists externally
+2. Add via submodule if the code exists externally:
     * Example: fsph
-3. Contact Freud developers to inquire if the library you'd like as a dependency fits in with the overall design/goals
-of freud
+3. Contact freud developers to inquire if the library you'd like as a dependency fits in with the overall design/goals
+of freud.
 
 # Version control
 
@@ -52,14 +52,15 @@ If there are spelling errors to fix, propose that in a separate pull request :)
 
 ## Agree to the contributor agreement
 
-All contributors must agree to the Contributor Agreement ([ContributorAgreement.md](ContributorAgreement.md)) before their pull request can be merged.
+All contributors must agree to the Contributor Agreement ([ContributorAgreement.md](ContributorAgreement.md))
+before their pull request can be merged.
 
 # Source code
 
 ## Use a consistent style
 
 It is important to have a consistent style throughout the source code. See [SourceConventions.md](SourceConventions.md)
-for the defined style guidelines for Freud code.
+for the defined style guidelines for freud code.
 
 ## Document code with comments
 
@@ -76,8 +77,8 @@ Your changes should compile without warnings.
 
 ## Write unit tests
 
-All new functionality in Freud should be tested with automatic unit tests that execute in a few seconds (if your
-specific test requires a long amount of time, please alert the Freud developers as to why this is required so that
+All new functionality in freud should be tested with automatic unit tests that execute in a few seconds (if your
+specific test requires a long amount of time, please alert the freud developers as to why this is required so that
 your test can be opted-out of for "regular" unit-testing). High level features should be tested from python, and the
 python tests should attempt to cover all options that the user can select.
 

ChangeLog.md

@@ -1,14 +1,5 @@
 # Change Log
 
-## v0.7.0
-
-* Improved API
-    - Named Tuples for Boxes intelligently converted for user
-    - inputs to compute functions converted to proper type, made contiguous if necessary
-    - if a single input is passed to a function requiring two, it is assumed the user wants that input duplicated
-* Boost dependence removed
-    - migration of boost bimap to custom implementation
-
 ## v0.6.0
 
 * trajectory module removed

ContributorAgreement.md

@@ -1,6 +1,6 @@
-Freud Contributor Agreement
+freud Contributor Agreement
 
-These terms apply to your contribution to the Freud Open Source Project ("Project") owned or managed by the Regents of the University of Michigan ("Michigan"), and set out the intellectual property rights you grant to Michigan in the contributed materials. If this contribution is on behalf of a company, the term "you" will also mean the company you identify below. If you agree to be bound by these terms, fill in the information requested below and provide your signature.
+These terms apply to your contribution to the freud Open Source Project ("Project") owned or managed by the Regents of the University of Michigan ("Michigan"), and set out the intellectual property rights you grant to Michigan in the contributed materials. If this contribution is on behalf of a company, the term "you" will also mean the company you identify below. If you agree to be bound by these terms, fill in the information requested below and provide your signature.
 
 1. The term "contribution" means any source code, object code, patch, tool, sample, graphic, specification, manual, documentation, or any other material posted or submitted by you to a project.
 1. With respect to any worldwide copyrights, or copyright applications and registrations, in your contribution:
@@ -19,11 +19,11 @@ These terms apply to your contribution to the Freud Open Source Project ("Projec
 you are authorized to sign this contract on behalf of your company (if identified below).
 1. The terms will be governed by the laws of the State of Michigan and applicable U.S. Federal Law. Any choice of law rules will not apply.
 
-** By making contribution, you electronically sign and agree to the terms of the Freud Contributor Agreement.**
+** By making contribution, you electronically sign and agree to the terms of the freud Contributor Agreement.**
 
 ![by-sa.png](https://licensebuttons.net/l/by-sa/3.0/88x31.png)
 
 Based on the Sun Contributor Agreement - version 1.5.
 This document is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License
-http://creativecommons.org/licenses/by-sa/3.0/
+https://creativecommons.org/licenses/by-sa/3.0/