Describe polling with ETag cachingsh-expand-on-definition-of-done

1 files changed, 3 insertions, 2 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 9a6e3feec4c..ae143c58290 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -403,8 +403,8 @@ There are a few rules to get your merge request accepted:
    - Avoid repeated polling of endpoints that require a significant amount of overhead
    - Check for N+1 queries via the SQL log or [`QueryRecorder`](https://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
    - Avoid repeated access of filesystem
-1. If you need polling to support real-time features, consider using this [described long
-   polling approach](https://gitlab.com/gitlab-org/gitlab-ce/issues/26926).
+1. If you need polling to support real-time features, please use
+   [polling with ETag caching][polling-etag].
 1. Changes after submitting the merge request should be in separate commits
    (no squashing). If necessary, you will be asked to squash when the review is
    over, before merging.
@@ -547,6 +547,7 @@ available at [http://contributor-covenant.org/version/1/1/0/](http://contributor
 [UX Guide for GitLab]: http://docs.gitlab.com/ce/development/ux_guide/
 [license-finder-doc]: doc/development/licensing.md
 [GitLab Inc engineering workflow]: https://about.gitlab.com/handbook/engineering/workflow/#labelling-issues
+[polling-etag]: https://docs.gitlab.com/ce/development/polling.html
 
 [^1]: Specs other than JavaScript specs are considered backend code. Haml
       changes are considered backend code if they include Ruby code other than just