Decision making in the WG

[SimonSapin]

• Should this working group have formal membership?
  • If so, how does one join?
• Should @rfcbot be used to run the FCP process and formally record consensus?
• Does @rust-lang/libs delegate any authority to the WG? To what extent?
• Should the output of the WG go through the RFC process at https://github.com/rust-lang/rfcs, to involve the wider Rust project and community?
• When and how should changes to the standard library land?
  • Should there be code experiments outside of the standard library first? On crates.io? CC Reimplement the most important structs and traits for testing #19

I’ve added this to @rust-lang/libs’s agenda for the 2019-05-15 meeting. Discussion or suggestions are welcome from anyone.

[gnzlbg]

Should this working group have formal membership?
If so, how does one join?

Usually one pings the facilitator, and they just add them to the repo, such that @rust-lang/wg-allocators pings all members. We should document this in the readme.

Does @rust-lang/libs delegate any authority to the WG? To what extent?

I think that the goal of the wg should be to produce RFCs that go through the process. PRs from the group to rust-lang/rust would need libs team review as usual. I don't think we need any special kind of status for the WG right now. EDIT: That is, I expect the libs team to check on what this group is doing regularly, and participate in it, as well as maybe "bless" RFC-drafts before they are submitted as RFCs, but IMO we should just follow the normal process after that, where each lib team member needs to sign on any important changes.

Should @rfcbot be used to run the FCP process and formally record consensus?

I think this is up to the people in the working group to decide. The tool is there, if we think we need it we should use it. It's unclear to me how useful it would be at this stage. If the repo contains RFC-drafts that we plan to submit, those would be send to the repo as PR, and the members can just review them and approve them, so we can also track consensus there (e.g. if everyone approves a PR to this repo, then it's good to go).

[TimDiekmann]

Should the output of the WG go through the RFC process at https://github.com/rust-lang/rfcs, to involve the wider Rust project and community?

Yes, I don't think this WG should have a special position. But we should not go through the whole RFC process. I think a FCP would be enough in the most cases.

Should @rfcbot be used to run the FCP process and formally record consensus?

