open-feature
/
community
mirror of https://github.com/open-feature/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs: fix links in tech guide, add to sidebar 

Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
This commit is contained in:
Michael Beemer 2024-04-24 16:17:48 -04:00
parent 7811a45d85
commit a80f1134e4
No known key found for this signature in database
GPG Key ID: 47B734C8FDEE96EE
2 changed files with 38 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
docusaurus-sidebar.js
View File

@ -4,59 +4,63 @@
const sidebarCommunity = { const sidebarCommunity = {
community: [ community: [
{ {
type: "doc", type: 'doc',
id: "README", id: 'README',
label: "Overview", label: 'Overview',
}, },
{ {
type: "doc", type: 'doc',
id: "mission-vision", id: 'mission-vision',
}, },
{ {
type: "doc", type: 'doc',
id: "CONTRIBUTOR_LADDER", id: 'CONTRIBUTOR_LADDER',
}, },
{ {
type: "doc", type: 'doc',
id: "community-members", id: 'community-members',
label: "Members", label: 'Members',
}, },
{ {
type: "category", type: 'category',
label: "Charters", label: 'Charters',
collapsible: false, collapsible: false,
items: [ items: [
{ {
type: "doc", type: 'doc',
id: "governance-charter", id: 'governance-charter',
}, },
{ {
type: "doc", type: 'doc',
id: "tech-committee-charter", id: 'tech-committee-charter',
}, },
], ],
}, },
{ {
type: "doc", type: 'doc',
id: "interested-parties", id: 'interested-parties',
}, },
{ {
type: "doc", type: 'doc',
id: "ADOPTERS", id: 'ADOPTERS',
label: "Adopters", label: 'Adopters',
}, },
{ {
type: "doc", type: 'doc',
id: "presentations", id: 'presentations',
}, },
{ {
type: "doc", type: 'doc',
id: "branding-guidelines", id: 'branding-guidelines',
}, },
{ {
type: "doc", type: 'doc',
id: "SECURITY", id: 'technical-guidelines',
},
{
type: 'doc',
id: 'SECURITY',
}, },
], ],
}; };

14
technical-guidelines.md
View File

@ -50,7 +50,7 @@ Adherence to these guidelines is required for 1.0 artifact releases, to the sati
| unit, integration testing | github actions (with permissions applying principle of least privilege), language-specific tools (JUnit, Jest, etc), [Cucumber][cucumber] | required, with coverage metrics up to maintainer discretion | | unit, integration testing | github actions (with permissions applying principle of least privilege), language-specific tools (JUnit, Jest, etc), [Cucumber][cucumber] | required, with coverage metrics up to maintainer discretion |
| signing (binaries, packages, container images) | language-specific tools, [cosign][cosign] | recommended, where supported | | signing (binaries, packages, container images) | language-specific tools, [cosign][cosign] | recommended, where supported |
| fuzzing | [ClusterFuzzLite][clusterfuzzlite], [OSS-Fuzz][oss-fuzz] | recommended | | fuzzing | [ClusterFuzzLite][clusterfuzzlite], [OSS-Fuzz][oss-fuzz] | recommended |
| helpful readme file | See [example README.md](./templates/READMEs/README.md) | recommended | | helpful readme file | See [example README.md](https://github.com/open-feature/.github/blob/main/templates/READMEs/README.md) | recommended |
| provenance | [SLSA](https://slsa.dev/spec/v1.0/provenance#provenance) | recommended | | provenance | [SLSA](https://slsa.dev/spec/v1.0/provenance#provenance) | recommended |
| SBOM generation | [CycloneDX][cyclonedx], [SPDX][spdx], [syft][syft] | recommended | | SBOM generation | [CycloneDX][cyclonedx], [SPDX][spdx], [syft][syft] | recommended |
| static analysis | [SonarCloud][sonarcloud], language-specific tools (SpotBugs, eslint) | recommended | | static analysis | [SonarCloud][sonarcloud], language-specific tools (SpotBugs, eslint) | recommended |
@ -71,13 +71,13 @@ Consistent and prolonged failure to satisfy the above requirements may result in
## Semantic Versioning and 1.0 Releases ## Semantic Versioning and 1.0 Releases
We require release artifacts to adhere to [semantic versioning](https://semver.org/) except in specific cases approved by the [Technical Steering Committee](https://github.com/open-feature/community/blob/main/community-members.md#technical-committee). We require release artifacts to adhere to [semantic versioning](https://semver.org/) except in specific cases approved by the [Technical Steering Committee](./community-members.md#technical-committee).
1.0 releases must satisfy the [repository requirements](#repository-requirements) above. 1.0 releases must satisfy the [repository requirements](#repository-requirements) above.
If the artifact is an SDK implementing the OpenFeature specification, it must also conform to a version of the OpenFeature specification not less than 2 minor versions behind the latest (ex: if the latest OpenFeature specification is `0.8.1`, then an implementation conforming to `0.6.0` is a candidate for `1.0` release, while an implementation conforming only to `0.5.0` is not). If the artifact is an SDK implementing the OpenFeature specification, it must also conform to a version of the OpenFeature specification not less than 2 minor versions behind the latest (ex: if the latest OpenFeature specification is `0.8.1`, then an implementation conforming to `0.6.0` is a candidate for `1.0` release, while an implementation conforming only to `0.5.0` is not).
This policy may be subject to change with the release of the OpenFeature specification version `1.0.0`. This policy may be subject to change with the release of the OpenFeature specification version `1.0.0`.
> [!IMPORTANT] > [!IMPORTANT]
> While the OpenFeature specification version is <`1.0`, it's possible breaking changes will be introduced. > While the OpenFeature specification version is < `1.0`, it's possible breaking changes will be introduced.
> This may necessitate that SDKs which have released `1.0` versions, release `2.0` versions in order to adhere to breaking specification changes. > This may necessitate that SDKs which have released `1.0` versions, release `2.0` versions in order to adhere to breaking specification changes.
> [!IMPORTANT] > [!IMPORTANT]
@ -97,7 +97,7 @@ If such changes are necessary, please consider the following:
* For example, if you are releasing a `2.0.0`, maintain a `v1` branch. * For example, if you are releasing a `2.0.0`, maintain a `v1` branch.
* [Release Please][release-please] can make maintenance and release of artifacts from such a branch easy; simply have the release-please action run on the branch, and target that branch for its PRs. * [Release Please][release-please] can make maintenance and release of artifacts from such a branch easy; simply have the release-please action run on the branch, and target that branch for its PRs.
Please consult with a member of the [TC](https://github.com/open-feature/community/blob/main/community-members.md#technical-committee) before making breaking changes to a `1.0+` component. Please consult with a member of the [TC](./community-members.md#technical-committee) before making breaking changes to a `1.0+` component.
## Platform Support ## Platform Support
@ -139,6 +139,6 @@ Please consult with a member of the [TC](https://github.com/open-feature/communi
[syft]: https://github.com/anchore/syft [syft]: https://github.com/anchore/syft
[spdx]: https://spdx.dev/resources/tools/ [spdx]: https://spdx.dev/resources/tools/
[dependabot]: https://github.com/dependabot [dependabot]: https://github.com/dependabot
[conventional-commits]: [https://www.conventionalcommits.org/] [conventional-commits]: https://www.conventionalcommits.org/
[semantic-versioning]: [https://semver.org/] [semantic-versioning]: https://semver.org/
[release-please]: [https://github.com/googleapis/release-please] [release-please]: https://github.com/googleapis/release-please