Improving the RFC workflow process

[Niryo]

Improving the RFC workflow process

[brillout]

What @Niryo says resonates with me.

I'm seeing a lot of open issues that are spam-ish but not rejected.

This makes me less confident to contribute. I'd rather be rejected than receiving no signal at all.

The React team is super busy and not reacting to issues is (obviously) a legitimate thing to do. But not rejecting does make me relunctant to share ideas I have.

Maybe an automated answer like "Hi, thanks for openeing an issue/PR. We couldn't understand or see the value of what you are proposing. Feel free to elaborate your point. Note that we are super busy and, even though we'd love to, we may not find the time to answer you." could help here.

[gaearon]

All right, I went through almost all open proposals, and either closed them or updated with the current thinking. Let's see the feedback. If people get frustrated that reviews weren't deep enough then maybe we can rethink the approach again.

I'll also be updating the RFC process description in README tomorrow to be closer to how it really is.

[Niryo]

@bvaughn , I have read your comment in the other thread, I decided to open the issue in order to give the chance to other people to suggest improvements to the process. you don't have to repeat your comment:) I will close this issue if I'll see that no one has anything to add to it...

[bvaughn]

Thanks for opening this as a new issue rather than on another RFC, @Niryo. 👍

[gaearon]

I just got a -1 emoji from one of the core team

Just to clarify, the person who did the –1 is not working full time on the React team, but is an external contributor with a commit access who's been helping triage issues. I assume in this case they expressed frustration with a "bump" type of comment since they usually only create noise in notifications. (If there was an update, it would be on the issue.) But what you said is totally fair that we're not setting the right expectations. I can see how that –1 might have seemed passive-aggressive, and I'm sorry for that.

I'd suggest there be more updates in the RFCs, or a comment to say something like "we are not looking into this at the moment" would be helpful to know whether it's months away or years.

I think the unspoken assumption from our side is that if we're not commenting on a proposal, we indeed are not looking into this at the moment. If we need to specify this explicitly, we'd have to comment on almost every RFC with this comment. But even if we do, what is the expectation of the timeframe for when it expires. Do we need to come back every half a year and write this again if the status has not changed? I'm not sure what's best here.

[gaearon]

Hmm. I'm actually not sure. Let's say I closed #11. But #11 (comment) is the most information someone can find about this problem space. Now that information is no longer easy to see because it's buried in a closed issue. And there is no one place to discuss the problem since the RFC is about a particular (flawed) solution. So I'm a bit torn about closing. But for now I'll keep closing and add context where I can. And in the future we can link to closed RFCs to provide more context.

[gaearon]

I wonder though, why is a PR works better than an issue for you?

The main reason is that RFC have a particular format. From what I see, people filing issues usually ignore that format so they end up not specific enough. Making a PR has a slightly higher barrier but that’s good because it encourages more thoroughly written RFCs.

Disabling issues is a great idea IMO, it will force people (like me) to read the README

For now I just closed them and changed the template to be explicit that the RFC themselves need to be PRs. Unfortunately disabling the issues erases all their content so we have to keep them enabled at least until people migrate their RFCs to PRs.

[Scott-HangarA]

I have also been running into this in a RFC proposal to add unmount transitions to Suspense. It was commented on by the core team, and discussed heavily, then abandoned for over a year with no insights into what is going on with it. Now I don't know what to expect from this. I'm not asking for a schedule, or even for them to do it, I just want to know what's even happening.

[gaearon]

I don't think we've set the right expectations about how the RFCs are used in practice. That's definitely an issue.

It's not entirely correct that we ignore the RFCs. We do reference them and read through the existing discussions and proposals when we start work in a related area. For example, we read the proposal and discussion in #32, which is an area we're working on: #32 (comment). Another example of a successful RFC is #118, which we're working on in facebook/react#20890 and which will likely influence the next iteration of our internal architecture. Note how in this case, it took over a year for us to get back to it, but it was a very valuable contribution nevertheless.

