From 668f8691f1017042e238497d1a5b7b8bf1c43819 Mon Sep 17 00:00:00 2001 From: Matthew Draper Date: Sun, 9 Apr 2017 00:31:58 +0930 Subject: Remove mentions and instructions for docrails It's been retired; all contributions now come in via PRs. --- guides/source/api_documentation_guidelines.md | 4 ---- 1 file changed, 4 deletions(-) (limited to 'guides/source/api_documentation_guidelines.md') diff --git a/guides/source/api_documentation_guidelines.md b/guides/source/api_documentation_guidelines.md index 34b9c0d2ca..3c61754982 100644 --- a/guides/source/api_documentation_guidelines.md +++ b/guides/source/api_documentation_guidelines.md @@ -333,10 +333,6 @@ As a contributor, it's important to think about whether this API is meant for en A class or module is marked with `:nodoc:` to indicate that all methods are internal API and should never be used directly. -If you come across an existing `:nodoc:` you should tread lightly. Consider asking someone from the core team or author of the code before removing it. This should almost always happen through a pull request instead of the docrails project. - -A `:nodoc:` should never be added simply because a method or class is missing documentation. There may be an instance where an internal public method wasn't given a `:nodoc:` by mistake, for example when switching a method from private to public visibility. When this happens it should be discussed over a PR on a case-by-case basis and never committed directly to docrails. - To summarize, the Rails team uses `:nodoc:` to mark publicly visible methods and classes for internal use; changes to the visibility of API should be considered carefully and discussed over a pull request first. Regarding the Rails Stack -- cgit v1.2.3