github.com/google/cadvisor@v0.49.1/docs/development/issues.md (about)

     1  # GitHub Issue tracking cAdvisor
     2  
     3  This document outlines the process around GitHub issue tracking for cAdvisor at https://github.com/google/cadvisor/issues
     4  
     5  ## Labels
     6  
     7  A brief explanation of what issue labels mean. Most labels also apply to pull requests, but for pull
     8  requests which reference an issue, it is not necessary to copy the same labels to the PR.
     9  
    10  - `area/API` - For issues related to the API.
    11  - `area/UI` - For issues related to the web UI.
    12  - `area/documentation` - For issues related to the documentation (inline comments or markdown).
    13  - `area/performance` - For issues related to cAdvisor performance (speed, memory, etc.).
    14  - `area/storage` - For issues related to cAdvisor storage plugins.
    15  - `area/testing` - For issues related to testing (integration tests, unit tests, jenkins, etc.)
    16  - `closed/duplicate` - For issues which have been closed as duplicates of another issue. The final
    17    comment on the issue should hold a reference the duplicate issue.
    18  - `closed/infeasible` - For issues which cannot be resolved (e.g. a request for a feature we cannot
    19    or do not want to add).
    20  - `community-assigned` - For issues which are being worked on by a community member (when github won't let us assign the issue to them).
    21  - `kind/bug` - For issues referring to a bug in the existing implementation.
    22  - `kind/enhancement` - For issues proposing an enhancement or new feature.
    23  - `kind/support` - For issues which might just be user confusion / environment setup. If support
    24    issue ends up requiring a PR, it should probably be relabeled (for example, to `bug`). Many
    25    support issues may indicate a shortcoming of the documentation.
    26  - `help wanted` - For issues which have been highlighted as a good place to contribute to
    27    cAdvisor. `help wanted` issues could be enhancements that the core team is unlikely to get to in
    28    the near future, or small projects which might be a good starting point. Lack of a `help wanted`
    29    label does not mean we won't accept contributions, it only means it was not identified as a
    30    candidate project for community contributions.