FLOSS Uzbekistan RFCs - RFC Book

The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project and communities, so that whole uzbek it communities with its developers can be confident about the direction the uzbek is evolving in.

Many changes, including typo fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow.

Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the FLOSS Uzbekistan community and the [core team].

Table of Contents

• Opening
• Table of Contents
• When you need to follow this process
• Specific guidelines
• Before creating an RFC
• What the process is
• The RFC life-cycle
• Reviewing RFCs
• Implementing an RFC
• RFC Postponement
• Help this is all too informal!
• License
• Contributions

When you need to follow this process

You need to follow this process if you intend to make "substantial" changes to the FLOSS Uzebkistan distribution. What constitutes a "substantial" change is evolving based on community norms, but may include the following.

• Any semantic or syntactic change to the standards.
• Removing stds, including those that are feature-gated.
• Changes to the interface between the stds and rule-sets, intrinsics.
• Additions to stds.

Some changes do not require an RFC:

• Rephrasing, reorganizing, refactoring, or otherwise "changing shape does not change meaning".
• Additions only likely to be noticed by other core-of-floss, invisible to members-of-floss.

If you submit a pull request to implement a new feature without going through the RFC process, it may be closed with a polite request to submit an RFC first.

Specific guidelines

For more details on when an RFC is required for the following areas, please see the Rust community's [sub-team] specific guidelines for:

• general changes

Before creating an RFC

A hastily-proposed RFC can hurt its chances of acceptance. Low quality proposals, proposals for previously-rejected features, or those that don't fit into the near-term roadmap, may be quickly rejected, which can be demotivating for the unprepared contributor. Laying some groundwork ahead of the RFC can make the process smoother.

Although there is no single way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from other project developers beforehand, to ascertain that the RFC may be desirable; having a consistent impact on the project requires concerted effort toward consensus-building.

The most common preparations for writing and submitting an RFC include talking the idea over on our official telegram chat, and occasionally posting "pre-RFCs" on the developer forum. You may file issues on this repo for discussion, but these are not actively looked at by the core team members.

As a rule of thumb, receiving encouraging feedback from long-standing project developers, and particularly members of the relevant core-team is a good indication that the RFC is worth pursuing.

What the process is

In short, to get a standards added to Uzbek communities, one must first get the RFC merged into the RFC repository as a markdown file. At that point the RFC is "active" and may be implemented with the goal of eventual inclusion into general collection of overall STDs applied over all uzbek communities that are affected with rules applied by its maintainers.

• Fork the RFC repo RFC repository
• Copy 0000-template.md to text/0000-my-std.md (where "my-std" is descriptive). Don't assign an RFC number yet; This is going to be the PR number and we'll rename the file accordingly if the RFC is accepted.
• Fill in the RFC. Put care into the details: RFCs that do not present convincing motivation, demonstrate lack of understanding of the design's impact, or are disingenuous about the drawbacks or alternatives tend to be poorly-received.
• Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in response.
• Now that your RFC has an open pull request, use the issue number of the PR to update your 0000- prefix to that number.
• Each pull request will be labeled with the most relevant core-team member, which will lead to its being triaged by that member in a future meeting and assigned to a member of the core-team.
• Build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don't receive any comments. Feel free to reach out to the RFC assignee in particular to get help identifying obstacles.
• The sub-team will discuss the RFC pull request, as much as possible in the comment thread of the pull request itself. Offline discussion will be summarized on the pull request comment thread.
• RFCs rarely go through this process unchanged, especially as alternatives and drawbacks are shown. You can make edits, big and small, to the RFC to clarify or change the design, but make changes as new commits to the pull request, and leave a comment on the pull request explaining your changes. Specifically, do not squash or rebase commits after they are visible on the pull request.
• At some point, a member of the core-team member will propose a "motion for final comment period" (FCP), along with a disposition for the RFC (merge, close, or postpone).
  • This step is taken when enough of the tradeoffs have been discussed that the subteam is in a position to make a decision. That does not require consensus amongst all participants in the RFC thread (which is usually impossible). However, the argument supporting the disposition on the RFC needs to have already been clearly articulated, and there should not be a strong consensus against that position outside of the subteam. Subteam members use their best judgment in taking this step, and the FCP itself ensures there is ample time and notification for stakeholders to push back if it is made prematurely.
  • For RFCs with lengthy discussion, the motion to FCP is usually preceded by a summary comment trying to lay out the current state of the discussion and major tradeoffs/points of disagreement.
  • Before actually entering FCP, all members of the subteam must sign off; this is often the point at which many subteam members first review the RFC in full depth.
