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

View File

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

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 |
| signing (binaries, packages, container images) | language-specific tools, [cosign][cosign] | recommended, where supported |
| 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 |
| SBOM generation | [CycloneDX][cyclonedx], [SPDX][spdx], [syft][syft] | 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
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.
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`.
> [!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.
> [!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.
* [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
@ -139,6 +139,6 @@ Please consult with a member of the [TC](https://github.com/open-feature/communi
[syft]: https://github.com/anchore/syft
[spdx]: https://spdx.dev/resources/tools/
[dependabot]: https://github.com/dependabot
[conventional-commits]: [https://www.conventionalcommits.org/]
[semantic-versioning]: [https://semver.org/]
[release-please]: [https://github.com/googleapis/release-please]
[conventional-commits]: https://www.conventionalcommits.org/
[semantic-versioning]: https://semver.org/
[release-please]: https://github.com/googleapis/release-please