• Start Date: 2023-12-18
• RFC PR: N/A
• STD Issue: github.com/FLOSS-uz/standards/issues/8
• Severity: MUST

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.

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.

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.

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.

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.

Detailed Structure of CONTRIBUTING.md

i. 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.

ii. 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.

ii. 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.

iv. 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.

v. 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 be maintained.

5.4 Documentation for Recognition and Support

To ensure transparency regarding incentives and acknowledgment, these processes must be formalized.

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

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.