• In most cases, the FCP period is quiet, and the RFC is either merged or closed. However, sometimes substantial new arguments or ideas are raised, the FCP is canceled, and the RFC goes back into development mode.

The RFC life-cycle

Once an RFC becomes "active" then authors may implement it and submit the feature as a pull request to the Rust repo. Being "active" is not a rubber stamp, and in particular still does not mean the feature will ultimately be merged; it does mean that in principle all the major stakeholders have agreed to the feature and are amenable to merging it.

Furthermore, the fact that a given RFC has been accepted and is "active" implies nothing about what priority is assigned to its implementation, nor does it imply anything about whether a Rust developer has been assigned the task of implementing the feature. While it is not necessary that the author of the RFC also write the implementation, it is by far the most effective way to see an RFC through to completion: authors should not expect that other project developers will take on responsibility for implementing their accepted feature.

Modifications to "active" RFCs can be done in follow-up pull requests. We strive to write each RFC in a manner that it will reflect the final design of the feature; but the nature of the process means that we cannot expect every merged RFC to actually reflect what the end result will be at the time of the next major release.

In general, once accepted, RFCs should not be substantially changed. Only very minor changes should be submitted as amendments. More substantial changes should be new RFCs, with a note added to the original RFC. Exactly what counts as a "very minor change" is up to the sub-team to decide; check [Sub-team specific guidelines] for more details.

Reviewing RFCs

While the RFC pull request is up, the core-team member may schedule meetings with the author and/or relevant members to discuss the issues in greater detail, and in some cases the topic may be discussed at a core-team meeting. In either case a summary from the meeting will be posted back to the RFC pull request.

A core-team makes final decisions about RFCs after the benefits and drawbacks are well understood. These decisions can be made at any time, but the core-team will regularly issue decisions. When a decision is made, the RFC pull request will either be merged or closed. In either case, if the reasoning is not clear from the discussion in thread, the core-team will add a comment describing the rationale for the decision.

Implementing an RFC

Some accepted RFCs represent vital features that need to be implemented right away. Other accepted RFCs can represent features that can wait until some arbitrary developer or community member feels like doing the work. Every accepted RFC has an associated issue tracking its implementation in the STD repository; thus that associated issue can be assigned a priority via the triage process that the team uses for all issues in the STD repository.

The author of an RFC is not obligated to implement it. Of course, the RFC author (like any other member) is welcome to post an implementation for review after the RFC has been accepted.

If you are interested in working on the implementation for an "active" RFC, but cannot determine if someone else is already working on it, feel free to ask (e.g. by leaving a comment on the associated issue).

RFC Postponement

Some RFC pull requests are tagged with the "postponed" label when they are closed (as part of the rejection process). An RFC closed with "postponed" is marked as such because we want neither to think about evaluating the proposal nor about implementing the described feature until some time in the future, and we believe that we can afford to wait until then to do so. Postponed pull requests may be re-opened when the time is right. We don't have any formal process for that, you should ask members of the relevant core-team.

Usually an RFC pull request marked as "postponed" has already passed an informal first round of evaluation, namely the round of "do we think we would ever possibly consider making this change, as outlined in the RFC pull request, or some semi-obvious variation of it." (When the answer to the latter question is "no", then the appropriate response is to close the RFC, not postpone it.)

Help this is all too informal!

The process is intended to be as lightweight as reasonable for the present circumstances. As usual, we are trying to let the process be driven by consensus and community norms, not impose more structure than necessary.

License

This repository is currently in the process of being licensed under either of:

• Apache License, Version 2.0, (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)

at your option. Some parts of the repository are already licensed according to those terms. For more see RFC N/A and its tracking issue.

Contributions

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

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

• Standartization Name: English as the Primary Language for Formal Communication and Technical Standardization

