From d838c887d658901f02220ef3040080a3d4595e4c Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Tue, 21 Oct 2025 18:41:01 +0900 Subject: [PATCH 01/11] Add RFC about contribution --- text/0000-contribution.md | 149 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 text/0000-contribution.md diff --git a/text/0000-contribution.md b/text/0000-contribution.md new file mode 100644 index 0000000..e0fb77a --- /dev/null +++ b/text/0000-contribution.md @@ -0,0 +1,149 @@ +- Start Date: 2023-12-18 - RFC PR: N/A - STD Issue: +[github.com/FLOSS-uz/standards/issues/8](https://github.com/FLOSS-uz/standards/issues/8) +- Severity: MUST + +# Summary + +This RFC proposes a standardized framework for technology-specific communities +(e.g., Rust, NixOS, Dotnet) within FLOSS Uzbekistan to overcome stagnation +and increase member engagement. It mandates the implementation of clear +contribution paths, structured onboarding processes, active support mechanisms, +and systematic contributor recognition to transform passive groups into +active, collaborative hubs. + +# Motivation + +Many technology-focused communities in the Uzbek IT ecosystem suffer from low +engagement, lack of clear contribution paths, and high newcomer abandonment +rates. For FLOSS Uzbekistan to become a mature ecosystem, its constituent +communities must be active and self-sustaining. This standard provides a +principled set of requirements to guide these communities in creating a +welcoming, purpose-driven, and rewarding environment that converts curious +members into active contributors. + +# Detailed design + +All member communities of FLOSS Uzbekistan MUST implement the following four +pillars of engagement: + +## 1. Defining Purpose and Diverse Contribution Paths + +Every community **MUST** define a clear, local focus beyond the core +technology itself. + +- **Local Project Focus (MUST):** The community **MUST** identify, initiate, +or actively contribute to at least one **local, manageable project**. This +project should have relevance to the Uzbek developer context (e.g., a +localized tool, an open-source library for common Uzbek tasks, or a simple +web application for local impact). + +- **Diverse Contribution Paths (MUST):** Community leadership +**MUST** explicitly define and document contribution paths that are +**non-code-centric**. These paths **MUST** include: + + - **Translation:** Contribution to localizing documentation/tutorials + into Uzbek. + + - **Content Creation:** Writing tutorials, articles, or creating video + content about the technology. + + - **Community Management:** Responsibilities for organizing events, + moderation, and newcomer welcoming. + +- **Local Resource Curation (MUST):** The community **MUST** gather and +maintain a curated, public list of local open-source projects using their +technology (e.g., an "Awesome-Rust-Uzbekistan" list). This resource serves +as both a contribution path and a local showcase. + +## 2. Streamlined Onboarding and First Contributions + +The community **MUST** optimize the initial experience for new members. + +- **Newcomer's Guide (MUST):** The community **MUST** maintain a clear, concise +**"Newcomer's Guide"** (preferably in Uzbek) that includes: an overview of +the technology, the community's purpose, a roadmap for installation/setup, +a breakdown of all key community platforms (GitHub, Telegram), and a list +of entry-level tasks. + +- **"Good First Issue" Labelling (MUST):** Maintainers **MUST** actively +label a revolving set of simple, well-defined issues (e.g., typo fixes, +documentation updates, minor code cleanups) with a `Good First Issue` tag +on their main project repositories. + +- **Mentorship Program (SHOULD):** The community SHOULD establish an informal +mentorship program to pair experienced developers with new members for +personalized guidance. + + +## 3. Cultivating Active Communication and Support + +Community leadership **MUST** foster a positive, responsive, and collaborative +environment. + +- **Responsiveness (MUST):** Community leaders and experienced members +**MUST** be quick to respond to questions in public channels. A clearly +defined acceptable response time for general queries SHOULD be established. + +- **Public Discussion (MUST):** All substantial technical discussions, +debates, and decision-making **MUST** be promoted and conducted in public +community chats or on GitHub to ensure transparency and allow the entire +community to learn. + +- **Regular Collaborative Events (MUST):** The community **MUST** host +regular scheduled events (online or in-person) such as: + + +## 4. Recognition and Incentives + +The community **MUST** establish a formal mechanism for acknowledging and +rewarding contributions. + +- **Public Recognition (MUST):** Community leadership **MUST** regularly and +publicly highlight contributions (code, documentation, support, organization) +in community announcements, social media, or newsletters. + +- **Recognition System (SHOULD):** The community **SHOULD** implement a +system for formal acknowledgment, such as: + + - **Contributor Badges/Roles:** Digital badges or special roles in chat + platforms (e.g., "Documentation Contributor," "Active Helper"). + + - **Gamification:** Small, monetary or non-monetary incentives or public + leaderboards for answering questions or completing specific tasks. + +# Guide-level explanation + +To revitalize your community: + +1. **Start a Project:** Pick a simple, local problem (e.g., a public Telegram +bot for common Uzbek tech questions) and declare it your community's official +project. This gives everyone a place to contribute. + +2. **Document EVERYTHING:** Create a `Newcomers Guide` (in Uzbek) that +tells a new member exactly what to do first. Then, make sure your project +has issues labelled `Good First Issue`. + +3. **Be Visible and Helpful:** Make sure questions in your main chat don't +go unanswered for hours. + +4. **Celebrate:** When someone submits a pull request, fixes a bug, or even +just answers a difficult question in the chat, **publicly thank them**. Use +your community's social channels to showcase their work. + + +# Unresolved questions + +1. What metrics will be used by the FLOSS Uzbekistan council to measure a +community's compliance and progress in implementing this standard (e.g., +PR activity, event frequency, responsiveness score)? + +2. Should the FLOSS Uzbekistan council provide template documents for +the "Newcomer's Guide" or "Good First Issue" practices to accelerate +implementation? + +# Future possibilities + +A future RFC could establish a **"Community Health Review"** process where +the council periodically audits member communities based on the metrics +developed from this standard. This could lead to a **"FLOSS Uzbekistan Active +Community"** certification or similar system of endorsement. From 0987a8ee0e6dbcd2effb603241b9b7df93dbcbe4 Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Tue, 21 Oct 2025 18:43:41 +0900 Subject: [PATCH 02/11] Fix header formatting --- text/0000-contribution.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/text/0000-contribution.md b/text/0000-contribution.md index e0fb77a..76f1d8b 100644 --- a/text/0000-contribution.md +++ b/text/0000-contribution.md @@ -1,5 +1,6 @@ -- Start Date: 2023-12-18 - RFC PR: N/A - STD Issue: -[github.com/FLOSS-uz/standards/issues/8](https://github.com/FLOSS-uz/standards/issues/8) +- Start Date: 2023-12-18 +- RFC PR: N/A +- STD Issue: [github.com/FLOSS-uz/standards/issues/8](https://github.com/FLOSS-uz/standards/issues/8) - Severity: MUST # Summary From 43d0a6bb4bd03ad6d030a10fb1f8caa66bf547b3 Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Tue, 21 Oct 2025 18:59:44 +0900 Subject: [PATCH 03/11] Remove section about online events --- text/0000-contribution.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/text/0000-contribution.md b/text/0000-contribution.md index 76f1d8b..b1c0390 100644 --- a/text/0000-contribution.md +++ b/text/0000-contribution.md @@ -90,9 +90,6 @@ debates, and decision-making **MUST** be promoted and conducted in public community chats or on GitHub to ensure transparency and allow the entire community to learn. -- **Regular Collaborative Events (MUST):** The community **MUST** host -regular scheduled events (online or in-person) such as: - ## 4. Recognition and Incentives From 1c2f3965d5ec5f1a697d689dd7f1018af16bd04b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bilolbek=20Normo=CA=BBminov?= <113835460+itsbilolbek@users.noreply.github.com> Date: Tue, 21 Oct 2025 19:06:52 +0900 Subject: [PATCH 04/11] Update text/0000-contribution.md: Remove DotNet MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: λjon <46736978+lambdajon@users.noreply.github.com> --- text/0000-contribution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-contribution.md b/text/0000-contribution.md index b1c0390..22c7684 100644 --- a/text/0000-contribution.md +++ b/text/0000-contribution.md @@ -6,7 +6,7 @@ # Summary This RFC proposes a standardized framework for technology-specific communities -(e.g., Rust, NixOS, Dotnet) within FLOSS Uzbekistan to overcome stagnation +(e.g., Rust, Xinux) within FLOSS Uzbekistan to overcome stagnation and increase member engagement. It mandates the implementation of clear contribution paths, structured onboarding processes, active support mechanisms, and systematic contributor recognition to transform passive groups into From 6af7de09523ad1a13f99c4cde27c6c1152c76920 Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Wed, 22 Oct 2025 22:02:58 +0900 Subject: [PATCH 05/11] Add required documents section --- text/0000-contribution.md | 65 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/text/0000-contribution.md b/text/0000-contribution.md index 22c7684..edb9ab6 100644 --- a/text/0000-contribution.md +++ b/text/0000-contribution.md @@ -109,6 +109,71 @@ system for formal acknowledgment, such as: - **Gamification:** Small, monetary or non-monetary incentives or public leaderboards for answering questions or completing specific tasks. +## 5. Mandatory Documentation Requirements + +To ensure all requirements of this standard are transparent, accessible, and +structured for easy onboarding, every technology-specific community **MUST** +implement and maintain the following core set of documents in their main +organizational repository or a dedicated standards repository. + +### 5.1. The Newcomer's Guide (Dedicated Document) + +The **Newcomer's Guide** is a dedicated, high-level document designed to be +the single entry point for all individuals joining the community. It **MUST** +be highly visible and easily accessible from the main chat and the GitHub +organization homepage. + +| Requirement | Purpose | Status | | --- | --- | --- | | **Document Location** +| Must be a standalone file or a dedicated page on the community website. | +MUST | | **Content** | Must include: a clear overview of the technology's +relevance in Uzbekistan, the community's mission and culture, a complete list +of communication platforms (Telegram, GitHub)and the **"Easy First Tasks"** +list. | MUST | | **Language** | Must be primarily written in Uzbek. |MUST | + +### 5.2. The Contribution Guide (CONTRIBUTING.md) + +The standard GitHub CONTRIBUTING.md file must be expanded to explicitly +cover the diverse contribution paths mandated by this RFC. + +| Requirement | Purpose | Status | | --- | --- | --- | | **Coding Standards** +| Must outline coding style, testing requirements, and the process for +submitting a Pull Request (PR) to the local community project(s). | MUST | +| **Non-Code Paths** | Must dedicate clear sections detailing the process +for submitting: Translations, Tutorials/Content, and how to join a Community +Management/Events team. | MUST | | **Issue Triage Process** | Must describe +how issues are labeled, how long contributors should wait for a review, +and the definition of a `Good First Issue`. |MUST | + +### 5.3. Project Showcase and Curation (AWESOME_LIST.md) + +To fulfill the Local Resource Curation mandate, a dedicated document must +be maintained. + +| Requirement | Purpose | Status | | --- | --- | --- | | **Document Location** +| Must be a standalone list (e.g., `AWESOME_RUST_UZ.md`) in the main +organizational repository. | MUST | | **Content** | Must be a categorized +list of locally-relevant open-source projects using the community's core +technology, along with contact information or contribution links for each. | +MUST | | **Maintenance** | Must specify a leader or team responsible for +regularly updating the curated list by finding new open-source projects and +verifying that the project is still active. | MUST | + + + +### 5.4 Documentation for Recognition and Support + +To ensure transparency regarding incentives and acknowledgment, these +processes must be formalized. + +| Requirement | Purpose | Status | | --- | --- | --- | | **Contributor +List** | Must maintain an up-to-date `CONTRIBUTORS.md` file, or use a +tool to automatically generate a list, acknowledging all individuals who +have made a recognized contribution (code, docs, or community help)." | +MUST | | **Recognition System Rules** | If a **Recognition System** +(Badges/Gamification) is implemented (SHOULD), the rules, points system, and +rewards (if any) **MUST** be clearly documented in a public location. | MUST | + + # Guide-level explanation To revitalize your community: From 5f4d27de00d0d075fa112b3888dcc8f31bea0330 Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Wed, 22 Oct 2025 22:44:14 +0900 Subject: [PATCH 06/11] Add detailed explanation for CONTRIBUTING.md --- text/0000-contribution.md | 75 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) diff --git a/text/0000-contribution.md b/text/0000-contribution.md index edb9ab6..3924be6 100644 --- a/text/0000-contribution.md +++ b/text/0000-contribution.md @@ -144,6 +144,81 @@ Management/Events team. | MUST | | **Issue Triage Process** | Must describe how issues are labeled, how long contributors should wait for a review, and the definition of a `Good First Issue`. |MUST | +### **Detailed Structure of `CONTRIBUTING.md`** + +#### 1. Getting Started and Code of Conduct + +This section sets the tone and the mandatory prerequisites for all contributors. + +- **Code of Conduct (CoC) Link:** A clear, mandatory link to the community's CODE_OF_CONDUCT.md. This is non-negotiable—all contributors must agree to abide by the community's rules. + +- Direct link to the **Newcomer's Guide** for high-level orientation. + +#### 2. Code Contribution Workflow (Setup, Build, and Test) + +This section provides the technical roadmap required for hands-on development. + +- **Prerequisites:** List all required tools (e.g., specific version of the SDK/runtime, Git client). + +- **Local Setup:** Clear, step-by-step instructions for getting the code: How to fork the main repository on GitHub and setting upstream. + +- **Building the Project:** + + - The exact build command(s) needed (e.g., dotnet build, cargo build, nix-build). + + - Troubleshooting steps for common build errors in the local Uzbek environment. + +- **Testing:** + + - The command(s) needed to run the entire test suite (e.g., dotnet test, cargo test). + + - A mandate: All Pull Requests MUST pass all automated tests before they will be reviewed. + +#### 3. Style, Standards, and Submission + +This covers the quality and mechanics of submitting the code for review. + +- **Code Style and Quality:** + + - Mandatory tools for automated formatting (e.g., link to the community's .editorconfig or .rustfmt.toml). + + - Clear statement on required documentation for new functions and features. + +- **Commit and Branching Standards:** + + - Define the required structure for branch names (e.g., feat/my-new-feature or bug/fix-123). + + - Define the preferred commit message style (e.g., conventional commits: fix: resolve crash on startup). + +- **The Pull Request (PR) Submission:** + + - A reminder that the contributor **MUST** fill out the entire PR template. + + - Explanation of the review process, including the expected initial response time and guidance on how to respond constructively to feedback. + +#### 4. Non-Code Contribution Paths + +This critical section formalizes the diverse contribution avenues to meet the FLOSS Uzbekistan standard. + +- **Documentation and Translation:** + + - **Process:** Specify the branch or directory where documentation contributions should be submitted (e.g., PRs to the docs/uz folder). + + - **Translation:** if applicable, list all the documents that need to be translated into Uzbek. + + +#### 5. Licensing Information (Legal Mandate) + +This section ensures legal transparency and compliance with FLOSS principles. + +- **Licensing Terms (MUST):** + + - Explicitly state the project's **license** (e.g., MIT, GPLv3, etc.). + + - **MUST INCLUDE:** A statement that by submitting a Pull Request, the contributor agrees to license their work under the project's specified license. + + - Link to the full `LICENSE` file. + ### 5.3. Project Showcase and Curation (AWESOME_LIST.md) To fulfill the Local Resource Curation mandate, a dedicated document must From 213decc8ab1502407681b2bfb5a74471bd68cc08 Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Wed, 22 Oct 2025 22:48:16 +0900 Subject: [PATCH 07/11] Fix table formatting --- text/0000-contribution.md | 110 ++++++++++++++++++++------------------ 1 file changed, 59 insertions(+), 51 deletions(-) diff --git a/text/0000-contribution.md b/text/0000-contribution.md index 3924be6..6d42299 100644 --- a/text/0000-contribution.md +++ b/text/0000-contribution.md @@ -6,11 +6,11 @@ # Summary This RFC proposes a standardized framework for technology-specific communities -(e.g., Rust, Xinux) within FLOSS Uzbekistan to overcome stagnation -and increase member engagement. It mandates the implementation of clear -contribution paths, structured onboarding processes, active support mechanisms, -and systematic contributor recognition to transform passive groups into -active, collaborative hubs. +(e.g., Rust, Xinux) within FLOSS Uzbekistan to overcome stagnation and increase +member engagement. It mandates the implementation of clear contribution +paths, structured onboarding processes, active support mechanisms, and +systematic contributor recognition to transform passive groups into active, +collaborative hubs. # Motivation @@ -123,34 +123,33 @@ the single entry point for all individuals joining the community. It **MUST** be highly visible and easily accessible from the main chat and the GitHub organization homepage. -| Requirement | Purpose | Status | | --- | --- | --- | | **Document Location** -| Must be a standalone file or a dedicated page on the community website. | -MUST | | **Content** | Must include: a clear overview of the technology's -relevance in Uzbekistan, the community's mission and culture, a complete list -of communication platforms (Telegram, GitHub)and the **"Easy First Tasks"** -list. | MUST | | **Language** | Must be primarily written in Uzbek. |MUST | +| Requirement | Purpose | Status | +| --- | --- | --- | +| **Document Location** | Must be a standalone file or a dedicated page on the community website. | MUST | +| **Content** | Must include: a clear overview of the technology's relevance in Uzbekistan, the community's mission and culture, a complete list of communication platforms (Telegram, GitHub)and the **"Easy First Tasks"** list. | MUST | +| **Language** | Must be primarily written in Uzbek. |MUST | ### 5.2. The Contribution Guide (CONTRIBUTING.md) The standard GitHub CONTRIBUTING.md file must be expanded to explicitly cover the diverse contribution paths mandated by this RFC. -| Requirement | Purpose | Status | | --- | --- | --- | | **Coding Standards** -| Must outline coding style, testing requirements, and the process for -submitting a Pull Request (PR) to the local community project(s). | MUST | -| **Non-Code Paths** | Must dedicate clear sections detailing the process -for submitting: Translations, Tutorials/Content, and how to join a Community -Management/Events team. | MUST | | **Issue Triage Process** | Must describe -how issues are labeled, how long contributors should wait for a review, -and the definition of a `Good First Issue`. |MUST | +| Requirement | Purpose | Status | +| --- | --- | --- | +| **Coding Standards** | Must outline coding style, testing requirements, and the process for submitting a Pull Request (PR) to the local community project(s). | MUST | +| **Non-Code Paths** | Must dedicate clear sections detailing the process for submitting: Translations, Tutorials/Content, and how to join a Community Management/Events team. | MUST | +| **Issue Triage Process** | Must describe how issues are labeled, how long contributors should wait for a review, and the definition of a `Good First Issue`. |MUST | ### **Detailed Structure of `CONTRIBUTING.md`** #### 1. Getting Started and Code of Conduct -This section sets the tone and the mandatory prerequisites for all contributors. +This section sets the tone and the mandatory prerequisites for all +contributors. -- **Code of Conduct (CoC) Link:** A clear, mandatory link to the community's CODE_OF_CONDUCT.md. This is non-negotiable—all contributors must agree to abide by the community's rules. +- **Code of Conduct (CoC) Link:** A clear, mandatory link to the community's +CODE_OF_CONDUCT.md. This is non-negotiable—all contributors must agree to +abide by the community's rules. - Direct link to the **Newcomer's Guide** for high-level orientation. @@ -158,21 +157,27 @@ This section sets the tone and the mandatory prerequisites for all contributors. This section provides the technical roadmap required for hands-on development. -- **Prerequisites:** List all required tools (e.g., specific version of the SDK/runtime, Git client). +- **Prerequisites:** List all required tools (e.g., specific version of the +SDK/runtime, Git client). -- **Local Setup:** Clear, step-by-step instructions for getting the code: How to fork the main repository on GitHub and setting upstream. +- **Local Setup:** Clear, step-by-step instructions for getting the code: +How to fork the main repository on GitHub and setting upstream. - **Building the Project:** - - The exact build command(s) needed (e.g., dotnet build, cargo build, nix-build). + - The exact build command(s) needed (e.g., dotnet build, cargo build, + nix-build). - - Troubleshooting steps for common build errors in the local Uzbek environment. + - Troubleshooting steps for common build errors in the local Uzbek + environment. - **Testing:** - - The command(s) needed to run the entire test suite (e.g., dotnet test, cargo test). + - The command(s) needed to run the entire test suite (e.g., dotnet test, + cargo test). - - A mandate: All Pull Requests MUST pass all automated tests before they will be reviewed. + - A mandate: All Pull Requests MUST pass all automated tests before they + will be reviewed. #### 3. Style, Standards, and Submission @@ -180,32 +185,39 @@ This covers the quality and mechanics of submitting the code for review. - **Code Style and Quality:** - - Mandatory tools for automated formatting (e.g., link to the community's .editorconfig or .rustfmt.toml). + - Mandatory tools for automated formatting (e.g., link to the community's + .editorconfig or .rustfmt.toml). - Clear statement on required documentation for new functions and features. - **Commit and Branching Standards:** - - Define the required structure for branch names (e.g., feat/my-new-feature or bug/fix-123). + - Define the required structure for branch names (e.g., feat/my-new-feature + or bug/fix-123). - - Define the preferred commit message style (e.g., conventional commits: fix: resolve crash on startup). + - Define the preferred commit message style (e.g., conventional commits: + fix: resolve crash on startup). - **The Pull Request (PR) Submission:** - A reminder that the contributor **MUST** fill out the entire PR template. - - Explanation of the review process, including the expected initial response time and guidance on how to respond constructively to feedback. + - Explanation of the review process, including the expected initial + response time and guidance on how to respond constructively to feedback. #### 4. Non-Code Contribution Paths -This critical section formalizes the diverse contribution avenues to meet the FLOSS Uzbekistan standard. +This critical section formalizes the diverse contribution avenues to meet +the FLOSS Uzbekistan standard. - **Documentation and Translation:** - - **Process:** Specify the branch or directory where documentation contributions should be submitted (e.g., PRs to the docs/uz folder). + - **Process:** Specify the branch or directory where documentation + contributions should be submitted (e.g., PRs to the docs/uz folder). + + - **Translation:** if applicable, list all the documents that need to + be translated into Uzbek. - - **Translation:** if applicable, list all the documents that need to be translated into Uzbek. - #### 5. Licensing Information (Legal Mandate) @@ -215,7 +227,9 @@ This section ensures legal transparency and compliance with FLOSS principles. - Explicitly state the project's **license** (e.g., MIT, GPLv3, etc.). - - **MUST INCLUDE:** A statement that by submitting a Pull Request, the contributor agrees to license their work under the project's specified license. + - **MUST INCLUDE:** A statement that by submitting a Pull Request, the + contributor agrees to license their work under the project's specified + license. - Link to the full `LICENSE` file. @@ -224,14 +238,11 @@ This section ensures legal transparency and compliance with FLOSS principles. To fulfill the Local Resource Curation mandate, a dedicated document must be maintained. -| Requirement | Purpose | Status | | --- | --- | --- | | **Document Location** -| Must be a standalone list (e.g., `AWESOME_RUST_UZ.md`) in the main -organizational repository. | MUST | | **Content** | Must be a categorized -list of locally-relevant open-source projects using the community's core -technology, along with contact information or contribution links for each. | -MUST | | **Maintenance** | Must specify a leader or team responsible for -regularly updating the curated list by finding new open-source projects and -verifying that the project is still active. | MUST | +| Requirement | Purpose | Status | +| --- | --- | --- | +| **Document Location** | Must be a standalone list (e.g., `AWESOME_RUST_UZ.md`) in the main organizational repository. | MUST | +| **Content** | Must be a categorized list of locally-relevant open-source projects using the community's core technology, along with contact information or contribution links for each. | MUST | +| **Maintenance** | Must specify a leader or team responsible for regularly updating the curated list by finding new open-source projects and verifying that the project is still active. | MUST | @@ -240,13 +251,10 @@ verifying that the project is still active. | MUST | To ensure transparency regarding incentives and acknowledgment, these processes must be formalized. -| Requirement | Purpose | Status | | --- | --- | --- | | **Contributor -List** | Must maintain an up-to-date `CONTRIBUTORS.md` file, or use a -tool to automatically generate a list, acknowledging all individuals who -have made a recognized contribution (code, docs, or community help)." | -MUST | | **Recognition System Rules** | If a **Recognition System** -(Badges/Gamification) is implemented (SHOULD), the rules, points system, and -rewards (if any) **MUST** be clearly documented in a public location. | MUST | +| Requirement | Purpose | Status | +| --- | --- | --- | +| **Contributor List** | Must maintain an up-to-date `CONTRIBUTORS.md` file, or use a tool to automatically generate a list, acknowledging all individuals who have made a recognized contribution (code, docs, or community help)." | MUST | +| **Recognition System Rules** | If a **Recognition System** (Badges/Gamification) is implemented (SHOULD), the rules, points system, and rewards (if any) **MUST** be clearly documented in a public location. | MUST | # Guide-level explanation From 9f7aa852976eee412b2d8970c0d9aaa4921d4150 Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Wed, 22 Oct 2025 22:53:46 +0900 Subject: [PATCH 08/11] Remove unnecessary table --- text/0000-contribution.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/text/0000-contribution.md b/text/0000-contribution.md index 6d42299..6bf24a9 100644 --- a/text/0000-contribution.md +++ b/text/0000-contribution.md @@ -123,12 +123,6 @@ the single entry point for all individuals joining the community. It **MUST** be highly visible and easily accessible from the main chat and the GitHub organization homepage. -| Requirement | Purpose | Status | -| --- | --- | --- | -| **Document Location** | Must be a standalone file or a dedicated page on the community website. | MUST | -| **Content** | Must include: a clear overview of the technology's relevance in Uzbekistan, the community's mission and culture, a complete list of communication platforms (Telegram, GitHub)and the **"Easy First Tasks"** list. | MUST | -| **Language** | Must be primarily written in Uzbek. |MUST | - ### 5.2. The Contribution Guide (CONTRIBUTING.md) The standard GitHub CONTRIBUTING.md file must be expanded to explicitly From 5e1f8da4a7ef3004a3ce86cf4220b54c6a93d7cf Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Wed, 22 Oct 2025 22:54:35 +0900 Subject: [PATCH 09/11] Wrong table lol --- text/0000-contribution.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/text/0000-contribution.md b/text/0000-contribution.md index 6bf24a9..43f81fc 100644 --- a/text/0000-contribution.md +++ b/text/0000-contribution.md @@ -123,17 +123,17 @@ the single entry point for all individuals joining the community. It **MUST** be highly visible and easily accessible from the main chat and the GitHub organization homepage. +| Requirement | Purpose | Status | +| --- | --- | --- | +| **Document Location** | Must be a standalone file or a dedicated page on the community website. | MUST | +| **Content** | Must include: a clear overview of the technology's relevance in Uzbekistan, the community's mission and culture, a complete list of communication platforms (Telegram, GitHub)and the **"Easy First Tasks"** list. | MUST | +| **Language** | Must be primarily written in Uzbek. |MUST | + ### 5.2. The Contribution Guide (CONTRIBUTING.md) The standard GitHub CONTRIBUTING.md file must be expanded to explicitly cover the diverse contribution paths mandated by this RFC. -| Requirement | Purpose | Status | -| --- | --- | --- | -| **Coding Standards** | Must outline coding style, testing requirements, and the process for submitting a Pull Request (PR) to the local community project(s). | MUST | -| **Non-Code Paths** | Must dedicate clear sections detailing the process for submitting: Translations, Tutorials/Content, and how to join a Community Management/Events team. | MUST | -| **Issue Triage Process** | Must describe how issues are labeled, how long contributors should wait for a review, and the definition of a `Good First Issue`. |MUST | - ### **Detailed Structure of `CONTRIBUTING.md`** #### 1. Getting Started and Code of Conduct From 638f3c1a7daa5d73e439f9df9b0eb4a90cfc6694 Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Thu, 23 Oct 2025 13:30:21 +0900 Subject: [PATCH 10/11] Replace nested numbered list with roman numerals for better readability --- text/0000-contribution.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/text/0000-contribution.md b/text/0000-contribution.md index 43f81fc..f220b00 100644 --- a/text/0000-contribution.md +++ b/text/0000-contribution.md @@ -136,7 +136,7 @@ cover the diverse contribution paths mandated by this RFC. ### **Detailed Structure of `CONTRIBUTING.md`** -#### 1. Getting Started and Code of Conduct +#### i. Getting Started and Code of Conduct This section sets the tone and the mandatory prerequisites for all contributors. @@ -147,7 +147,7 @@ abide by the community's rules. - Direct link to the **Newcomer's Guide** for high-level orientation. -#### 2. Code Contribution Workflow (Setup, Build, and Test) +#### ii. Code Contribution Workflow (Setup, Build, and Test) This section provides the technical roadmap required for hands-on development. @@ -173,7 +173,7 @@ How to fork the main repository on GitHub and setting upstream. - A mandate: All Pull Requests MUST pass all automated tests before they will be reviewed. -#### 3. Style, Standards, and Submission +#### ii. Style, Standards, and Submission This covers the quality and mechanics of submitting the code for review. @@ -199,7 +199,7 @@ This covers the quality and mechanics of submitting the code for review. - Explanation of the review process, including the expected initial response time and guidance on how to respond constructively to feedback. -#### 4. Non-Code Contribution Paths +#### iv. Non-Code Contribution Paths This critical section formalizes the diverse contribution avenues to meet the FLOSS Uzbekistan standard. @@ -213,7 +213,7 @@ the FLOSS Uzbekistan standard. be translated into Uzbek. -#### 5. Licensing Information (Legal Mandate) +#### v. Licensing Information (Legal Mandate) This section ensures legal transparency and compliance with FLOSS principles. From c7b3b17ea6c48bdc6764ed59165bfbc361b6de9e Mon Sep 17 00:00:00 2001 From: Normuminov Bilolbek Date: Thu, 23 Oct 2025 13:41:33 +0900 Subject: [PATCH 11/11] Add section about Code of Conduct --- text/0000-contribution.md | 99 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) diff --git a/text/0000-contribution.md b/text/0000-contribution.md index f220b00..3b54745 100644 --- a/text/0000-contribution.md +++ b/text/0000-contribution.md @@ -250,6 +250,105 @@ processes must be formalized. | **Contributor List** | Must maintain an up-to-date `CONTRIBUTORS.md` file, or use a tool to automatically generate a list, acknowledging all individuals who have made a recognized contribution (code, docs, or community help)." | MUST | | **Recognition System Rules** | If a **Recognition System** (Badges/Gamification) is implemented (SHOULD), the rules, points system, and rewards (if any) **MUST** be clearly documented in a public location. | MUST | +### 5.5 Code of Conduct + +The Code of Conduct must consist of four primary components: The Statement, +The Standards, The Scope, and The Enforcement Process. + +1. **The Statement and Scope** + + This section sets the purpose and explicitly defines where and to whom + the CoC applies. + + - **Preamble/Statement of Purpose (MUST):** A clear, concise statement + explaining why the community needs a CoC. The purpose is to foster + a respectful, harassment-free experience for everyone, regardless of + background. + + - **Scope (MUST):** Explicitly list where the CoC is in effect. This + must cover all official community spaces: + + - GitHub repositories and issue trackers. + + - Primary communication channels (e.g., Telegram, Matrix). + + - Community events (online and in-person meetups, workshops). + + - **Applicable Parties (MUST):** State clearly that the CoC applies to + everyone participating in the community, including: + + - Contributors and users. + + - Project Maintainers and the Community Chair. + + - Event organizers and sponsors. + +2. **Behavioral Standards (The Rules)** + + This section defines the expected positive behaviors and explicitly + lists the unacceptable behaviors. + + - **Expected Behavior (MUST):** Emphasize positive actions, such as: + + - Being considerate, respectful, and collaborative. + + - Welcoming newcomers and being patient with those who are learning. + + - Accepting constructive criticism and delivering feedback politely. + + - Focusing on the technical problem, not the person. + + - **Unacceptable Behavior (MUST):** List specific actions that constitute + harassment, including, but not limited to: + + - Offensive Comments related to gender, sexual orientation, disability, + physical appearance, race, or religion. + + - Unwelcome Sexual Attention or conduct. + + - Intimidation, Stalking, or Trolling (especially in public channels). + + - Sustained Disruption of discussions or events. + + - Unsolicited sharing of private information (doxxing). + +3. **Reporting and Enforcement** + + This is the most critical section; an unenforceable CoC is useless. This + process must be clear, simple, and prioritize the reporter's safety. + + - **Designated Contact (MUST):** Clearly state who is responsible for + receiving reports. This should be a small, trusted CoC Response Team + (usually the Community Chair and one or two Maintainers). Provide multiple, + private contact methods, such as: + + - A dedicated, private email address (e.g., coc@floss.uz). + + - A direct contact handle (e.g., Telegram ID) of one trusted team + member. + + - **The Reporting Process (MUST):** Detail the steps a reporter + should take, assuring them that reports will be handled privately and + confidentially. The process should specify what information is needed + (date, time, location, involved parties, what happened). + + - **Confidentiality (MUST):** Provide a strong statement assuring the + reporter that their identity will be kept confidential from the public + and from the accused party unless absolutely necessary for investigation + or disclosure is explicitly requested by the reporter. + + - **Enforcement Actions (MUST):** Provide a clear list of potential + consequences for violations, ranging from low-severity to high-severity: + + - A private written warning. + + - A temporary ban (mute) from community spaces. + + - A permanent ban from the community. + + - Note: Actions should be taken only after investigation and + deliberation by the Response Team. + # Guide-level explanation