If we decide not to go through the whole RFC process for small changes (e.g. Alloc - > AllocHandle), this is a suitable solution. Those changes should be tracked in the WGs repo, either by code (#19) or by some text files. I'd prefer the former. When an area has been finished (e.g. How we want Box<T, A> to be implemented) this will go through the FCP at rust-lang/rust.

How do we actually decide on this issue?

[SimonSapin]

Yes, I don't think this WG should have a special position. But we should not go through the whole RFC process.

I think these two sentences are strictly contradictory.

[TimDiekmann]

What I wanted to say is that it makes no sense for small changes to always start the complete RFC machine and instead combine several changes within the WG as pre-RFC. After this, we file this RFC to rust-lang/rust.

[SimonSapin]

Oh ok. Yes we can definitely “batch” changes into a smaller number of separate RFCs in https://github.com/rust-lang/rfcs.

[Ericson2314]

I would hope that WG can get "expedited" landing of unstable changes like the eRFC concept. Of course stabilization must and should require a full RFC.

[SimonSapin]

The libs team discussed at yersterday’s triage meeting… but didn’t have much to say.

Process-wise, it’s fine to make any change whenever to unstable APIs. Any stabilization should go through an RFC, as usual. Other than that, it’s up to the WG to self-organize however we want.

---

I think it can be useful to use this repository both for code with faster iteration time than the homu queue for rust-lang/rust, and for collaborating on draft RFCs.

I think https://rust-lang.github.io/rfcs/1398-kinds-of-allocators.html can serve as a de-factor eRFC for this WG, even though we didn’t use that term at the time. Note that an eRFC does not expedite anything, it is merely an agreement to start work in rust-lang/rust on a large unstable feature, without having the final design yet. (As opposed for example to not accepting at all a PR that starts implementing coroutines without https://rust-lang.github.io/rfcs/2033-experimental-coroutines.html.)

[TimDiekmann]

It has been about half a year since the workgroup was formed and not a single decision has been made since.
I think it has turned out who is active in the WG. I would suggest that we either use the FCP-bot or do it manually, but if that continues, we haven't made a decision in a year.

@ErichDonGubler It would be great to have a statement by you regarding this as you wanted to lead this WG.

[ErichDonGubler]

@TimDiekmann I admit that I've let this particular WG fall off my radar for a while. I've been keeping up with discussion, and haven't seen a need to moderate, but I agree with the sentiment that having somebody to shepherd tasks forward would be the most helpful at this point.

To that end, I'll commit to pushing tasks forward from this point. I'm going to take an hour or two to refresh myself on the contents of this issue, and reply here with more thoughts then. I'm probably going to need some help to do it correctly, but I'm interested in developing a summary of this WG's progress and the current design of allocators, including open questions.

Thoughts?

[ErichDonGubler]

Originally, I volunteered to be a facilitator for this working group. To lean heavily on @Manishearth's definition in his relevant blog post:

At a high level, the job of the facilitators is to:

• help foster empathy between participants
• help linearize complex discussions
• nudge towards cooperative behavior, away from adversarial behavior. Get people playing not to win, but to win-win.

By this definition, I feel @TimDiekmann's expectation to "lead" wasn't previously established. That's why I haven't taken an active role in pushing discussion forward until this point. I have been paying attention to tone and whether or not some clarification would have served to faciliate discussion in one issue or another, and until now I haven't felt that there have been any emotional or technical standstills that required my assistance.

That said, from what I see, this working group could benefit enormously from some renewed interest, and I feel that the most helpful thing I can do for the WG would be to encourage people to participate. I think that interest will naturally drive issues to completion. As a facilitator, I can do better in encouraging participants to fulfill commitments they make or to take certain actions that would drive an issue. So, let me rescind my previous statement here:

I'm going to take an hour or two to refresh myself on the contents of this issue, and reply here with more thoughts then. I'm probably going to need some help to do it correctly, but I'm interested in developing a summary of this WG's progress and the current design of allocators, including open questions.

...and try to express my intent better: I'm interested in developing a summary of this WG's progress and the current design of allocators, including open questions. My intent is to do so and then use that summary to encourage people to come and participate.

[ErichDonGubler]

To @TimDiekmann's point, it seems like the discussion here is getting stale, so I'll try to do my part as facilitator and summarize what I think is happening in this issue so far. Correct me if I'm wrong or misrepresent you, please! :) I'll use the @SimonSapin's OP content to structure the summary.

---

• Should this working group have formal membership?
  • If so, how does one join?

@gnzlbg stated that just talking to a facilitator (that's me) and getting added to Zulip is sufficient. I see this as pretty relaxed, I don't see a reason to keep this process more restrictive at this point. Does anyone else?

---

• Should @rfcbot be used to run the FCP process and formally record consensus?

[snip]

• Should the output of the WG go through the RFC process at https://github.com/rust-lang/rfcs, to involve the wider Rust project and community?

[snip]

• When and how should changes to the standard library land?

So, there's a distinction embedded in these points between:

• Using the FCP process to drive decisions and designs still internal to the WG

  • I believe RFCBot would be useful if we're going to have an FCP-like process internally -- it's familiar to the existing Rust internals community, and it's nice to have a tool to drive formal closure of issues. Unless somebody objects, I'll investigate integrating RFCBot into this repository.

  Just as a note: I'll do this because everybody else seems mostly interested in how to make allocators work, not administrative details. I don't view myself as having any particular authority here, just somebody who just wants to create the environment necessary for the WG to work happily. :) So I think I might as well!

• Opening FCPs via (e)RFC in Rust upstream to present what has achieved consensus in this WG for further feedback, refinement, and eventually merging

  • My feeling here is that our current design has enough open questions that we might not have much to present yet. However, once we DO have something (be it a working implementation or just an API), I'm of the opinion that feedback would only make what we deliver better.
  • @SimonSapin has indicated his opinion that the previously accepted allocators RFC can serve as what we know as an eRFC today for the WG's current design, which I know we're already tweaking and discussing. By the same token, why not use eRFCs when we have an updated design to present (viz., want wider experimentation in nightly) and full RFCs when we want to finalize a design?

---

• Does @rust-lang/libs delegate any authority to the WG? To what extent?

@gnzlbg is the only participant that has responded to this, indicating he thinks no.

What would this authority be used for, exactly? I don't think I understand this question.

---

[snip]

• Should there be code experiments outside of the standard library first? On crates.io? CC Reimplement the most important structs and traits for testing #19

The only argument I can see against this is if the design we want for allocators requires deep integration with Rust upstream. Otherwise, implementation and feedback loop could be significantly streamlined. Am I missing something here?

---

I didn't do a particularly good job of being neutral in this case, but...here's my first post trying to actively be a facilitator! :) Woot!

[gnzlbg]

What would this authority be used for, exactly? I don't think I understand this question.

I think this was resolved by @SimonSapin in this comment: #20 (comment)

[TimDiekmann]

How much effort is it to add the FCP bot? I propose to FCP #8 to rename Alloc to AllocRef.