Clarifying documentation requirements now that GoReportCard no longer checks for documentation formatting. (#4173)

This commit is contained in:
Shannon 2022-04-11 15:53:26 -07:00 committed by GitHub
parent 12db3ff8ec
commit 94d76c321c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -23,10 +23,10 @@ To be on the list, project repositories should adhere to the following quality s
- function as documented and expected;
- be generally useful to the wider community of Go programmers;
- be actively maintained with:
- Regular, recent commits;
- Or, for finished projects, issues and pull requests are responded to generally within 2 weeks;
- regular, recent commits;
- or, for finished projects, issues and pull requests are responded to generally within 2 weeks;
- be stable or progressing toward stable;
- be thoroughly documented (README, pkg.go.dev doc comments, etc.) in the english language, so everyone is able to understand the project's intention and how it works;
- be thoroughly documented (README, pkg.go.dev doc comments, etc.) in the english language, so everyone is able to understand the project's intention and how it works. All public functions and types should have a Go style documentation header;
- if the library/program is testable, then coverage should be >= 80% for non-data-related packages and >=90% for data related packages. (**Note**: the tests will be reviewed too. We will check your coverage manually if your package's coverage is just a benchmark results);
- have at least one official version-numbered release that allows go.mod files to list the file by version number, of the form vX.X.X.