Merge branches 'main' and 'main' of github.com:myteron/wg-best-practices-os-developers

Author: myteron

README.md

@@ -241,6 +241,16 @@ Formal specifications would be licensed under the
 [Community Specification License](https://github.com/CommunitySpecification/1.0)
 (though at this time we don't have any examples of that).
 
+## Reviewing translations
+
+We are _delighted_ that some are willing to help us translate materials
+to other languages. Please ensure all
+pull requests that add or modify translations are labeled with its language.
+Such pull requests (PRs) must be first
+reviewed and approved by a trusted translator.
+
+See [translations](docs/translations) for specific details.
+
 ## Charter
 
 Like all OpenSSF working groups, this working group reports to the

docs/Secure-Coding-Guide-for-Python/readme.md

@@ -1,5 +1,7 @@
 # Secure Coding One Stop Shop for Python
 
+> ⓘ  NOTE: This is a draft. Contributions welcome!
+
 An initiative by the OpenSSF to provide new Python programmers a resource to study secure coding in `CPython >= 3.9` with working code examples.
 
 Documentation is written in academic style to support security researchers while using plain English to cater for an international audience.
@@ -23,12 +25,12 @@ Every person writing code shall study the following:
 
 ## Secure Coding Standard for Python
 
-Code examples are written to explain security design with as little code as possible. __None__ of the code examples are intendet to be used 'as is' for production. Using the code is at your own risk!
+Code examples are written to explain security design with as little code as possible. __None__ of the code examples are intended to be used 'as is' for production. Using the code is at your own risk!
 
-__Code file naminng conventions:__
+__Code file naming conventions:__
 
-* `noncompliantXX.py`  anti-pattern.
-* `compliantXX.py` mitigation for mitigating or removal of __ONLY__ the described risk.
+* `noncompliantXX.py` anti-pattern, bad programming practice.
+* `compliantXX.py` mitigation or removal of __ONLY__ the described risk.
 * `exampleXX.py` to allow understanding the documented behaviour.
 
 It is __not production code__ and requires code-style or python best practices to be added such as:

docs/index.md

@@ -24,13 +24,17 @@ Note: You can also see the larger list of
 * [Security Scorecard](https://github.com/ossf/scorecard) - automated scoring of OSS projects
 * [OpenSSF Best Practices badge](https://www.bestpractices.dev/) - a way for Free/Libre/Open Source Software projects to show that they follow best practices (you can also see its [source code repository](https://github.com/coreinfrastructure/best-practices-badge)).
 
-## Future work
+## Ongoing work
 
 The OpenSSF Best Practices WG is working on many more materials, such as
 more educational materials through our education special interest group (SIG),
 compiler hardening guides,
 guidance about memory safety through our memory safety SIG, and so on.
 
+Examples of ongoing work include:
+
+* [Secure Coding One Stop Shop for Python](Secure-Coding-Guide-for-Python/readme.md)
+
 [Please join the OpenSSF Best Practices working group if you're interested in helping](https://github.com/ossf/wg-best-practices-os-developers)!
 
 Please also see the

docs/translations.md

@@ -0,0 +1,45 @@
+# Translations
+
+We are *delighted* that people are willing to work to translate materials
+into various languages such as Japanese. Here is how we review translation PRs
+in this repo to ensure translations are good ones.
+
+## Translation review process
+
+To ensure that translations are good ones:
+
+1. All pull requests (PRs) that add or modify a translation
+   *must* be labeled as such.
+   The label is the language name, e.g., "Japanese" for Japanese.
+   Anyone can add that label, including the originator,
+   if the repository permissions allow it.
+   This way, missing labels can be easily added.
+2. A member of the "trusted translation team" for that language
+   will review those PRs for translation accuracy. At least one
+   such member MUST approve the PR before it can be merged.
+   If the PR comes *from* one if its team members, it's presumed to be
+   approved by that team.
+   If the label is wrong, a trusted translation team member
+   should remove the label.
+3. Someone else will also review the PR for any other issues,
+   using the usual review processes, and indicate it's approved
+   if it's approved.
+
+Whenever both a trusted translation team member approves (2) AND it's
+been approved otherwise (3), in any order, the PR can be merged.
+
+## Trusted translation team members
+
+Here are the trusted translation team members for each language,
+including their name and GitHub id.
+Any member of a trusted translation team can add other members to their team.
+
+The OpenSSF TAC or Best Practices WG can create and remove teams,
+and can add or remove members in such teams. In practice we expect anything
+other than creating a team to be rare events for them.
+
+### Japanese
+
+* Non KAWANA - ninan27
+* Muuhh IKEDA - Muuhh-CTJ
+* Taku SHIMOSAWA - shimos