Feedback about the new RFC process

[Patrick Brosset]

Hi,

We've been using the new RFC process [1] for a while now, and I thought it
was time to ask the people involved what they thought about it.

- What works?
- What doesn't work?
- Should we improve? Can we improve?
- Should we drop it or continue using it?

My 2 cents from looking at it from outside:
It looks to me like it's working really well. When I look at the closed
issues, especially the accepted ones [2], I feel like this is great. I love
the fact that this is now a well established group decision making process,
and that we have a record of our technical decisions.

I'd like to also take this opportunity to warmly thank Julian for leading
the charge here. Thanks Julian!
And thank you all who have participated by either posting new RFCs, or
contributed to the discussions on them.

Patrick

[1] https://github.com/devtools-html/rfcs
[2]
https://github.com/devtools-html/rfcs/issues?q=is%3Aissue+is%3Aclosed+label%3Aaccepted

[J. Ryan Stinnett]

On Thu, Feb 1, 2018 at 10:36 PM, Patrick Brosset <pbro...@mozilla.com>
wrote:

> - What works?
>

Overall, I think the process works quite nicely. The RFC issue is a nice
way to collect comments and reactions. Since we have a defined process that
causes a decision to be taken, you know that something will happen, unlike
the pre-RFC world of sprawling mail threads that never reach a conclusion.

> - What doesn't work?
>

Nothing much to mention here. We've made small tweaks along the way, and I
assume we'll continue to do so if problems come up.

> - Should we improve? Can we improve?
>

Maybe a bot should announce new RFCs to Slack, IRC, mailing list, wherever?
Or people can watch the repo. It feels a bit silly to manually announce new
RFCs ad-hoc when a bot could do it.

I have a future RFC in mind that is a more complex proposal for which I'd
like to attach a design document (in markdown) for review. How should this
work with the DevTools process? In the Rust world, each RFC is a pull
request with an *.md file with a `rendered` link to view it easily in the
PR. The DevTools RFC repo doesn't actually store any files (since we chose
to keep things simple and just use issues directly). Should I create an RFC
issue with a link to a gist? Something else? (Should I make a meta-RFC
about how to make such an RFC...?) :)

> - Should we drop it or continue using it?
>

Keep it up, seems great to me.

> I'd like to also take this opportunity to warmly thank Julian for leading
> the charge here. Thanks Julian!
>

Yes, thanks Julian! It's critical to have a step that drives the process
forward each week, or else things would get stuck in an undetermined state.
Great work!

- Ryan

[Greg Tatum]

It's working really well in my opinion. I think pre-RFC it was really not
obvious how to propose a change and get consensus. I think we're
self-correcting along the way for what's working with the process and
what's not. I do like the formalized process of short weekly meetings to
drive actions on the comments, plus the way that stakeholders are following
through with filing bugs and doing the work once a decision has been
reached.

And yes thanks Julian! 👍



On Thu, Feb 1, 2018 at 10:02 PM, J. Ryan Stinnett <jry...@mozilla.com>
wrote:

[Julian Descottes]

Thanks for the feedback!

I also think it's been working nicely. RFCs are regularly created, without
forcing anyone to do so (thanks!).

As Greg said we are adjusting along the way. We are still figuring out the
role of reviewers, moving towards
facilitating discussions rather than taking decisions, and I think that's
fine. The review meeting might feel a
bit redundant, but it's great to have a regular checkpoint.

I agree with jryans, we definitely need to automate the email notification
:)

Regarding improvements/shortcomings, RFC discussions are not connected to
our backlog & priorities.
I want to keep an eye on this, make sure the two processes are not in
competition but complement each other.
We didn't have RFCs big enough to be queued in the backlog (most have been
heavier on discussion than
implementation). But when it happens, we'll need to make sure we transition
RFCs to backlog items correctly and
give them decent visibility.

| I have a future RFC in mind that is a more complex proposal [...] Should

I create an RFC issue with a link to a gist? Something else?

For more complex RFCs, start with a link to the design document (gist or
other) in the issue.
Once we reach an agreement on this particular RFC, let's figure out how to
document the decision efficiently.
e.g. if it is about code architecture, maybe landing documentation in m-c,
published at http://docs.firefox-dev.tools/ ?

[Brian Grinstead]

> On Feb 1, 2018, at 8:02 PM, J. Ryan Stinnett <jry...@mozilla.com> wrote:
>
> I have a future RFC in mind that is a more complex proposal for which I'd like to attach a design document (in markdown) for review. How should this work with the DevTools process? In the Rust world, each RFC is a pull request with an *.md file with a `rendered` link to view it easily in the PR. The DevTools RFC repo doesn't actually store any files (since we chose to keep things simple and just use issues directly). Should I create an RFC issue with a link to a gist? Something else? (Should I make a meta-RFC about how to make such an RFC...?) :)

We’ve been using a new design review process for doing more complex proposals like XBL replacement or migrating the preference UI to Fluent: https://mozilla.github.io/firefox-browser-architecture/text/0006-architecture-review-process.html. Depending on what you are planning to propose is it may be a good fit, and would result in an artifact that could be linked to from an RFC (for example: https://mozilla.github.io/firefox-browser-architecture/text/0007-xbl-design-review-packet.html). I’d be happy to discuss in more detail if you think it may work for this.

Brian