Re: [rust-dev] RFC: Updated RFC process

[Jack Moffitt]

>> We should also use tags: `Rejected` / `Approved`
>
> I'm specifically trying to avoid those words :) 'approved' is stronger than
> I want, because an approved RFC still may not get merged into the language,
> and being 'rejected' is unfun.

XMPP uses the XEP process, which has decent names for things:
http://xmpp.org/extensions/xep-0001.html#states

Things progress from the inbox (the XSF equivalent of a pull request
queue) through the different states. Here are the main ones:

Experimental, Draft, Final, Deprecated, Obsolete, Rejected.

Every week or so the XSF Council convenes to discuss the pending XEPs
in the inbox, and advances them to Experimental or gives feedback.

Obviously the standards process has different requirements, but it
seems reasonable to steal some of these state names.

jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Updated RFC process

[Brian Anderson]

On 03/12/2014 03:42 AM, Simon Sapin wrote:

On 12/03/2014 01:11, Brian Anderson wrote:

* Fork the RFC repohttp://github.com/rust-lang/rfcs
* Copy `-template.md` to `active/-my-feature.md` (where
'my-feature' is descriptive. don't 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 and assigning the RFC a number, at which point
the RFC is 'active', or reject it by closing the pull request.


Should the mailing list be involved in this process, as a way to get
more people discussing RFCs? (Maybe automatically with a bot sending
email for every PR in the RFC repo.)


Explicitly, no. rust-dev has a broad audience, few moderation options, 
and discussions tend to derail quickly.




On the other hand, we probably don’t want to fragment the discussion
between GitHub issues and email.



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Updated RFC process

[Brian Anderson]

On 03/12/2014 12:54 AM, Flaper87 wrote:




2014-03-12 2:11 GMT+01:00 Brian Anderson mailto:bander...@mozilla.com>>:

[snip]

-

Many changes, including bug 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
Rust community and the [core team].

The "RFC" (request for comments process) is intended to provide a
consistent and controlled path for new features to enter the
language and standard libraries, so that all stakeholders can be
confident about the direction the language is evolving in.

## When you need to follow this process

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

   - Any semantic or syntactic change to the language that is not a
bugfix.
   - Changes to the interface between the compiler and libraries,
including lang items and intrinsics.
   - Additions to `std`

Some changes do not require an RFC:

   - Rephrasing, reorganizing, refactoring, or otherwise "changing
shape does not change meaning".
   - Additions that strictly improve objective, numerical quality
criteria (warning removal, speedup, better platform coverage, more
parallelism, trap more errors, etc.)
   - Additions only likely to be _noticed by_ other
developers-of-rust, invisible to users-of-rust.

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 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 into Rust.

* Fork the RFC repo http://github.com/rust-lang/__rfcs

* Copy `-template.md ` to
`active/-my-feature.md ` (where
'my-feature' is descriptive. don't assign an RFC number yet).


What about using the PR's number? That means we'll end up with some gaps
between accepted RFCs but... just thinking aloud.


We've discussed this but decided against, though the argument doesn't 
seem to be that strong either way.





* 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 and assigning the RFC a number, at which
point the RFC is 'active', or reject it by closing the pull request.


We should also use tags: `Rejected` / `Approved`


I'm specifically trying to avoid those words :) 'approved' is stronger 
than I want, because an approved RFC still may not get merged into the 
language, and being 'rejected' is unfun.





I'm wondering if we should keep rejected RFCs too and not just as closed
PRs. If for some reason, this repo is moved out of GH in the future,
we'd loose a bunch of RFC history. We could keep the first rejected RFC
for a type of change and reject future duplicated RFCs by linking them
to that RFC. Not sure about this, though.


I do think this is a good idea, particularly for good RFCs that we 
nonetheless don't want to implement. I haven't put any language in about 
doing this but I suspect it will happen anyway when the proper case arises.





Once an RFC becomes active then authors may implement it and submit
the feature as a pull request to the Rust repo. 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 moved to the 'complete' folder; an RFC
that fails after becoming active is 'inactive' and moves to the
'inactive' folder.


We also need a way to track who's working on that RFC. Should an RFC bug
be created in Rust's repo and be linked to the real RFC ? This way folks
can raise their hands and work on the RFC, it's also a good place for
follow-up discussions on the work happening for that RFC, etc. The
person proposing the RFC is not necessarily the one that will work on it.


I've add

Re: [rust-dev] RFC: Updated RFC process

[Benjamin Striegel]

> Should the mailing list be involved in this process, as a way to get more
people discussing RFCs?

I'm using Github's "watch" feature on the RFC repo so that I am
automatically emailed whenever a new PR pops up or a discussion occurs.
These emails then get filtered to a "Rust RFCs" folder for easier review.
Perhaps this approach could work for others as well.


On Wed, Mar 12, 2014 at 6:42 AM, Simon Sapin  wrote:

> On 12/03/2014 01:11, Brian Anderson wrote:
>
>> * Fork the RFC repohttp://github.com/rust-lang/rfcs
>>
>> * Copy `-template.md` to `active/-my-feature.md` (where
>> 'my-feature' is descriptive. don't 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 and assigning the RFC a number, at which point
>> the RFC is 'active', or reject it by closing the pull request.
>>
>
> Should the mailing list be involved in this process, as a way to get more
> people discussing RFCs? (Maybe automatically with a bot sending email for
> every PR in the RFC repo.)
>
> On the other hand, we probably don't want to fragment the discussion
> between GitHub issues and email.
>
> --
> Simon Sapin
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Updated RFC process

[Simon Sapin]

On 12/03/2014 01:11, Brian Anderson wrote:

* Fork the RFC repohttp://github.com/rust-lang/rfcs
* Copy `-template.md` to `active/-my-feature.md` (where
'my-feature' is descriptive. don't 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 and assigning the RFC a number, at which point
the RFC is 'active', or reject it by closing the pull request.


Should the mailing list be involved in this process, as a way to get 
more people discussing RFCs? (Maybe automatically with a bot sending 
email for every PR in the RFC repo.)


On the other hand, we probably don’t want to fragment the discussion 
between GitHub issues and email.


--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Updated RFC process

[Benjamin Striegel]

Rather than discuss this here, let's start dogfooding:

https://github.com/rust-lang/rfcs/pull/2


On Wed, Mar 12, 2014 at 3:54 AM, Flaper87  wrote:

>
>
>
> 2014-03-12 2:11 GMT+01:00 Brian Anderson :
>
> [snip]
>
>
>> -
>>
>> Many changes, including bug 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 Rust
>> community and the [core team].
>>
>> The "RFC" (request for comments process) is intended to provide a
>> consistent and controlled path for new features to enter the language and
>> standard libraries, so that all stakeholders can be confident about the
>> direction the language is evolving in.
>>
>> ## When you need to follow this process
>>
>> You need to follow this process if you intend to make "substantial"
>> changes to the Rust distribution. What constitutes a "substantial" change
>> is evolving based on community norms, but may include the following.
>>
>>   - Any semantic or syntactic change to the language that is not a bugfix.
>>   - Changes to the interface between the compiler and libraries,
>> including lang items and intrinsics.
>>   - Additions to `std`
>>
>> Some changes do not require an RFC:
>>
>>   - Rephrasing, reorganizing, refactoring, or otherwise "changing shape
>> does not change meaning".
>>   - Additions that strictly improve objective, numerical quality criteria
>> (warning removal, speedup, better platform coverage, more parallelism, trap
>> more errors, etc.)
>>   - Additions only likely to be _noticed by_ other developers-of-rust,
>> invisible to users-of-rust.
>>
>> 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 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 into
>> Rust.
>>
>> * Fork the RFC repo http://github.com/rust-lang/rfcs
>> * Copy `-template.md` to `active/-my-feature.md` (where
>> 'my-feature' is descriptive. don't assign an RFC number yet).
>>
>
> What about using the PR's number? That means we'll end up with some gaps
> between accepted RFCs but... just thinking aloud.
>
>
>
>> * 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 and assigning the RFC a number, at which point the
>> RFC is 'active', or reject it by closing the pull request.
>>
>
> We should also use tags: `Rejected` / `Approved`
>
> I'm wondering if we should keep rejected RFCs too and not just as closed
> PRs. If for some reason, this repo is moved out of GH in the future, we'd
> loose a bunch of RFC history. We could keep the first rejected RFC for a
> type of change and reject future duplicated RFCs by linking them to that
> RFC. Not sure about this, though.
>
>
> Once an RFC becomes active then authors may implement it and submit the
>> feature as a pull request to the Rust repo. 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 moved to the 'complete' folder; an RFC that fails after
>> becoming active is 'inactive' and moves to the 'inactive' folder.
>>
>
> We also need a way to track who's working on that RFC. Should an RFC bug
> be created in Rust's repo and be linked to the real RFC ? This way folks
> can raise their hands and work on the RFC, it's also a good place for
> follow-up discussions on the work happening for that RFC, etc. The person
> proposing the RFC is not necessarily the one that will work on it.
>
> I was going to suggest having a way to automatically close and move the
> active RFC under the complete folder but I think this process requires some
> double checking from the [core team] so I'd prefer keeping it that way.
>
>
>
>> ### 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.
>>
>
> FWIW, I've seen a similar process being i

Re: [rust-dev] RFC: Updated RFC process

[Flaper87]

2014-03-12 2:11 GMT+01:00 Brian Anderson :

[snip]


> -
>
> Many changes, including bug 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 Rust
> community and the [core team].
>
> The "RFC" (request for comments process) is intended to provide a
> consistent and controlled path for new features to enter the language and
> standard libraries, so that all stakeholders can be confident about the
> direction the language is evolving in.
>
> ## When you need to follow this process
>
> You need to follow this process if you intend to make "substantial"
> changes to the Rust distribution. What constitutes a "substantial" change
> is evolving based on community norms, but may include the following.
>
>   - Any semantic or syntactic change to the language that is not a bugfix.
>   - Changes to the interface between the compiler and libraries, including
> lang items and intrinsics.
>   - Additions to `std`
>
> Some changes do not require an RFC:
>
>   - Rephrasing, reorganizing, refactoring, or otherwise "changing shape
> does not change meaning".
>   - Additions that strictly improve objective, numerical quality criteria
> (warning removal, speedup, better platform coverage, more parallelism, trap
> more errors, etc.)
>   - Additions only likely to be _noticed by_ other developers-of-rust,
> invisible to users-of-rust.
>
> 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 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 into
> Rust.
>
> * Fork the RFC repo http://github.com/rust-lang/rfcs
> * Copy `-template.md` to `active/-my-feature.md` (where
> 'my-feature' is descriptive. don't assign an RFC number yet).
>

What about using the PR's number? That means we'll end up with some gaps
between accepted RFCs but... just thinking aloud.



> * 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 and assigning the RFC a number, at which point the
> RFC is 'active', or reject it by closing the pull request.
>

We should also use tags: `Rejected` / `Approved`

I'm wondering if we should keep rejected RFCs too and not just as closed
PRs. If for some reason, this repo is moved out of GH in the future, we'd
loose a bunch of RFC history. We could keep the first rejected RFC for a
type of change and reject future duplicated RFCs by linking them to that
RFC. Not sure about this, though.


Once an RFC becomes active then authors may implement it and submit the
> feature as a pull request to the Rust repo. 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 moved to the 'complete' folder; an RFC that fails after
> becoming active is 'inactive' and moves to the 'inactive' folder.
>

We also need a way to track who's working on that RFC. Should an RFC bug be
created in Rust's repo and be linked to the real RFC ? This way folks can
raise their hands and work on the RFC, it's also a good place for follow-up
discussions on the work happening for that RFC, etc. The person proposing
the RFC is not necessarily the one that will work on it.

I was going to suggest having a way to automatically close and move the
active RFC under the complete folder but I think this process requires some
double checking from the [core team] so I'd prefer keeping it that way.



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

FWIW, I've seen a similar process being implemented in other projects.
Using the review infrastructure to propose RFCs sounds like a good idea to
me. The only bit that worries me is having a good way to search through the
RFCs history (like real search, not just `git grep` or GH's search field),
hence the proposal of keeping som

[rust-dev] RFC: Updated RFC process

[Brian Anderson]

Hey, Rusties.

The freewheeling way that we add new features to Rust has been good for 
early development, but for Rust to become a mature platform we need to 
develop some more self-discipline when it comes to changing the system. 
So this is a proposed modification to our current RFC process to make it 
a more integral part of the overall development process, and one that is 
followed consistently to introduce features to Rust.


Some improvements I would like this to bring over the current process 
include:


* Discourage unactionable or vague RFCs
* Ensure that all serious RFCs are considered equally
* Those with a stake in Rust's development should feel confident they 
understand why new features are being merged


Below is the proposed change to the RFC process. Please read and 
comment. Assuming the feedback is positive I'll update the wiki with 
this later.


-

Many changes, including bug 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 Rust 
community and the [core team].


The "RFC" (request for comments process) is intended to provide a 
consistent and controlled path for new features to enter the language 
and standard libraries, so that all stakeholders can be confident about 
the direction the language is evolving in.


## When you need to follow this process

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


  - Any semantic or syntactic change to the language that is not a bugfix.
  - Changes to the interface between the compiler and libraries, 
including lang items and intrinsics.

  - Additions to `std`

Some changes do not require an RFC:

  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape 
does not change meaning".
  - Additions that strictly improve objective, numerical quality 
criteria (warning removal, speedup, better platform coverage, more 
parallelism, trap more errors, etc.)
  - Additions only likely to be _noticed by_ other developers-of-rust, 
invisible to users-of-rust.


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 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 
into Rust.


* Fork the RFC repo http://github.com/rust-lang/rfcs
* Copy `-template.md` to `active/-my-feature.md` (where 
'my-feature' is descriptive. don't 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 and assigning the RFC a number, at which point 
the RFC is 'active', or reject it by closing the pull request.


Once an RFC becomes active then authors may implement it and submit the 
feature as a pull request to the Rust repo. 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 moved to the 'complete' folder; an RFC that fails 
after becoming active is 'inactive' and moves to the 'inactive' folder.


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


[core team]: https://github.com/mozilla/rust/wiki/Note-core-team
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev