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

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:

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: 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?

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.

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.