Update documentation to meet CII badging requirements

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,25 @@
+# Contributor Code of Conduct
+
+As contributors and maintainers of this project, we pledge to respect all people who 
+contribute through reporting issues, posting feature requests, updating documentation,
+submitting pull requests or patches, and other activities.
+
+We are committed to making participation in this project a harassment-free experience for
+everyone, regardless of level of experience, gender, gender identity and expression,
+sexual orientation, disability, personal appearance, body size, race, ethnicity, age, or religion.
+
+Examples of unacceptable behavior by participants include the use of sexual language or
+imagery, derogatory comments or personal attacks, trolling, public or private harassment,
+insults, or other unprofessional conduct.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments,
+commits, code, wiki edits, issues, and other contributions that are not aligned to this 
+Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed 
+from the project team.
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by 
+opening an issue or contacting one or more of the project maintainers.
+
+This Code of Conduct is adapted from the Contributor Covenant 
+(http://contributor-covenant.org), version 1.0.0, available at 
+http://contributor-covenant.org/version/1/0/0/

CONTRIBUTING.md

@@ -1,13 +1,20 @@
 # Contributing to ggplot2 development
 
-The goal of this guide is to help you get up and contributing to ggplot2 as quickly as possible. The guide is divided into two main pieces:
+The goal of this guide is to help you get up and contributing to ggplot2 as 
+quickly as possible. The guide is divided into two main pieces:
 
 1. Filing a bug report or feature request in an issue.
 1. Suggesting a change via a pull request.
 
+Please note that 'ggplot2 is released with a [Contributor Code of Conduct](.github/CODE_OF_CONDUCT.md). By contributing to this project, 
+you agree to abide by its terms.
+
 ## Issues
 
-When filing an issue, the most important thing is to include a minimal reproducible example so that we can quickly verify the problem, and then figure out how to fix it. There are three things you need to include to make your example reproducible: required packages, data, code.
+When filing an issue, the most important thing is to include a minimal 
+reproducible example so that we can quickly verify the problem, and then figure 
+out how to fix it. There are three things you need to include to make your 
+example reproducible: required packages, data, code.
 
 1.  **Packages** should be loaded at the top of the script, so it's easy to
     see which ones the example needs.
@@ -34,9 +41,11 @@ When filing an issue, the most important thing is to include a minimal reproduci
     * do your best to remove everything that is not related to the problem.  
      The shorter your code is, the easier it is to understand.
 
-You can check you have actually made a reproducible example by starting up a fresh R session and pasting your script in.
+You can check you have actually made a reproducible example by starting up a 
+fresh R session and pasting your script in.
 
-(Unless you've been specifically asked for it, please don't include the output of `sessionInfo()`.)
+(Unless you've been specifically asked for it, please don't include the output 
+of `sessionInfo()`.)
 
 ## Pull requests
 
@@ -48,7 +57,9 @@ To contribute a change to ggplot2, you follow these steps:
 1. Iterate until either we accept the PR or decide that it's not
    a good fit for ggplot2.
 
-Each of these steps are described in more detail below. This might feel overwhelming the first time you get set up, but it gets easier with practice. If you get stuck at any point, please reach out for help on the [ggplot2-dev](https://groups.google.com/forum/#!forum/ggplot2-dev) mailing list.
+Each of these steps are described in more detail below. This might feel 
+overwhelming the first time you get set up, but it gets easier with practice. 
+If you get stuck at any point, please reach out for help on the [ggplot2-dev](https://groups.google.com/forum/#!forum/ggplot2-dev) mailing list.
 
 If you're not familiar with git or github, please start by reading <http://r-pkgs.had.co.nz/git.html>
 
@@ -89,7 +100,7 @@ Pull requests will be evaluated against a seven point checklist:
     and don't submit any others until the first one has been processed.
 
 1.  __Use ggplot2 coding style__. Please follow the
-    [official ggplot2 style](http://adv-r.had.co.nz/Style.html). Maintaining
+    [official tidyverse style](http://style.tidyverse.org). Maintaining
     a consistent style across the whole code base makes it much easier to
     jump into the code. If you're modifying existing ggplot2 code that
     doesn't follow the style guide, a separate pull request to fix the
@@ -103,17 +114,23 @@ Pull requests will be evaluated against a seven point checklist:
     can get with `install_github("klutometis/roxygen")`. This will be
     available on CRAN in the near future.
 
-<!--
 1.  If fixing a bug or adding a new feature to a non-graphical function,
-    please add a [testthat](https://github.com/hadley/testthat) unit test.
+    please add a [testthat](https://github.com/r-lib/testthat) unit test.
 
 1.  If fixing a bug in the visual output, please add a visual test.
     (Instructions to follow soon)
--->
 
 1.  If you're adding a new graphical feature, please add a short example
     to the appropriate function.
 
-This seems like a lot of work but don't worry if your pull request isn't perfect. It's a learning process and Winston and I will be on hand to help you out. A pull request is a process, and unless you've submitted a few in the past it's unlikely that your pull request will be accepted as is.
-
-Finally, remember that ggplot2 is a mature package used by thousands of people. This means that it's extremely difficult (i.e. impossible) to change any existing functionality without breaking someone's code (or another package on CRAN). Please don't submit pull requests that change existing behaviour. Instead, think about how you can add a new feature in a minimally invasive way.
+This seems like a lot of work but don't worry if your pull request isn't perfect.
+It's a learning process and members of the ggplot2 team will be on hand to help you out. A pull request is a process, and unless you've submitted a few in the past 
+it's unlikely that your pull request will be accepted as is. All PRs require 
+review and approval from at least one member of the ggplot2 development team 
+before merge.
+
+Finally, remember that ggplot2 is a mature package used by thousands of people. 
+This means that it's extremely difficult (i.e. impossible) to change any existing
+functionality without breaking someone's code (or another package on CRAN). 
+Please don't submit pull requests that change existing behaviour. Instead, 
+think about how you can add a new feature in a minimally invasive way.

GOVERNANCE.md

@@ -0,0 +1,43 @@
+<!-- This is heavily adapted version of
+the Benevolent dictator governance model by Ross
+Gardler and Gabriel Hanganu licensed under a Creative Commons 
+Attribution-ShareAlike 4.0 International License. -->
+
+# Overview
+This project is led by a benevolent dictator and managed by a core team of developers and a large community of contributors and users. That is, the community and core developers actively contribute to the day-to-day maintenance of the project, but the general strategic line is drawn by the benevolent dictator. In case of disagreement, they have the last word.
+
+# Roles And Responsibilities
+## Benevolent dictator (Hadley Wickham, @hadley)
+The job of the benevolent dictator is to set the strategic objectives of the project and communicate these clearly to the community, ensuring that the project survives in the long term. 
+
+## [Core Developers](https://github.com/orgs/tidyverse/teams/ggplot2)
+Core developers are contributors who have made several valuable contributions to the project and are now relied upon to both write code directly to the repository and screen the contributions of others. Core developers are empowered to merge pull requests after careful review. Core developers have no authority over the overall direction of the project, however it is their job to help develop or elicit appropriate contributions to the project. As a matter of policy, core developers, even if no longer active, are listed as [package authors](https://ggplot2.tidyverse.org/authors.html).
+
+## Contributors
+Contributors are community members who make valuable contributions, such as those outlined in the list below, but generally do not have the authority to make direct changes to the project code. Instead, contributors can suggest changes to project code through the pull request process outlined in the project's [CONTRIBUTING](https://github.com/tidyverse/ggplot2/blob/master/CONTRIBUTING.md) document. 
+
+Anyone can become a contributor. There is no expectation of commitment to the project, no specific skill requirements and no selection process. To become a contributor, a community member simply has to perform one or more actions that are beneficial to the project.
+
+Most contributors will already be engaging with the project as users, but will also find themselves doing one or more of the following:
+
+- opening issues to report bugs or suggest new features
+- submitting PRs to implement new features, fix bugs, or improve documentation
+- commenting in open PRs or issues to help support users or contribute to discussion
+
+## Users
+Users are community members who have a need for the project. They are the most important members of the community: without them, the project would have no purpose. Anyone can be a user; there are no specific requirements.
+
+Users are encouraged to participate in the life of the project and the community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user activities include (but are not limited to):
+
+- evangelising about the project
+- informing developers of project strengths and weaknesses from a new user’s perspective
+- providing moral support (a ‘thank you’ goes a long way)
+
+Users who continue to engage with the project and its community will often find themselves becoming more and more involved. Such users may then go on to become contributors, as described above.
+
+# Decision-Making Process
+This project makes decisions according to a consensus model where suggestions
+are considered and discussed between the community and core developers. In case 
+of conflict, the project lead’s word is final. If the community chooses to question
+the wisdom of the actions of a core developer, the project lead can review their
+decision, and either uphold or reverse them.