Skip to content

Update CFT, RFC and FCP sections for TWiR-443 #3260

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
May 19, 2022
Merged

Update CFT, RFC and FCP sections for TWiR-443 #3260

Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
65113e0
Update CFT, RFC and FCP sections for TWiR-443
Xandkeeper May 17, 2022
5150fa1
Update CFT with additional information
Xandkeeper May 17, 2022
c69fd08
Flip CFT item order (pre-stabilization item first)
Xandkeeper May 17, 2022
cfca738
Add CFT item `Tracking Issue for scoped threads`
Xandkeeper May 17, 2022
c20a6e9
Update 2022-05-18-this-week-in-rust.md: Added Asteracea
Tamschi May 14, 2022
8dfddb7
Update 2022-05-18-this-week-in-rust.md
tyt2y3 May 15, 2022
5133a0c
Link to new Compiler Adventures episode in Walkthroughs
obi1kenobi May 17, 2022
af6e167
Add events for TWIR 443
mariannegoldin May 18, 2022
a871d7a
Add instructions for feature implementers on how to request inclusion…
Xandkeeper May 18, 2022
c890f82
Merge branch 'master' into twir-443
Xandkeeper May 19, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 38 additions & 4 deletions draft/2022-05-18-this-week-in-rust.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -83,15 +83,49 @@ If you are a Rust project owner and are looking for contributors, please submit

<!-- Perf results go here -->

### Call for Testing
### Call for Testing (*New!*)

An important step for RFC implementation is for people to experiment with the
implementation and give feedback, especially before stabilization. The following
RFCs are at point where user testing is needed before moving forward:
RFCs would benefit from user testing before moving forward:

<!-- Pre-Stabilization RFCs go here -->
* [RFC: Deduplicate Cargo workspace information](https://github.com/rust-lang/rfcs/pull/2906)
- [Tracking Issue](https://github.com/rust-lang/cargo/issues/8415)
- [Testing steps](https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/unstable.md#testing-notes)
Comment on lines +92 to +94
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What're your thoughts on this structure? I know this is what I had but I was worried it was too different of a format from other things around it.

As well should we use tracking issues or summary posts (where there are ones). Summary posts may give a more in-depth look than just the tracking issue i.e. Tracking Issue vs Sumamry

Copy link
Contributor Author

@U007D U007D May 17, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine--I like the structure.

I anticipate wide variability in the amount of information that different RFC's, TIs, Summaries, etc. will provide. What is nice about this format is it compresses or expands elegantly to accommodate that variability. In the end, I adopted it into the MR.

I am not sure yet to what degree the Call for Testing section will benefit from "categories", and if yes, what the "categories" should be. Pre-stabilization and interim design seem reasonable (although I feel the names could do with a little bikeshedding to clarify to the reader where in the process the feature is), but is there an alternative slicing of these features that ends up being more useful to the community? As we get a larger sample size of features, it should become clearer where (if needed) the natural lines of division should fall.

Re: Tracking Issue vs Summary, I think primarily something is better than nothing--i.e. I'd take either! :). Given the choice, the Summary is more focused and probably higher signal-to-noise to the prospective tester, so I guess there's a (slight) preference for that, but in the end, the author would tag their document as call-for-testing and add a comment to the document thread. That comment could be the tester instructions, or could point to a TI or Summary at the discretion of the author. In all cases, I'd pick that metadata up as part of the Call for Testing line item.

A key goal is to enable more feature testing, more information flow with a minimum of process overhead, and iterate over time as we see more traction and discover what works. I have seen that often planning too heavy/specific a process can prevent the feature from shipping, so I'm glad we're bypassing that here. :)

Is that the feedback you were looking for?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's perfect! I am updating some of the cargo docs to include the updates to TWiR. This comment as well as a few others will be helpful as I write those

* [Tracking Issue for scoped threads](https://github.com/rust-lang/rust/issues/93203)
- [Feature documentation](https://doc.rust-lang.org/nightly/std/thread/fn.scope.html)
* [RFC: Packages as (optional) namespaces](https://github.com/rust-lang/rfcs/pull/3243)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should testing notes always be included in this section? Giving only the RFC without how to test the changes might be confusing

Copy link
Contributor Author

@U007D U007D May 17, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe?

I think we should gather a couple of weeks of data and conversations to determine whether testing notes should be a blocking condition to appearing in TWiR. As I mentioned above, I'm guessing we're going to see a lot of variability, so if you have a strong preference one way or the other, let me know and I'll include that in the thinking that is all but certain to occur over the next couple of weeks.

My bias is to keep it simple: An author looking for testing help should know that when they apply the call-for-testing tag without metadata, TWiR will run it without any metadata and they can expect a correspondingly low response rate. This will hopefully drive a higher rate of test notes.

This policy also makes the weekly publishing exercise much simpler; rather than having to track whose tags are new, who added metadata, say, 5 weeks after adding the tag, etc. I'd like to be able to say that a tag added to a valid work item will get published in the next issue of TWiR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was mostly wondering as I am writing up docs for cargo and want to know if we should require testing notes. I will go with that we do need testing notes and can update the docs if they aren't required.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. How about making the recommendation to include testing notes/documentation or other instructions a "strong recommendation" (or some similar verbiage), since we're not blocking inclusion on having the notes (at least not at this point)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can change it to that but cargo might be one case where testing notes should be required regardless of TWiR requiring them

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍


<!-- RFC and FCP sections go here -->
If you are a feature implementer and would like your RFC to appear on the above list, add the new `call-for-testing`
label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature
need testing.

### [Approved RFCs](https://github.com/rust-lang/rfcs/commits/master)

Changes to Rust follow the Rust [RFC (request for comments) process](https://github.com/rust-lang/rfcs#rust-rfcs). These
are the RFCs that were approved for implementation this week:

* [RFC: Add target configuration](https://github.com/rust-lang/rfcs/pull/3239)

### Final Comment Period

Every week [the team](https://www.rust-lang.org/team.html) announces the
'final comment period' for RFCs and key PRs which are reaching a
decision. Express your opinions now.

#### [RFCs](https://github.com/rust-lang/rfcs/labels/final-comment-period)

* [disposition: merge] [Create a types team](https://github.com/rust-lang/rfcs/pull/3254)

#### [Tracking Issues & PRs](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3Afinal-comment-period+sort%3Aupdated-desc)

* [disposition: merge] [Neither require nor imply lifetime bounds on opaque type for well formedness](https://github.com/rust-lang/rust/pull/95474)
* [disposition: merge] [impl Read and Write for VecDeque\<u8\>](https://github.com/rust-lang/rust/pull/95632)
* [disposition: merge] [Tracking Issue for `int_roundings`](https://github.com/rust-lang/rust/issues/88581)

### [New and Updated RFCs](https://github.com/rust-lang/rfcs/pulls)

* [new] [RFC: Rust SemVer 2](https://github.com/rust-lang/rfcs/pull/3266)

## Upcoming Events

Expand Down