Updates to Stable component process.

[artursouza]

Signed-off-by: Artur Souza [email protected]

Thank you for helping make the Dapr documentation better!

Please follow this checklist before submitting:

• [ ] Commits are signed with Developer Certificate of Origin (DCO - learn more)
• [ ] Read the contribution guide
• [ ] Commands include options for Linux, MacOS, and Windows within codetabs
• [ ] New file and folder names are globally unique
• [ ] Page references use shortcodes instead of markdown or URL links
• [ ] Images use HTML style and have alternative text
• [ ] Places where multiple code/command options are given have codetabs

In addition, please fill out the following to help reviewers understand this pull request:

Description

Adds stable candidate step. Changes requirement from 1 to 2 approvers for component to be stable.

Issue reference

[msfussell]

Have all Component Contrib maintainers agreed to this?

[github-actions[bot]]

Stale PR, paging all reviewers

[berndverst]

I would say we should get the approval of two contrib maintainers to call something stable, but needing to maintainers to merge a PR in certification tests doesn't seem like a good idea.

We should refine the details a little bit here.

Can we have a yaml file at the root of contrib where we track what is stable and then require two maintainers to modify that file?

[greenie-msft]

@berndverst, @artursouza, @yaron2 - have we come to an agreement here with how to handle stable candidates

[berndverst]

@greenie-msft we have not - we need to separately discuss this. And that does not need to happen timed with release 1.8

Personally I think we should do this:

• Keep a file in the contrib repo of stable components. Modifying that file requires 2 maintainers to approve / author the PR.
• Certification tests themselves however will continue to require one maintainer as before. This is important because I want to decouple the development (especially iterative development) of certification tests from the actual stable certification.

[msfussell]

@greenie-msft we have not - we need to separately discuss this. And that does not need to happen timed with release 1.8

Personally I think we should do this:

• Keep a file in the contrib repo of stable components. Modifying that file requires 2 maintainers to approve / author the PR.
• Certification tests themselves however will continue to require one maintainer as before. This is important because I want to decouple the development (especially iterative development) of certification tests from the actual stable certification.

For the first point, can we use these https://github.com/dapr/docs/tree/v1.7/daprdocs/data/components since this is what John did this for in the docs?

[berndverst]

@greenie-msft we have not - we need to separately discuss this. And that does not need to happen timed with release 1.8 Personally I think we should do this:

• Keep a file in the contrib repo of stable components. Modifying that file requires 2 maintainers to approve / author the PR.
• Certification tests themselves however will continue to require one maintainer as before. This is important because I want to decouple the development (especially iterative development) of certification tests from the actual stable certification.

For the first point, can we use these https://github.com/dapr/docs/tree/v1.7/daprdocs/data/components since this is what John did this for in the docs?

@greenie-msft I really want that to be separate from documentation that is shown. It should be more of an internal file to keep track of technical decision-making.

As long as we set up the permissions such that ONLY contrib maintainers can provide reviews and approvals for that file (via CODEOWNERS) I'm fine with having this anywhere. Even Docs maintainers should not be allowed to approve changes to this. That's the entire point - our tooling must enforce that two contrib maintainers are involved.

[github-actions[bot]]

Stale PR, paging all reviewers

[artursouza]

This is not applicable anymore since we do not require stable candidates.