• Start Date: 2025-10-31

• RFC PR: N/A

• STD Issue: N/A

• Severity: MUST

Summary

This RFC mandates the use of English as the Primary Language for all formal communication, technical documentation, and code contributions within the FLOSS Uzbekistan network. This policy aligns the community with global open-source standards, ensuring maximum accessibility to international contributors and tools. Furthermore, all Uzbek technical communication MUST standardize on the Latin alphabet, deprecating the use of Cyrillic script.

Motivation

While promoting the Uzbek language is important for local empowerment, mandating English for formal technical communication provides critical benefits for the long-term sustainability and quality of FLOSS Uzbekistan projects:

1. Maximizing Global Contribution: English is the lingua franca of software development. Standardizing on English immediately lowers the barrier to entry for international contributors, users, and reviewers, directly increasing the talent pool and external feedback loop.

2. Tooling Compatibility: English simplifies interaction with essential global tools (GitHub, automated translation services, static analysis tools) which are primarily designed around Latin-based languages.

3. Professional Readiness: Mandating English prepares Uzbek developers for global careers and high-level international collaboration, reinforcing the community's role in professional development.

4. Uzbek Script Standardization: Deprecating the Cyrillic alphabet for technical writing eliminates internal confusion and aligns with the widely recognized Latin script used in modern coding environments and data processing.

I. Detailed Design and Language Mandates

All technology-specific communities (e.g., Rust, Haskell, DevOps) and their members MUST adhere to the following language requirements:

A. Formal Communication (MUST be English)

All official and formal communications channels MUST use English exclusively:

• RFCs and Standards: All new RFCs and proposed standards MUST be written in English.

• Code Review: All Pull Request (PR) titles, descriptions, and review comments MUST be in English.

• Issue Tracking: All GitHub issues, bug reports, feature requests, and issue comments MUST be in English.

• Official Announcements: Major announcements, official blog posts MUST be delivered in English.

B. Technical Documentation and Readmes

English MUST be the source of truth for all technical documentation.

• Documentation Priority (MUST): Project documentation (e.g., reference guides, API documentation, tutorials) MUST be authored in English first. The English version serves as the canonical source.

• Uzbek Documentation (SHOULD): An Uzbek version of documentation is strongly encouraged as a secondary resource but is not mandatory unless specified by a separate localization standard.

• Project Readmes (MUST): Every repository MUST provide an English version of the README.md. An Uzbek version may be provided alongside it (e.g., in the same file or a separate README_uz.md).

C. Uzbek Script Standardization (MUST)

When writing technical content in the Uzbek language (e.g., in documentation, readmes, or internal code comments):

• Latin Alphabet Only: Only the Latin alphabet MUST be used.

• Cyrillic Deprecation: The use of the Cyrillic alphabet for all official FLOSS Uzbekistan technical communications, repositories, and documentation is deprecated and MUST be phased out.

II. Guide-Level Explanation

For community members and contributors:

• English is the Default: When you open a PR, write an RFC, or report a bug on GitHub, use clear, concise English. This is non-negotiable for formal submissions.

• Prioritize English Docs: If you are a technical writer or contributor to documentation, create and maintain the English version first.

• Use Latin for Uzbek: When you switch to Uzbek for a piece of documentation or a comment, only use the Latin alphabet.

For community leaders and maintainers:

• Active Enforcement: Politely but firmly reject PRs and RFCs submitted in non-English languages, asking the contributor to resubmit in English.

• Migration Plan: For existing documentation that uses Cyrillic Uzbek, establish a plan to migrate the content to the Latin script within six (6) months of this standard's adoption.

III. Unresolved Questions

• Will the FLOSS Uzbekistan council provide automated tooling or resources to help communities migrate existing Cyrillic-based documentation to the Latin alphabet?

IV. Future Possibilities

• Start Date: 2023-12-18
• RFC PR: N/A
• STD Issue: N/A
• Severity: MUST

Summary

