From 24a627f6b536106d45e460e1bb186dec4069e81f Mon Sep 17 00:00:00 2001 From: Michael Tautschnig Date: Thu, 12 Dec 2024 18:22:07 +0000 Subject: [PATCH 1/3] Add review guidelines Extends committee membership information with guidance on what is expected of committee members. --- doc/src/general-rules.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/doc/src/general-rules.md b/doc/src/general-rules.md index b56ddc7e7d778..131f7dc1e0753 100644 --- a/doc/src/general-rules.md +++ b/doc/src/general-rules.md @@ -92,3 +92,18 @@ members = [ + "rahulku" ] ``` + +Committee members are expected to contribute by reviewing pull requests (all +pull requests review approvals from at least two committee members before they +can be merged). +Reviews of solutions towards challenges should consider at least the following aspects: + +1. Does the pull request implement a solution that respects/meets the success + criteria of the challenge? +2. Do the contracts and harnesses incorporate the safety conditions stated in + the documentation (from comments in the code and Rust book)? Note that we + currently focus on safety verification. Pre- and post-conditions towards + functional correctness are acceptable as long as they do not negatively + impact verification of safety, such as over-constraining input values. +3. Is the contributed code of adequate quality and idiomatic (to the best of the + committee member's knowledge). From e65322e502e75c448a307c6711ac611c315f8ade Mon Sep 17 00:00:00 2001 From: Michael Tautschnig Date: Thu, 12 Dec 2024 20:41:31 +0100 Subject: [PATCH 2/3] Update doc/src/general-rules.md Co-authored-by: Carolyn Zech --- doc/src/general-rules.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/general-rules.md b/doc/src/general-rules.md index 131f7dc1e0753..53d96a13b44ee 100644 --- a/doc/src/general-rules.md +++ b/doc/src/general-rules.md @@ -101,7 +101,7 @@ Reviews of solutions towards challenges should consider at least the following a 1. Does the pull request implement a solution that respects/meets the success criteria of the challenge? 2. Do the contracts and harnesses incorporate the safety conditions stated in - the documentation (from comments in the code and Rust book)? Note that we + the documentation (from comments in the code and the [standard library documentation](https://doc.rust-lang.org/std/index.html))? Note that we currently focus on safety verification. Pre- and post-conditions towards functional correctness are acceptable as long as they do not negatively impact verification of safety, such as over-constraining input values. From f47d83c7636ca44755c3ea2f190bb69eaf47ee5e Mon Sep 17 00:00:00 2001 From: Michael Tautschnig Date: Thu, 12 Dec 2024 19:44:32 +0000 Subject: [PATCH 3/3] Apply suggestions --- doc/src/general-rules.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/doc/src/general-rules.md b/doc/src/general-rules.md index 53d96a13b44ee..b5cc9604e4b35 100644 --- a/doc/src/general-rules.md +++ b/doc/src/general-rules.md @@ -101,9 +101,12 @@ Reviews of solutions towards challenges should consider at least the following a 1. Does the pull request implement a solution that respects/meets the success criteria of the challenge? 2. Do the contracts and harnesses incorporate the safety conditions stated in - the documentation (from comments in the code and the [standard library documentation](https://doc.rust-lang.org/std/index.html))? Note that we - currently focus on safety verification. Pre- and post-conditions towards - functional correctness are acceptable as long as they do not negatively - impact verification of safety, such as over-constraining input values. -3. Is the contributed code of adequate quality and idiomatic (to the best of the - committee member's knowledge). + the documentation (from comments in the code and the + [standard library documentation](https://doc.rust-lang.org/std/index.html))? + Note that we currently focus on safety verification. Pre- and post-conditions + towards functional correctness are acceptable as long as they do not + negatively impact verification of safety, such as over-constraining input + values or causing excessive verification run time. +3. Is the contributed code of adequate quality, idiomatic, and stands a chance + to be accepted into the standard library (to the best of the committee + member's knowledge)?