From 5a2c760306fe8e66562094aceaca8b9923ecc08d Mon Sep 17 00:00:00 2001 From: "Tim St. Clair" Date: Mon, 8 Feb 2016 16:17:41 -0800 Subject: [PATCH] Add issue tracking documentation, move development documents to subdir --- docs/development/README.md | 3 ++ docs/{ => development}/build.md | 0 docs/{ => development}/integration_testing.md | 0 docs/development/issues.md | 30 +++++++++++++++++++ 4 files changed, 33 insertions(+) create mode 100644 docs/development/README.md rename docs/{ => development}/build.md (100%) rename docs/{ => development}/integration_testing.md (100%) create mode 100644 docs/development/issues.md diff --git a/docs/development/README.md b/docs/development/README.md new file mode 100644 index 00000000..3bd426ae --- /dev/null +++ b/docs/development/README.md @@ -0,0 +1,3 @@ +The [development](./) directory holds documentation for cAdvisor developers and contributors. If you +are looking for development using cAdvisor (as opposed to development of cAdvisor), then these +documents probably don't apply to you. diff --git a/docs/build.md b/docs/development/build.md similarity index 100% rename from docs/build.md rename to docs/development/build.md diff --git a/docs/integration_testing.md b/docs/development/integration_testing.md similarity index 100% rename from docs/integration_testing.md rename to docs/development/integration_testing.md diff --git a/docs/development/issues.md b/docs/development/issues.md new file mode 100644 index 00000000..26f47ad1 --- /dev/null +++ b/docs/development/issues.md @@ -0,0 +1,30 @@ +# GitHub Issue tracking cAdvisor + +This document outlines the process around GitHub issue tracking for cAdvisor at https://github.com/google/cadvisor/issues + +## Labels + +A brief explanation of what issue labels mean. Most labels also apply to pull requests, but for pull +requests which reference an issue, it is not necessary to copy the same labels to the PR. + +- `area/API` - For issues related to the API. +- `area/UI` - For issues related to the web UI. +- `area/documentation` - For issues related to the documentation (inline comments or markdown). +- `area/performance` - For issues related to cAdvisor performance (speed, memory, etc.). +- `area/storage` - For issues related to cAdvisor storage plugins. +- `area/testing` - For issues related to testing (integration tests, unit tests, jenkins, etc.) +- `closed/duplicate` - For issues which have been closed as duplicates of another issue. The final + comment on the issue should hold a reference the duplicate issue. +- `closed/infeasible` - For issues which cannot be resolved (e.g. a request for a feature we cannot + or do not want to add). +- `community-assigned` - For issues which are being worked on by a community member (when github won't let us assign the issue to them). +- `kind/bug` - For issues referring to a bug in the existing implementation. +- `kind/enhancement` - For issues proposing an enhancement or new feature. +- `kind/support` - For issues which might just be user confusion / environment setup. If support + issue ends up requiring a PR, it should probably be relabeled (for example, to `bug`). Many + support issues may indicate a shortcoming of the documentation. +- `help wanted` - For issues which have been highlighted as a good place to contribute to + cAdvisor. `help wanted` issues could be enhancements that the core team is unlikely to get to in + the near future, or small projects which might be a good starting point. Lack of a `help wanted` + label does not mean we won't accept contributions, it only means it was not identified as a + candidate project for community contributions.