2014-03-10 02:33:47 +00:00
|
|
|
# Rust RFCs
|
2014-10-08 11:41:09 +00:00
|
|
|
[Rust RFCs]: #rust-rfcs
|
|
|
|
|
|
|
|
(jump forward to: [Table of Contents], [Active RFC List])
|
2014-03-10 02:33:47 +00:00
|
|
|
|
2014-10-15 15:38:56 +00:00
|
|
|
Many changes, including bug fixes and documentation improvements can be
|
2014-04-04 22:07:19 +00:00
|
|
|
implemented and reviewed via the normal GitHub pull request workflow.
|
2014-03-10 02:33:47 +00:00
|
|
|
|
2014-10-15 15:38:56 +00:00
|
|
|
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 Rust
|
2015-09-18 19:13:24 +00:00
|
|
|
community and the [sub-team]s.
|
2014-04-04 22:07:19 +00:00
|
|
|
|
2014-06-26 03:30:26 +00:00
|
|
|
The "RFC" (request for comments) process is intended to provide a
|
2014-10-15 15:38:56 +00:00
|
|
|
consistent and controlled path for new features to enter the language
|
|
|
|
and standard libraries, so that all stakeholders can be confident about
|
2014-04-04 22:07:19 +00:00
|
|
|
the direction the language is evolving in.
|
|
|
|
|
2014-10-08 11:41:09 +00:00
|
|
|
## Active RFC List
|
|
|
|
[Active RFC List]: #active-rfc-list
|
|
|
|
|
|
|
|
* [0016-more-attributes.md](text/0016-more-attributes.md)
|
|
|
|
* [0019-opt-in-builtin-traits.md](text/0019-opt-in-builtin-traits.md)
|
|
|
|
* [0066-better-temporary-lifetimes.md](text/0066-better-temporary-lifetimes.md)
|
|
|
|
* [0090-lexical-syntax-simplification.md](text/0090-lexical-syntax-simplification.md)
|
|
|
|
* [0107-pattern-guards-with-bind-by-move.md](text/0107-pattern-guards-with-bind-by-move.md)
|
|
|
|
* [0132-ufcs.md](text/0132-ufcs.md)
|
|
|
|
* [0135-where.md](text/0135-where.md)
|
|
|
|
* [0141-lifetime-elision.md](text/0141-lifetime-elision.md)
|
|
|
|
* [0195-associated-items.md](text/0195-associated-items.md)
|
2015-02-16 04:18:18 +00:00
|
|
|
* [0213-defaulted-type-params.md](text/0213-defaulted-type-params.md)
|
2015-04-10 13:30:42 +00:00
|
|
|
* [0218-empty-struct-with-braces.md](text/0218-empty-struct-with-braces.md)
|
2015-02-05 14:42:47 +00:00
|
|
|
* [0320-nonzeroing-dynamic-drop.md](text/0320-nonzeroing-dynamic-drop.md)
|
2014-10-30 22:32:12 +00:00
|
|
|
* [0339-statically-sized-literals.md](text/0339-statically-sized-literals.md)
|
2014-10-24 03:16:41 +00:00
|
|
|
* [0385-module-system-cleanup.md](text/0385-module-system-cleanup.md)
|
2014-11-18 23:07:09 +00:00
|
|
|
* [0401-coercions.md](text/0401-coercions.md)
|
2015-02-16 04:18:18 +00:00
|
|
|
* [0447-no-unused-impl-parameters.md](text/0447-no-unused-impl-parameters.md)
|
2015-03-06 16:19:30 +00:00
|
|
|
* [0495-array-pattern-changes.md](text/0495-array-pattern-changes.md)
|
2015-02-16 04:18:18 +00:00
|
|
|
* [0501-consistent_no_prelude_attributes.md](text/0501-consistent_no_prelude_attributes.md)
|
2014-12-18 19:16:36 +00:00
|
|
|
* [0509-collections-reform-part-2.md](text/0509-collections-reform-part-2.md)
|
2015-02-16 04:18:18 +00:00
|
|
|
* [0517-io-os-reform.md](text/0517-io-os-reform.md)
|
|
|
|
* [0560-integer-overflow.md](text/0560-integer-overflow.md)
|
2015-04-10 10:07:07 +00:00
|
|
|
* [0639-discriminant-intrinsic.md](text/0639-discriminant-intrinsic.md)
|
2015-02-10 17:19:39 +00:00
|
|
|
* [0769-sound-generic-drop.md](text/0769-sound-generic-drop.md)
|
2015-04-15 04:32:40 +00:00
|
|
|
* [0771-std-iter-once.md](text/0771-std-iter-once.md)
|
2015-03-16 18:13:21 +00:00
|
|
|
* [0803-type-ascription.md](text/0803-type-ascription.md)
|
2015-02-11 16:31:04 +00:00
|
|
|
* [0809-box-and-in-for-stdlib.md](text/0809-box-and-in-for-stdlib.md)
|
2015-07-23 20:27:44 +00:00
|
|
|
* [0873-type-macros.md](text/0873-type-macros.md)
|
2015-04-25 22:20:26 +00:00
|
|
|
* [0888-compiler-fence-intrinsics.md](text/0888-compiler-fence-intrinsics.md)
|
2015-03-20 06:15:57 +00:00
|
|
|
* [0909-move-thread-local-to-std-thread.md](text/0909-move-thread-local-to-std-thread.md)
|
2015-04-06 14:24:56 +00:00
|
|
|
* [0911-const-fn.md](text/0911-const-fn.md)
|
2015-03-16 20:19:18 +00:00
|
|
|
* [0968-closure-return-type-syntax.md](text/0968-closure-return-type-syntax.md)
|
2015-08-07 16:33:27 +00:00
|
|
|
* [0980-read-exact.md](text/0980-read-exact.md)
|
2015-06-03 19:38:45 +00:00
|
|
|
* [0982-dst-coercion.md](text/0982-dst-coercion.md)
|
2015-03-31 22:34:52 +00:00
|
|
|
* [0979-align-splitn-with-other-languages.md](text/0979-align-splitn-with-other-languages.md)
|
2015-03-31 22:40:09 +00:00
|
|
|
* [1011-process.exit.md](text/1011-process.exit.md)
|
2015-03-31 23:03:50 +00:00
|
|
|
* [1023-rebalancing-coherence.md](text/1023-rebalancing-coherence.md)
|
2015-04-28 23:36:18 +00:00
|
|
|
* [1040-duration-reform.md](text/1040-duration-reform.md)
|
2015-04-24 23:42:17 +00:00
|
|
|
* [1044-io-fs-2.1.md](text/1044-io-fs-2.1.md)
|
2015-05-07 17:24:49 +00:00
|
|
|
* [1066-safe-mem-forget.md](text/1066-safe-mem-forget.md)
|
2015-06-04 18:24:54 +00:00
|
|
|
* [1096-remove-static-assert.md](text/1096-remove-static-assert.md)
|
2015-06-10 15:48:32 +00:00
|
|
|
* [1122-language-semver.md](text/1122-language-semver.md)
|
2015-06-10 15:25:17 +00:00
|
|
|
* [1131-likely-intrinsic.md](text/1131-likely-intrinsic.md)
|
2015-06-19 20:35:40 +00:00
|
|
|
* [1156-adjust-default-object-bounds.md](text/1156-adjust-default-object-bounds.md)
|
2015-07-30 01:47:23 +00:00
|
|
|
* [1184-stabilize-no_std.md](text/1184-stabilize-no_std.md)
|
2015-08-07 12:04:36 +00:00
|
|
|
* [1214-projections-lifetimes-and-wf.md](text/1214-projections-lifetimes-and-wf.md)
|
2015-08-07 10:35:59 +00:00
|
|
|
* [1219-use-group-as.md](text/1219-use-group-as.md)
|
2014-10-08 11:41:09 +00:00
|
|
|
|
|
|
|
## Table of Contents
|
|
|
|
[Table of Contents]: #table-of-contents
|
|
|
|
* [Opening](#rust-rfcs)
|
|
|
|
* [Active RFC List]
|
|
|
|
* [Table of Contents]
|
|
|
|
* [When you need to follow this process]
|
2014-12-05 23:06:41 +00:00
|
|
|
* [Before creating an RFC]
|
2014-10-08 11:41:09 +00:00
|
|
|
* [What the process is]
|
|
|
|
* [The role of the shepherd]
|
|
|
|
* [The RFC life-cycle]
|
|
|
|
* [Reviewing RFC's]
|
2014-12-05 23:06:41 +00:00
|
|
|
* [Implementing an RFC]
|
2014-10-08 11:41:09 +00:00
|
|
|
* [RFC Postponement]
|
|
|
|
* [Help this is all too informal!]
|
|
|
|
|
2015-09-18 19:13:24 +00:00
|
|
|
|
2014-04-04 22:07:19 +00:00
|
|
|
## When you need to follow this process
|
2014-10-08 11:41:09 +00:00
|
|
|
[When you need to follow this process]: #when-you-need-to-follow-this-process
|
2014-04-04 22:07:19 +00:00
|
|
|
|
2015-09-18 19:13:24 +00:00
|
|
|
You need to follow this process if you intend to make "substantial" changes to
|
|
|
|
Rust, Cargo, Crates.io, or the RFC process itself. What constitutes a
|
|
|
|
"substantial" change is evolving based on community norms and varies depending
|
|
|
|
on what part of the ecosystem you are proposing to change, but may include the
|
|
|
|
following.
|
2014-04-04 22:07:19 +00:00
|
|
|
|
|
|
|
- Any semantic or syntactic change to the language that is not a bugfix.
|
2014-06-26 00:42:11 +00:00
|
|
|
- Removing language features, including those that are feature-gated.
|
2015-09-18 19:13:24 +00:00
|
|
|
- Changes to the interface between the compiler and libraries, including lang
|
|
|
|
items and intrinsics.
|
|
|
|
- Additions to `std`.
|
2014-04-04 22:07:19 +00:00
|
|
|
|
|
|
|
Some changes do not require an RFC:
|
|
|
|
|
2014-10-15 15:38:56 +00:00
|
|
|
- Rephrasing, reorganizing, refactoring, or otherwise "changing shape
|
2014-04-04 22:07:19 +00:00
|
|
|
does not change meaning".
|
2014-10-15 15:38:56 +00:00
|
|
|
- Additions that strictly improve objective, numerical quality
|
|
|
|
criteria (warning removal, speedup, better platform coverage, more
|
2014-04-04 22:07:19 +00:00
|
|
|
parallelism, trap more errors, etc.)
|
2014-10-15 15:38:56 +00:00
|
|
|
- Additions only likely to be _noticed by_ other developers-of-rust,
|
2014-04-04 22:07:19 +00:00
|
|
|
invisible to users-of-rust.
|
|
|
|
|
2014-10-15 15:38:56 +00:00
|
|
|
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
|
2014-04-04 22:07:19 +00:00
|
|
|
submit an RFC first.
|
|
|
|
|
2015-09-18 19:13:24 +00:00
|
|
|
For more details on when an RFC is required, please see the following specific
|
|
|
|
guidelines, these correspond with some of the Rust community's
|
|
|
|
[sub-teams](http://www.rust-lang.org/team.html):
|
|
|
|
|
|
|
|
* [language changes](lang_changes.md),
|
|
|
|
* [library changes](libs_changes.md),
|
|
|
|
* [compiler changes](compiler_changes.md).
|
|
|
|
|
|
|
|
|
2014-12-05 23:06:41 +00:00
|
|
|
## Before creating an RFC
|
|
|
|
[Before creating an RFC]: #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 #rust-internals, filing and discusssing ideas
|
|
|
|
on the [RFC issue tracker][issues], and occasionally posting
|
|
|
|
'pre-RFCs' on [the developer discussion forum][discuss] for early
|
|
|
|
review.
|
|
|
|
|
|
|
|
As a rule of thumb, receiving encouraging feedback from long-standing
|
2015-09-18 19:13:24 +00:00
|
|
|
project developers, and particularly members of the relevant [sub-team]
|
2014-12-05 23:06:41 +00:00
|
|
|
is a good indication that the RFC is worth pursuing.
|
|
|
|
|
|
|
|
[issues]: https://github.com/rust-lang/rfcs/issues
|
|
|
|
[discuss]: http://discuss.rust-lang.org/
|
2015-09-18 19:13:24 +00:00
|
|
|
|
2014-12-05 23:06:41 +00:00
|
|
|
|
2014-04-04 22:07:19 +00:00
|
|
|
## What the process is
|
2014-10-08 11:41:09 +00:00
|
|
|
[What the process is]: #what-the-process-is
|
2014-12-05 23:06:41 +00:00
|
|
|
|
2014-10-15 15:38:56 +00:00
|
|
|
In short, to get a major feature added to Rust, 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
|
2014-04-04 22:07:19 +00:00
|
|
|
into Rust.
|
|
|
|
|
|
|
|
* Fork the RFC repo http://github.com/rust-lang/rfcs
|
2015-09-18 19:13:24 +00:00
|
|
|
* Copy `0000-template.md` to `text/0000-my-feature.md` (where 'my-feature' is
|
|
|
|
descriptive. don't assign an RFC number yet).
|
|
|
|
* Fill in the RFC. Put care into the details: RFCs that do not present
|
|
|
|
convincing motivation, demonstrate understanding of the impact of the design, 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.
|
|
|
|
* Each pull request will be labeled with the most relevant [sub-team].
|
|
|
|
* Each sub-team triages its RFC PRs. The sub-team will will either close the PR
|
|
|
|
(for RFCs that clearly will not be accepted) or assign it a *shepherd*. The
|
|
|
|
shepherd is a trusted developer who is familiar with the RFC process, who will
|
|
|
|
help to move the RFC forward, and ensure that the right people see and review
|
|
|
|
it.
|
|
|
|
* 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. The
|
|
|
|
shepherd assigned to your RFC should help you get feedback from Rust developers
|
|
|
|
as well.
|
2014-12-05 23:06:41 +00:00
|
|
|
* The shepherd may schedule meetings with the author and/or relevant
|
2015-09-18 19:13:24 +00:00
|
|
|
stakeholders to discuss the issues in greater detail.
|
|
|
|
* The sub-team will discuss the RFC PR, as much as possible in the comment
|
|
|
|
thread of the PR itself. Offline discussion will be summarized on the PR comment
|
|
|
|
thread.
|
|
|
|
* Once both proponents and opponents have clarified and defended positions and
|
|
|
|
the conversation has settled, the RFC will enter its *final comment period*
|
|
|
|
(FCP). This is a final opportunity for the community to comment on the PR and is
|
|
|
|
a reminder for all members of the sub-team to be aware of the RFC.
|
|
|
|
* The FCP lasts one week. It may be extended if consensus between sub-team
|
|
|
|
members cannot be reached. At the end of the FCP, the [sub-team] will either
|
|
|
|
accept the RFC by merging the pull request, assigning the RFC a number
|
|
|
|
(corresponding to the pull request number), at which point the RFC is 'active',
|
|
|
|
or reject it by closing the pull request. How exactly the sub-team decide on an
|
|
|
|
RFC is up to the sub-team.
|
|
|
|
|
2014-04-04 22:07:19 +00:00
|
|
|
|
2014-10-01 00:52:47 +00:00
|
|
|
## The role of the shepherd
|
2015-06-20 01:26:55 +00:00
|
|
|
[The role of the shepherd]: #the-role-of-the-shepherd
|
2014-09-09 00:30:46 +00:00
|
|
|
|
2015-09-18 19:13:24 +00:00
|
|
|
During triage, every RFC will either be closed or assigned a shepherd from the
|
|
|
|
relevant sub-team. The role of the shepherd is to move the RFC through the
|
|
|
|
process. This starts with simply reading the RFC in detail and providing initial
|
|
|
|
feedback. The shepherd should also solicit feedback from people who are likely
|
|
|
|
to have strong opinions about the RFC. When this feedback has been incorporated
|
|
|
|
and the RFC seems to be in a steady state, the shepherd and/or sub-team leader
|
|
|
|
will announce an FCP. In general, the idea here is to "front-load" as much of
|
|
|
|
the feedback as possible before the point where we actually reach a decision -
|
|
|
|
by the end of the FCP, the decision on whether or not to accept the RFC should
|
|
|
|
usually be obvious from the RFC discussion thread. On occasion, there may not be
|
|
|
|
consensus but discussion has stalled. In this case, the relevant team will make
|
|
|
|
a decision.
|
|
|
|
|
2014-09-09 00:30:46 +00:00
|
|
|
|
2014-08-01 17:09:24 +00:00
|
|
|
## The RFC life-cycle
|
2014-10-08 11:41:09 +00:00
|
|
|
[The RFC life-cycle]: #the-rfc-life-cycle
|
2014-08-01 17:09:24 +00:00
|
|
|
|
2014-12-05 23:06:41 +00:00
|
|
|
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.
|
2014-04-04 22:07:19 +00:00
|
|
|
|
2014-08-01 17:09:24 +00:00
|
|
|
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.
|
2014-12-08 20:11:06 +00:00
|
|
|
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.
|
2014-08-01 17:09:24 +00:00
|
|
|
|
2015-09-18 19:13:24 +00:00
|
|
|
Modifications to active RFC's can be done in follow-up PR's. We strive
|
2014-08-01 17:09:24 +00:00
|
|
|
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
|
2015-09-18 19:13:24 +00:00
|
|
|
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. There are some more
|
|
|
|
specific guidelines in the sub-team RFC guidelines for the [language](lang_changes.md),
|
|
|
|
[libraries](libs_changes.md), and [compiler](compiler_changes.md).
|
2014-08-01 17:09:24 +00:00
|
|
|
|
|
|
|
|
2014-12-05 23:06:41 +00:00
|
|
|
## Reviewing RFC's
|
|
|
|
[Reviewing RFC's]: #reviewing-rfcs
|
|
|
|
|
|
|
|
While the RFC PR is up, the shepherd may schedule meetings with the
|
|
|
|
author and/or relevant stakeholders to discuss the issues in greater
|
2015-09-18 19:13:24 +00:00
|
|
|
detail, and in some cases the topic may be discussed at a sub-team
|
|
|
|
meeting. In either case a summary from the meeting will be
|
2014-12-05 23:06:41 +00:00
|
|
|
posted back to the RFC pull request.
|
|
|
|
|
2015-09-18 19:13:24 +00:00
|
|
|
A sub-team makes final decisions about RFCs after the benefits and drawbacks are
|
|
|
|
well understood. These decisions can be made at any time, but the sub-team will
|
|
|
|
regularly issue decisions. When a decision is made, the RFC PR will either be
|
|
|
|
merged or closed. In either case, if the reasoning is not clear from the
|
|
|
|
discussion in thread, the sub-team will add a comment describing the rationale
|
|
|
|
for the decision.
|
|
|
|
|
2014-12-05 23:06:41 +00:00
|
|
|
|
2014-08-01 17:09:24 +00:00
|
|
|
## Implementing an RFC
|
2014-10-08 11:41:09 +00:00
|
|
|
[Implementing an RFC]: #implementing-an-rfc
|
2014-08-01 17:09:24 +00:00
|
|
|
|
|
|
|
Some accepted RFC's represent vital features that need to be
|
|
|
|
implemented right away. Other accepted RFC's can represent features
|
|
|
|
that can wait until some arbitrary developer feels like doing the
|
|
|
|
work. Every accepted RFC has an associated issue tracking its
|
|
|
|
implementation in the Rust repository; thus that associated issue can
|
2015-09-18 19:13:24 +00:00
|
|
|
be assigned a priority via the triage process that the team uses for
|
2014-08-01 17:09:24 +00:00
|
|
|
all issues in the Rust repository.
|
|
|
|
|
|
|
|
The author of an RFC is not obligated to implement it. Of course, the
|
|
|
|
RFC author (like any other developer) 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).
|
|
|
|
|
2015-09-18 19:13:24 +00:00
|
|
|
|
2014-08-01 17:09:24 +00:00
|
|
|
## RFC Postponement
|
2014-10-08 11:41:09 +00:00
|
|
|
[RFC Postponement]: #rfc-postponement
|
2014-08-01 17:09:24 +00:00
|
|
|
|
2015-09-18 19:13:24 +00:00
|
|
|
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. Historically,
|
|
|
|
"postponed" was used to postpone features until after 1.0. Postponed PRs 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 sub-team.
|
2014-08-01 17:09:24 +00:00
|
|
|
|
|
|
|
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.)
|
|
|
|
|
2014-04-04 22:07:19 +00:00
|
|
|
|
|
|
|
### Help this is all too informal!
|
2014-10-08 11:41:09 +00:00
|
|
|
[Help this is all too informal!]: #help-this-is-all-too-informal
|
2014-04-04 22:07:19 +00:00
|
|
|
|
2014-10-15 15:38:56 +00:00
|
|
|
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
|
2014-04-04 22:07:19 +00:00
|
|
|
necessary.
|
|
|
|
|
2015-09-18 19:13:24 +00:00
|
|
|
[sub-team]: http://www.rust-lang.org/team.html
|