Update CFT, RFC and FCP sections for TWiR-443 #3260
Conversation
| * [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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
| * [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) | ||
| * [RFC: Packages as (optional) namespaces](https://github.com/rust-lang/rfcs/pull/3243) |
There was a problem hiding this comment.
Should testing notes always be included in this section? Giving only the RFC without how to test the changes might be confusing
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
I can change it to that but cargo might be one case where testing notes should be required regardless of TWiR requiring them
Add notes about pre-stabilization to contributor unstable docs This PR is meant to add more direction for contributors on the path to stabilization for unstable features. It adds a section titled `Pre-Stabilization` to the unstable contributor docs. The idea for this [came out of the discussion](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/workspace.20inheritance.20stabilization/near/281856280) about when and how to stabilize workspace inheritance. The notes that are being added were derived from the above comment as well as the [the adding of the `Call for Testing`](rust-lang/this-week-in-rust#3236) section to TWiR. [This comment](rust-lang/this-week-in-rust#3260 (comment)) gives more information as well. As for the requirement of testing notes, [there is still discussion about if they are needed](rust-lang/this-week-in-rust#3260 (comment)). While what was added is not comprehensive it is meant as a guide for what to do as each feature has different requirements for stabilization r? `@epage`
This is a continuation of the series that's been in past editions of This Week in Rust. Episode 2 was linked here: https://github.com/rust-lang/this-week-in-rust/blob/c88b2d13c7f5dd1d62942df3db15806aa9c3f0a6/content/2022-02-23-this-week-in-rust.md
… on CFT list for their RFC.
No description provided.