diff --git a/docs/developers/contributing.md b/docs/developers/contributing.md
index 13f8e4429c6..d9871018f08 100644
--- a/docs/developers/contributing.md
+++ b/docs/developers/contributing.md
@@ -2,13 +2,12 @@
 
 New contributions to the library are welcome, but we ask that you please follow these guidelines:
 
-- Use tabs for indentation, not spaces.
-- Only change the individual files in `/src`.
-- Check that your code will pass `eslint` code standards, `gulp lint` will run this for you.
-- Check that your code will pass tests, `gulp test` will run tests for you.
-- Keep pull requests concise, and document new functionality in the relevant `.md` file.
+- Before opening a PR for major architectural changes, refactorings, or introduction of major features or API changes, please discuss the expected API and/or implementation. [File an issue](https://github.com/chartjs/Chart.js/issues) or ask about it in the [Chart.js Slack](https://chartjs-slack.herokuapp.com/) #dev channel. This will save you development time by getting feedback upfront and make review faster by giving the maintainers more context and details.
 - Consider whether your changes are useful for all users, or if creating a Chart.js [plugin](plugins.md) would be more appropriate.
-- Avoid breaking changes unless there is an upcoming major release, which are infrequent. We encourage people to write plugins for most new advanced features, so care a lot about backwards compatibility.
+- Check that your code will pass tests and `eslint` code standards. `gulp test` will run both the linter and tests for you.
+- Add unit tests and document new functionality (in the `test/` and `docs/` directories respectively).
+- Avoid breaking changes unless there is an upcoming major release, which are infrequent. We encourage people to write plugins for most new advanced features, and care a lot about backwards compatibility.
+- We strongly prefer new methods to be added as private whenever possible. A method can be made private either by making a top-level `function` outside of a class or by prefixing it with `_` and adding `@private` JSDoc if inside a class. Public APIs take considerable time to review and become locked once implemented as we have limited ability to change them without breaking backwards compatibility. Private APIs allow the flexibility to address unforeseen cases.
 
 # Joining the project