Should we adopt a lightweight RFC process?

[fitzgen]

Folks working in one corner of our ecosystem are finding that they are occasionally faced with choices that will affect many other parts of the ecosystem. They'd like to solicit feedback and opinions on the choices and then come to consensus with the larger group.

A lightweight RFC process is a potential solution for this. We could create an RFCs repo in this organization. We would also need to figure out the details of how our lightweight RFC process would work.

Thoughts?

+cc @rustwasm/core

[ashleygwilliams]

i would definitely like to see this happen. particularly because wasm-pack is an integrated tool and it would often be useful to get broader feedback on large decisions that affect not just the wasm-pack workflow but touch multiple different areas- e.g. npm dependency expression

[sendilkumarn]

I too agree with this, having something like this will help to get a broader feedback ofcourse

[Pauan]

I completely agree. It really doesn't need to be heavy-weight at all.

It mostly just needs to be a place where more "serious" ideas can be posted and discussed, with the expectation that more thought will go into them (pros, cons, alternatives, etc.), and that people will read and discuss them (issues sometimes get overlooked).

[mgattozzi]

I'm okay with this. It would also let us solicit feedback from others in the ecosystem who are not engaged with the working group direcely

[fitzgen]

I talked with @aturon about this over coffee yesterday, to leverage his experience with the wider Rust RFC process, and pick his brain about what he thought would apply well for us.

Here are my notes:

Lightweight RFCs

• what is important about the “RFC process”

  • decisions that have broad impact, need place for stakeholders to provide
    feedback
    • need to have single place to watch for all such things
  • set expectations around how long decisions are litigated
    • goal is to balance moving quickly and getting things done vs “you had to
      be in the room at the time or else you didn't get any say”
  • beaurocracy required is proportional to number of stakeholders

• tactical pieces

  • clear about setting expectations of whatever process
  • timeframe for making decisions
  • level of consensus in thread
  • who ultimately makes call, and how is that call communicated
  • labels in RFC repo per team

• rfcbot?

  • @aturon will look into how hard it is to set up

• FCP

  • helps enforce no new rationale

• RFC template

  • the rust tremplate has been steadily growing over time, but ours can
    probably be simplified
  • core bits are:
    • summary
    • motivation
    • design
    • exploration of design space, drawbacks, alternatives, rationale, etc
      • this is the most important, and also hardest

• how to decide what needs an RFC?

  • does this affect more than only users of this tool? a significant portion of
    users using this tool?
  • rule of thumb: if somebody missed this PR, who was otherwise trying to stay
    on top of things, how likely would it be that they would become upset?

[fitzgen]

Given that everyone who has left feedback on the idea is a +1, I will:

• create an RFCs repo in this organization
• draft up RFC number 1 which will lay out the rules, expectations, time frames, etc for our lightweight RFCs. We can debate the details and finer points in that PR thread :)

[xtuc]

May I ask to be invited to the org? Otherwise the bundle integration team won't be represented.

and @sendilkumarn too

[fitzgen]

@xtuc invite sent! @sendilkumarn is already a member of the org :)

[xtuc]

@fitzgen perfect! thanks.

Would it make sense to create a bundler team? So we can be pinged for specific questions. Also we could do it for every team.

[fitzgen]

RFC for RFC process is open: rustwasm/rfcs#1

Closing this issue, let's move discussion over there.