Merge branch 'master' of github.com:tidyverse/ggplot2

Author: hadley

.github/CODE_OF_CONDUCT.md

@@ -18,7 +18,7 @@ Code of Conduct. Project maintainers who do not follow the Code of Conduct may b
 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.
+opening an issue, emailing the project lead (<hadley@rstudio.com>), or one of the core developers.
 
 This Code of Conduct is adapted from the Contributor Covenant 
 (http://contributor-covenant.org), version 1.0.0, available at 

GOVERNANCE.md

@@ -3,43 +3,58 @@ 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
 
-# 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. 
+This project has a large community of __users__ and __contributors__, a team of __core developers__, and a __project lead__.
 
-## [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 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 (chronologically) in [package authors](https://ggplot2.tidyverse.org/authors.html).
+## Users
+
+People who create visualizations with ggplot2 are the most important members of the community; without these users, this project would have no purpose.
+
+Users are encouraged to participate in the life of the project and the community as much as possible. User contributions help ensure that the project is satisfying users' needs. Common user activities include (but are not limited to):
+
+- evangelising about the project
+- asking and answering on community forums
+- providing moral support (a 'thank you' goes a long way)
 
-An invitation to join the core team will be extended to contributors who have made a major contributions as a contributor. For example, they have added a major new feature or have a consistent pattern of smaller contributions over an extended period of time. Any existing core developer can propose a contributor be invited to the core team, pending confirmation by existing authors.
+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.
 
 ## 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.
+Contributors interact with the project on GitHub by filing new issues, improving existing issues, or submitting pull requests. Anyone can become a contributor: there is no expectation of commitment to the project, no required set of skills, and no selection process. The only obligation is to follow the [code of conduct](CODE_OF_CONDUCT.md).
 
-Most contributors will already be engaging with the project as users, but will also find themselves doing one or more of the following:
+Specific advice for contributing to the project can be found in
+[CONTRIBUTING.md](https://github.com/tidyverse/ggplot2/blob/master/CONTRIBUTING.md).
 
-- 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
+## Core developers
 
-## 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.
+Core developers are collectively responsible for day-to-day development of the package, including responding to issues and reviewing pull requests. They are GitHub administrators and [package authors](https://github.com/tidyverse/ggplot2/blob/master/DESCRIPTION#L8), which means that they have the ability to make changes to project code, and receive credit when others cite the package.
 
-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):
+While core developers can modify code directly, this ability is rarely used. Instead, changes are proposed as pull requests, and are only merged after they have been reviewed by at least one other core developer. Changes to the API (especially breaking changes) must also be approved by the project lead. 
 
-- 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)
+Core developers are recruited from contributors. An invitation to join the core team can be extended to anyone who has made a major contribution, either through a small number of large changes, or a consistent pattern of smaller contributions. Any existing core developer can propose a contributor be invited to the core team by emailing the project lead. The project lead will the confirm the invitation with the other core developers.
 
-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.
+The core developers of ggplot2 are:
+
+* [Winston Chang](https://github.com/wch)
+* [Lionel Henry](https://github.com/lionel-)
+* [Thomas Lin Pedersen](https://github.com/thomasp85)
+* [Kohske Takahashi](https://github.com/kohske)
+* [Claus Wilke](https://github.com/clauswilke)
+* [Kara Woo](https://github.com/karawoo)
+
+All core developers are bound by the [code of conduct](CODE_OF_CONDUCT.md).
+
+## Project lead
+
+The project lead, [Hadley Wickham](http://github.com/hadley), is responsible for:
+
+* Setting, and clearly communication the strategic objectives of the project.
+* Mediating any conflicts amongst the core developers.
+* Ensuring that the project survives in the long term.
+
+The project lead is bound by the [code of conduct](CODE_OF_CONDUCT.md).
+
+# Decision-making process
 
-# 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.
+This project makes decisions according to a consensus model where suggestions are considered and discussed between the community and core developers, typically in GitHub issues. Where consensus cannot be reached, the project lead's word is final. If the community questions a decision, the project lead may review it and either uphold or reverse it.