revise again

src/2024h2/Async--Drop.md

@@ -0,0 +1,68 @@
+# Stabilize trait for async streams
+
+| Metadata | |
+| --- | --- |
+| Owner(s) | eholk |
+| Teams | [Libs-API] |
+| Status | WIP |
+
+[eholk]: https://github.com/eholk
+[Libs-API]: https://www.rust-lang.org/governance/teams/library#team-libs-api
+
+## Motivation
+
+
+
+### The status quo
+
+*Elaborate in more detail about the problem you are trying to solve. This section is making the case for why this particular problem is worth prioritizing with project bandwidth. A strong status quo section will (a) identify the target audience and (b) give specifics about the problems they are facing today. Sometimes it may be useful to start sketching out how you think those problems will be addressed by your change, as well, though it's not necessary.*
+
+### The next few steps
+
+*Sketch out the specific things you are trying to achieve in 2024. This should be short and high-level -- we don't want to see the design!*
+
+### The "shiny future" we are working towards
+
+*If this goal is part of a larger plan that will extend beyond this goal period, sketch out the goal you are working towards. It may be worth adding some text about why these particular goals were chosen as the next logical step to focus on.*
+
+## Design axioms
+
+*Add your [design axioms][da] here. Design axioms clarify the constraints and tradeoffs you will use as you do your design work. These are most important for project goals where the route to the solution has significant ambiguity (e.g., designing a language feature or an API), as they communicate to your reader how you plan to approach the problem. If this goal is more aimed at implementation, then design axioms are less important. [Read more about design axioms][da].*
+
+[da]: ../about/design_axioms.md
+
+## Ownership and other resources
+
+**Owner:** *Identify a specific person or small group of people if possible, else the group that will provide the owner*
+
+*This section describes the resources that you the contributors are putting forward to address this goal. This includes people: you can list specific people or a number of people -- e.g., 2 experienced Rust engineers working 2 days/wk. Including details about experience level and background will help the reader to judge your ability to complete the work.*
+
+*You can also include other resources as relevant, such as hardware, domain names, or whatever else.*
+
+### Support needed from the project
+
+*Identify which teams you need support from -- ideally reference the "menu" of support those teams provide. Some common considerations:*
+
+* Will you be authoring RFCs? How many do you expect? Which team will be approving them?
+    * Will you need design meetings along the way? And on what cadence?
+* Will you be authoring code? If there is going to be a large number of PRs, or a very complex PR, it may be a good idea to talk to the compiler or other team about getting a dedicated reviewer.
+* Will you want to use "Rust project resources"...?
+    * Creating rust-lang repositories?
+    * Issuing rust-lang-hosted libraries on crates.io?
+    * Posting blog posts on the Rust blog? (The Inside Rust blog is always ok.)
+
+## Outputs and milestones
+
+### Outputs
+
+*Final outputs that will be produced*
+
+### Milestones
+
+*Milestones you will reach along the way*
+
+## Frequently asked questions
+
+### What do I do with this space?
+
+*This is a good place to elaborate on your reasoning above -- for example, why did you put the design axioms in the order that you did? It's also a good place to put the answers to any questions that come up during discussion. The expectation is that this FAQ section will grow as the goal is discussed and eventually should contain a complete summary of the points raised along the way.*

src/2024h2/Async.md

@@ -38,7 +38,15 @@ Despite the growth of async Rust, it continues to be significantly more difficul
 
 ### Our plan for 2024
 
-Author an evaluation. XXX expand on this
+Author an RFC that will lay out a vision for the Async Rust experience:
+
+* What works well and what challenges exist in the Status Quo of Async Rust
+* Long-term goals (e.g., over next 3-5 years) for async Rust
+    * Free of accidental complexity
+    * 
+* Problems we need to solve to achieve those goals along with possible solutions
+* 
+
 
 ### Looking further out
 

src/2024h2/arbitrary_self_types.md

@@ -0,0 +1,68 @@
+# Arbitrary self types
+
+| Metadata | |
+| --- | --- |
+| Owner(s) | [Adrian Taylor][] |
+| Teams | [Compiler], [Libs] |
+| Status | WIP |
+
+[Compiler]: https://www.rust-lang.org/governance/teams/compiler
+[Libs]: https://www.rust-lang.org/governance/teams/library
+[Alice Ryhl]: https://github.com/Darksonn/
+
+## Motivation
+
+The goal for 2024H2 is to stabilize support for Arbitrary Self Types as described in [RFC 3519][]. This will enable a number of use-cases, including C++ interop (as described in [RFC 3519][]) and the [ARC][] type from the Rust for Linux project.
+
+[RFC 3519]: https://github.com/rust-lang/rfcs/pull/3519
+[ARC]: https://rust-for-linux.com/arc-in-the-linux-kernel
+
+### The status quo
+
+The compiler permits self types for specific "smart pointers" (`Box`, `Rc`, etc) but it is not possible for users to define their own. There has been extensive discussion and design work culminating in the approval [RFC 3519][] with a specific proposal.
+
+### The next few steps
+
+This year the goal is to implement and stabilize the design from [RFC 3519][].
+
+### The "shiny future" we are working towards
+
+The ultimate goal is that users are able to define their own smart pointer types with equal capabilities to the builtin options in the standard library. Related and possible future work includes:
+
+* [Supporting unsizing](./rfl_arc_unsizing.md)
+* Ability to move out, as one can do with `Box`
+* Integration with matching (e.g., [deref patterns][])
+
+[deref patterns]: https://github.com/rust-lang/lang-team/blob/master/projects/deref-patterns.md
+
+## Design axioms
+
+None authored.
+
+## Ownership and other resources
+
+**Owner:** [Adrian Taylor][]
+
+[Adrian Taylor]: https://github.com/adetaylor
+
+### Support needed from the project
+
+* Reviews from the [compiler] and/or [libs] teams
+    * QUESTION: Should we assign a reviewer?
+* Lang team design is considered "done", but occasional design meetings or triage discussion may be required
+
+## Outputs and milestones
+
+### Outputs
+
+Stable version of the Arbitrary Self Types feature.
+
+### Milestones
+
+* Nightly implementation
+* Stabilization report
+* Stabilization PR
+
+## Frequently asked questions
+
+None.

src/2024h2/cross_cutting.md

@@ -0,0 +1 @@
+# Cross-cutting improvements

src/2024h2/rfl_arc_unsizing.md

@@ -14,7 +14,7 @@
 
 The goal for 2024H2 is to allow the [Rust for Linux's customized ARC type][arc] to use unsized types. The Linux kernel makes extensive use of intrusive linked lists due to their ability to separate *allocation* of a list entry from *insertion* of that entry into the list. While it is possible to safely model intrusive linked lists in Rust with `Pin`, it is complex and unergonomic.
 
-[arc]: XXX
+[arc]: https://rust-for-linux.com/arc-in-the-linux-kernel
 
 ### The status quo