The RFC (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project and communities so that the whole Uzbek IT community and its developers can be confident about the direction the community is evolving in.

Motivation

The freewheeling way that Uzbek developers adopt behaviors from other countries' cultures has been good for our developer ecosystem in early development. However, for Uzbek developer community to become a mature ecosystem we need to develop self-discipline when it comes to changing the system. This is a proposal for a principled RFC process to make it an integral part of the overall development process and one that is followed consistently to introduce standardizations to Uzbek communities under Uzbek Floss Organization.

Detailed design

Many changes, including typo fixes and documentation improvements can be implemented and reviewed via the regular GitHub pull request workflow.

Though some changes are 'substantial', and we ask them to be put through a bit of a design process and produce a consensus among the Floss Uzbekistan community and the core team.

When you need to follow this process

You need to follow this process if you intend to make 'substantial' changes to the Floss Uzbekistan distribution. What constitutes a 'substantial' change is evolving based on community norms, but may include the following.

• Any semantic or syntactic change to the standards.
• Removing stds, including those that are feature-gated.
• Changes to the interface between the stds and rule-sets, intrinsics.
• Additions to stds.

Some changes do not require an RFC:

• Rephrasing, reorganizing, refactoring, or otherwise "changing shape does not change meaning".
• Additions only likely to be noticed by other core-of-floss, invisible to members-of-floss.

If you submit a pull request to implement a new feature without going through the RFC process, it may be closed with a polite request to submit an RFC first.

What the process is

In short, to get a major change added to Floss Uzbekistan, one must first get the RFC merged into the RFC repo as a markdown file. At that point the RFC is 'active' and may be implemented with the goal of eventual inclusion into the main repository consisting all standardizations.

• Fork the RFC repo https://github.com/floss-uz/standards
• Copy 0000-template.md to text/0000-my-std.md (Where 'my-std' is descriptive. Do not assign an RFC number yet).
• Fill in the RFC
• Submit a pull request. The pull request is the time to get review of the design from the larger community.
• Build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don't receive any comments.

Eventually, somebody on the core team will either accept the RFC by merging the pull request, at which point the RFC is 'active' or rejected by closing the pull request. It may also be reworked later by the team and re-submitted on behalf of one of any core team members.

Whomever merges the RFC should do the following:

• Assign an id using the PR number of the RFC pull request. (If the RFC has multiple pull requests associated with it, choose one PR number, preferably the minimal one.)
• Add the file in the text/ directory.
• Create a corresponding issue on STD repo
• Fill in the remaining metadata in the RFC header, including links for the original pull request(s) and the newly created STD issue.
• Add an entry in the Active RFC List of the root README.md.
• Commit everything.

Once an RFC becomes active then authors may implement it and submit the feature as a pull request to corresponding repos. An 'active' is not a rubber stamp, and in particular still does not mean the feature will ultimately be merged; it does mean that in principle all the major stakeholders have agreed to the feature and are amenable to merging it.

Modifications to active RFC's can be done in followup PR's. An RFC that makes it through the entire process to implementation is considered 'complete' and is removed from the Active RFC List; an RFC that fails after becoming active is 'inactive' and moves to the 'inactive' folder.

Alternatives

Retain the current informal RFC process. The newly proposed RFC process is designed to improve over the informal process in the following ways:

• Discourage unactionable or vague RFCs
• Ensure that all serious RFCs are considered equally
• Give confidence to those with a stake in Rust's development that they understand why new features are being merged

As an alternative, we could adopt an even stricter RFC process than the one proposed here. If desired, we should likely look to Python's PEP process for inspiration.

Unresolved questions

1. Does this RFC strike a favorable balance between formality and agility?
2. Does this RFC successfully address the aforementioned issues with the current informal RFC process?
3. Should we retain rejected RFCs in the archive?

• Standartization Name: Shaping up what it means to be a community
• Start Date: 2025-04-09
• RFC PR: floss-uz/standards#0003
• STD Issue: floss-uz/standards#0002
• Severity: MUST

Summary

This RFC explains what it means to be a part of Uzbek Open Source (a.k.a Floss Uzbekistan) community and the requirements a community SHOULD meet before they join or become a representative member of Uzbek Open Source community.

Motivation

Over the last few weeks, we greeted many existing developer communities to Uzbek Open Source community. However, due to constantly changing shape of every community, it was decided to create and RFC that explicitly explains the requirements that a new joining community MUST meet or how a pre-existing community SHOULD shape up to. This RFC will prevent any further confuses and misunderstanding on explanation of "What it means to be a community inside Floss Uzbekistan".

Detailed design

We, a standing current committees of Uzbek Open Source, suggest that a chat-based community MUST have around 50 members, approximately 10 active members and about 2 moderators (including owner). It is MUST to have a GitHub organization if the joining community is about:

• a programming language
• a technology that is a domain to many others
• an aggregator to multiple other chat based communities

Also, the member community SHOULD have a website showing representatives of the community, the list of member sub-communities (any type) and the ongoing active projects with links to GitHub repositories and the GitHub organization.

After acceptance, if community doesn't have a telegram assistant, the community MUST implement a telegram bot which helps members with accessing useful links, information about the technology they are focusing on and also links to website and github organization.

It's also worth to mention that either telegram chat or GitHub organization MUST NOT be deleted at any cost as these two elements represent the community and its efforts as a member of Floss Uzbekistan.

The community MUST invite Floss Uzbekistan's telegram bot @flossuzbot to their chat to let users easily switch over other Floss Uzbekistan supported communities and bond stronger relationship with other communities.

These are suggestions to guide community structure, with the final decision to be determined by the council.

The optional requirements MUST be satisfied as soon as the community gets accepted to Floss Uzbekistan. Otherwise, if community refuses or does not implement given requirements in given time, the comittee still can decline and remove the community from the network. Afterwards, the community might be subjected to changes proposed by the committees of Floss Uzbekistan.

Guide-level explanation

Basic requirements before a community joins our network:

• Make sure you have a telegram chat community with 50+ members in it.
• Your community MUST exist more than 3 months.
• Check if at least 10 people are keeping it active on daily basis.
• See if you have 2 moderators that are maintaining chats.
• Then check if you have a GitHub organization to represent your community, if you don't have one, create it.
• If you don't have website, reserve a domain at .uz TLD for your community to later use in website.
• Use your domain to verify your github organization.
• If you don't have a website, initiate a repository at github organization and create very basic at least html and deploy it.
• Upon completing the steps above, reach Floss Uzbekistan chair via either Telegram chat at @flossuzc or open a discussion at Github.

Further extra-steps to perform after getting accepted:

• Let your community member know that the community has became a member of Floss Uzbekistan network.
• Add @flossuzbot to your community chat.
• Organize your GitHub organization and create necessary projects
• If you don't have an assistant telegram bot in your community, implement it alongside website and finish as soon as possible.
• Alter team changes to Floss Uzbeksitan's website and other sources by adding chair and maintainer or request a Floss maintainer to do it for you.

Unresolved questions

• Does this RFC cover all type of community effort?
• Does this RFC make community acceptance smooth enough?

Future possibilities

The current RFC already addresses the core issue with community's joining process. However, things that should be implemented throughout the proccess should be explored broader and explain further in the upcoming RFCs. The current implementation is not fully complete and is subjected to further modifications based on upcoming experience.

• Standartization Name: The culture we hold on dear
• Start Date: 2025-04-12
• RFC PR: floss-uz/standards#0004
• STD Issue: floss-uz/standards#0005
• Severity: MUST

Summary

Every technical community is created with one or many goals in mind and certain environment leads to creation and shape of corresponding culture around members of communities. This RFC aims to draw a line between culture and rules defined and maintained by Floss Uzbekistan and show, how your community can adopt the rules and standartizations of Floss Uzbekistan but also keep healthy culture of your community at the same time.

Motivation

Every community is developed and shaped differently and is unique to itself. The generalized term of culture is known to be a set of rules and suggestions developed depending on community's values. Forcing all communities to obey a single source of rules would do serious and vicious impact on communities' balances. In order to find a balance between standards and culture, this RFC was proposed to give communities opportunity to not adopt certain "OPTIONAL" standards.

Detailed design

In order to differentiate "OPTIONAL" and "MUST" implement standards, this RFC proposes a new option list named "Severity" which can have value either "OPTIONAL" or "MUST". Every implementing RFC must include this option in header indicating the level of importance. If a standard is being submitted by member who is not within council party, the standard's severity may be subjected to changes by council before it gets accepted.

A community chair, or maintainer MUST create ".github" repository in their GitHub organization with "RULES.md" file in the repository. There MUST be RULES.md with "Rejected Standards" section in the file showing all "OPTIONAL" standards refused by the community. Also, RULES.md file MUST includes all internal rules and cultural changes created and maintained by the community itself in "Internal Rules" section which must be obeyed by the members of culture. It is up to chair or maintainer's decision whether how to distribute the rules among community members, let it be telegram assistant's /rules command or a website page in their official website.

Guide-level explanation

If you are proposing a new standard:

• After completion of your standard, make sure to include "Severity" option in header list.
• Suggest your own "Severity" and pick either "OPRTIONAL" or "MUST".

As your PR goes through review process, the Severity may change depending on council's decision.

If you are a community chair or maintainer:

Assuming that you have been following through all past standards, you MUST have a GitHub organization.

• Create ".github" repository in your community's GitHub organization.
• Bootstrap default branch in the repository and create "RULES.md" file.
• If you would like to refuse certain "OPTIONAL" standards and rules maintained by Floss Uzbekistan, define "Rejected Standards" section and list all rejected rules and standards with their links to the document.
• If you would like to define your own set of rules and change behavior of certain "OPTIONAL" standards, define "Internal Rules" section and list all your own or custom rules and standards.

Drawbacks

There is a chance that there might be implemented certain "MUST" standards which might not be warmly welcomed by majority of Floss Uzbekistan communities. Therefore, chair party must take some precautions and carefully implement standards step-by-step following all procedures to avoid possible backlashes and keep the balance.

Unresolved questions

• Does this RFC covers all labels of severity?
• Does this RFC cover all sections fo "Code of Conduct"?

Future possibilities

For the time being, the current RFC is limited to only "MUST" and "OPTIONAL" labels. There might be added new labels for "Severity" in foreseable future to complete the necessities of communities.

• Standardization Name: Contributing to FLOSS
• Start Date: 2025-09-12
• RFC PR: floss-uz/standards#0004
• STD Issue: floss-uz/standards#0008
• Severity: MUST

Summary

All members of community have the right to participate in the community development process. We are open to all suggestions and initiatives aimed at development, but we ensure that all these actions are consistent with our culture and do not contradict the general floss movements. We believe that the most important foundation for community development is the contribution of all members, and this RFC is focused on contributing to Floss Uzbekistan.

Motivation

Each community has its own development processes. However, each community has similar or common development processes. We implement all development processes at the Floss Uzbekistan level and require all communities to follow them. This RFC sets standards for contributing to Floss related projects or communities within Floss Uzbekistan and offers it as a programmatic practice to all Floss communities.

Detailed design

A community chair, maintainer or volunteers are also required to follow the contribution rules, otherwise their work will not be accepted. All technical communities can also extend and implement the Floss Uzbekistan standards. However, standards with a severity of MUST are required to be fully implemented. It is important that all project documents are available and accessible to everyone. All projects belonging to the Floss community should have relevant results for the processes that are taking with MUST severity.

In particular, all projects require contributors to submit necessary documents. These documents must state the requirements and guidelines for contributing to the project. The types of documents can vary depending on the type of project or be in the form of reports. For example, events and conferences have different requirements, so the documents related to them are also different.

All actions that do not comply with the standards of the Floss community have the right to be rejected or require changes. Contributors and their work must comply with the copyright standards of Floss. Maintaining and adhering to copyright in the project is required at the level of RFC and OSS culture. In particular, all actions that are inconsistent with or contrary to floss standards are condemned.

Drawbacks

Some MUST standards may not be implemented. Therefore, the chairperson party should take some precautions and carefully implement the standards step by step, following all the procedures to avoid possible backlashes and maintain balance. In some projects, there is a possibility of conflicting point of views, in which case maintainers or chairpersons should participate in resolving these issues.

Unresolved questions

• Does RFC cover organization Open Source Software ?
• Will it be easy to contribute to projects, events based on RFC?
• Should we archive rejected projects?

Future possibilities

This RFC is the first foundational RFC related to contributing. Subsequent RFCs will reflect the documentation needed to contribute to and support the floss community.

• Standardization Name: FLOSS rules on the use of AI.
• Start Date: 2025-10-02
• RFC PR: floss-uz/standards#0004
• STD Issue: floss-uz/standards#0008
• Severity: OPTIONAL

Summary

This RFC explains the rules for using AI to FLOSS community members. RFC reflects the use and contribution of AI tools in community conversations and AI-related issues for FLOSS community members in their activities.

Motivation

We consider this activity to be of great importance for the development of the community, and therefore we are documenting it based on the RFC. This document outlines the issue of interacting with AI tools in the community. The main reason for creating this document is the conflicts of interest regarding interactions with AI in communities.

Detailed design

This issue consists of several sections and focuses on two main sections, and these sections are as follows. Of course, these two issues have been the subject of much discussion in the community, and for this reason, the implementation of some practices has relied more on community opinions.

• Using AI tools in community conversations, debates, and communication processes.
• Using AI tools to contribute to projects within FLOSS.

FLOSS oppose relying on AI-powered sources to inform conversations and debates in all communities. The FLOSS community advocates limiting or rejecting things done with AI. This section of the RFC rejects any references submitted based on AI.

Of course, the issue of AI-based contributions is somewhat controversial. For this reason, the FLOSS community supports somewhat liberal positions on this issue. It should be noted that licensing violations for the submission of AI generated content (including, but not limited to source code and translation strings) is a sole responsibility of the contributor. This means that the situation is somewhat serious, and these issues are still being widely discussed in the OSS community as a whole. For this reason, AI-based contributions are being made OPTIONAL for everyone within the FLOSS community.

Projects and communities belonging to the FLOSS community should implement RULES and CODE OF CONDUCT documents that are fully consistent with or extend these two sections of the RFC. Community chairs and maintainers should modify and implement their own policies based on these, provided they do not conflict with this RFC.

Project documents created using AI or developed with AI MUST include information about the use of AI. This information MUST also be reflected in the license of projects using AI.

Unresolved questions

• What is the licensing issue in AI-based projects?
• How will AI tools be used in the code review process?

Future possibilities

• Standardization name: Mandatory GPLv3 Licensing for FLOSS Uzbekistan Projects
• Start Date: 2025-10-28
• RFC PR: floss-uz/standards#0016
• STD Issue: N/A
• Severity: MUST

Summary

This RFC mandates that all new projects initiated under the FLOSS Uzbekistan network MUST be released under the GNU General Public License, Version 3 (GPLv3). Furthermore, all existing projects currently maintained or formally endorsed by member communities MUST be relicensed under GPLv3. This non-permissive (or copyleft) licensing strategy is proposed to strengthen the local open-source ecosystem by ensuring code, including any future modifications, remains permanently open and available for the entire Uzbek community.

Motivation

The primary goal of FLOSS Uzbekistan is to cultivate a robust, shared technical infrastructure. Using permissive licenses (like MIT or Apache 2.0) allows companies to use and modify the code without contributing their improvements back to the community, effectively creating proprietary forks from public effort. This practice fragments the local ecosystem and siphons value away from the community.

Mandating the GPLv3, a strong copyleft license, ensures that all derivative works built upon the community's projects must also be shared under GPLv3. This legal mechanism compels contribution back to the public pool, guaranteeing that the intellectual effort invested by Uzbek developers collectively benefits the entire FLOSS Uzbekistan network, thereby accelerating the growth and maturity of the local open-source space.

I. Detailed design

All technology-specific communities (e.g., Rust, Haskell, NixOS communities) within FLOSS Uzbekistan MUST adhere to the following licensing mandates:

• New Projects (MUST): Any new open-source project initiated or adopted by a member community after the effective date of this Standard MUST use the GNU General Public License, Version 3 (GPLv3).

• Existing Projects (MUST): All currently existing projects maintained or officially endorsed by member communities MUST begin the process of relicensing under GPLv3. This process requires securing permission from all past and current copyright holders and MUST be completed within a maximum of twelve (12) months from the Standard's adoption date.

• Documentation Requirement (MUST): The project's primary README.md and CONTRIBUTING.md files MUST prominently state that contributions are accepted only under the terms of the GPLv3.

• License File (MUST): Every repository MUST include a copy of the LICENSE file containing the full text of the GPLv3.

II. Copyright and Enforcement

FLOSS Uzbekistan asserts and holds the full copyright for all software projects under its umbrella.

FLOSS Uzbekistan is committed to actively monitoring for violations of the GPLv3 terms. As the copyright holder, FLOSS Uzbekistan reserves the right to monitor and enforce the GPLv3 license to ensure that all recipients and distributors of the software comply with the reciprocal obligations of the license.

Enforcement efforts will be primarily focused on achieving compliance—requiring violators to publicly release the complete and corresponding source code for any distributed software based on or linked to FLOSS Uzbekistan projects.

III. Benefits of Non-Permissive (Copyleft) Licensing over Permissive Licensing

The adoption of a non-permissive license like GPLv3, as opposed to permissive licenses (like MIT, BSD, or Apache 2.0), provides substantial benefits for a community-driven ecosystem like FLOSS Uzbekistan:

1. Guaranteed Freedom and Community Growth (The "Viral" Effect):

   • Permissive: Allows derived proprietary works. A local company can take a community library, improve it, and sell the improved version without sharing the source code, reducing the shared knowledge pool.

   • Non-Permissive (GPLv3): Requires any redistributed software that incorporates the original code (or derived code) to also be released under GPLv3. This powerful copyleft mechanism legally forces downstream developers, including commercial users, to contribute their improvements back to the public, ensuring the community always benefits from the work.

2. Protection Against Fragmentation:

   • Permissive: Creates a risk of "forking" where a company takes the project and continues development privately, leaving the community project to stagnate.

   • Non-Permissive (GPLv3): Discourages the creation of proprietary forks because the forking entity knows they will be legally required to release their changes, promoting a single, robust codebase shared by all local stakeholders.

3. Strengthening Open-Source Principles:

   • Permissive: Primarily benefits users and companies by granting maximal usage rights with minimal legal obligation.

   • Non-Permissive (GPLv3): Primarily benefits the developers and the community by ensuring that the fundamental open-source principles of access, study, modification, and redistribution are maintained for every user, permanently.

IV. Policy on Boarded External Projects

This section defines the policy for projects that were created outside the FLOSS Uzbekistan network but are later adopted or formally recognized by a member community.

• License Retention (MUST): Any existing, previously released software project "boarded" (adopted or officially recognized) into the FLOSS Uzbekistan network MUST retain its Original License. The requirement to relicense to GPLv3 (as detailed in Section III) does not apply to projects with external historical licensing.

• Maintaining the project under GPLv3 (MUST): All future contributions and maintenance work performed by FLOSS Uzbekistan members on a boarded project MUST be licensed under GPLv3, given that the original project is compatible with GPLv3.

• New Components (MUST): Any substantial new module, library, or feature developed entirely from scratch by the FLOSS Uzbekistan community specifically for the boarded project MUST be licensed under GPLv3, provided this is legally compatible with the Original License. This must be clearly documented in a separate LICENSE file for that module.

• Documentation Clarification (MUST): The README.md and CONTRIBUTING.md for boarded projects MUST clearly state the project's Original License and explicitly mention that the GPLv3 mandate for boarded projects does not apply.

Guide-level explanation

For all Maintainers:

• Licensing is Mandatory: Every project you touch or create from now on MUST use the GPLv3 license.

• The Power of Copyleft: When you write code under GPLv3, you guarantee that anyone who builds on your work — even a commercial company — MUST release their own source code. This ensures all improvements come back to our community.

• Relicensing Existing Work: You need to contact everyone who ever made a code contribution to your project (no matter how small) and get their explicit, written permission to change the project's license to GPLv3. This step is non-negotiable for legal compliance. Start this process immediately.

Unresolved questions

• What official FLOSS Uzbekistan resource will be provided to assist communities with the legal process of tracking down and obtaining relicensing consent from past contributors?

• How will the council handle an existing project where relicensing is technically or legally impossible (e.g., a critical mass of contributors cannot be located or refuse consent)?

Future possibilities