You can be assured that when we get to some other question (like animating Suspense), we'll get familiar with the related RFCs, as we've done in the above examples. However, usually these types of features have much deeper implications. E.g. we don't look at animating Suspense as an isolated feature. Rather, we see it as a part of a much deeper integration of Animations in React. So we wouldn't want to add a solution for one isolated case. Instead, we will look at the whole space holistically when we're ready to get to it. So the scope of the RFC doesn’t match the scope at which we want to tackle this problem. Since that’s already clear, we could maybe close the RFC. However, it's hard to explain why close it succinctly without providing years' worth of context. Closing without a good justification and a fair review also feels wrong. But each feature needs to work together with each other feature, so a proper explanation with an alternative strategy could take weeks to write. That's not really sustainable. At least, if the RFC stays open, the community has a chance to discuss it. By the time we get to this problem space, we have more research to read, and more opinions to consider. So from that point of view, keeping RFCs open is preferable. However, it seems like we should change the process so that we don't set the expectation of immediate (or even short term) reviews.

I'd say in most cases the de facto purpose of the RFCs here is twofold. For our RFCs, it's a way to announce intent and get feedback on the design. And for community RFCs, it's to give community a place to discuss possible ideas and to research them in the open, so that by the time we get to the space, we can be more informed by this research. However, it's uncommon that we would use the API design proposals directly.

[Scott-HangarA]

@gaearon Excellent reply and explanation of what the process is. I was unaware of a lot of what you are saying here, which is probably somewhat my fault based on flawed assumptions. I'd just add that, from a software development standpoint, sometimes I am asked to research the feasibility of a feature and this cycle is a bit of a barrier. Going back to the animate Suspense example, I am left with basically "it's something that's suggested, it might be possible soon, or later, or maybe not at all - there are workarounds but none are suggested by the react team or guaranteed to be stable". Which is a kind of unsavory position to be in. Depending on whether this will be addressed, it may be worth making our own implementation of it, or not. So that is what I am struggling with. I asked in the RFC what the intent was, and from that I just got a -1 emoji from one of the core team. Does that mean I shouldn't ask? Or that it's not being looked at anymore? I'd suggest there be more updates in the RFCs, or a comment to say something like "we are not looking into this at the moment" would be helpful to know whether it's months away or years.

[gaearon]

Another thing that's relevant is that for many RFCs, we don't have a stance ... yet. Because there aren't enough constraints yet. E.g. the thinking on Animations has changed several times. We have enough constraints now that we think the suggested approach isn't the one we'd prefer. But we didn't necessarily know that a year ago. Maybe we can be more explicit about this, e.g. "we don't feel like we know enough about this problem space yet to consider this idea, but we'd like to see more discussion on it". What do you think?

[Scott-HangarA]

@gaearon Yes that kind of comment would be incredibly helpful, I certainly don't expect a schedule for every RFC. I'd be a lot more eager to contribute to discussion if I know it's helpful and wanted. Maybe once a RFC thread gets "stale" it is flagged for review, then a comment made for either "this is an ongoing discussion and we want more input" or "we've reached agreement on this topic, but it's not currently part of our release schedule until further notice". Then once the team decides to look through all the RFCs related to a topic, they can mark them as "in progress" in some way. Maybe it'd even be possible to automate the message when it goes stale to say what you said here, that until one of the team updates the RFC, it's just a discussion and not an action item. That would just set people's expectations and people like me would realize it's annoying to keep bumping it.

[gaearon]

OK. I'll try to reply to as many as I can, but please keep in mind it's pretty tricky sometimes. Here is an example: #11 (comment)

[happycollision]

Now that information is no longer easy to see because it's buried in a closed issue

Could labels be a solution for this problem? Instead of closing, label as “dismissed” or something?

[gaearon]

I've submitted a "meta RFC" to clarify the RFC process: #200. Would love to hear your feedback!

[gaearon]

I'm seeing a lot of open issues that are spam-ish but not rejected.

Note that RFCs are submitted as pull requests, not issues. I don't think anyone from the team reads issues on this repository. Maybe we should disable them.

[brillout]

👍 Neat. This increases my motivation to write a little RFC I had in mind.

[sag1v]

I'm seeing a lot of open issues that are spam-ish but not rejected.

Note that RFCs are submitted as pull requests, not issues. I don't think anyone from the team reads issues on this repository. Maybe we should disable them.

@gaearon I'm one of them spammers who wrote an issue instead of a PR (Sorry!), for some reason i thought this is the way to discuss about ideas here. I know better now :)

I wonder though, why is a PR works better than an issue for you?

EDIT
Disabling issues is a great idea IMO, it will force people (like me) to read the README 😸