Improving the RFC workflow process #182
Comments
|
Thanks for opening this as a new issue rather than on another RFC, @Niryo. 👍 |
|
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. |
|
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. |
|
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. |
|
@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. |
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 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. |
|
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? |
|
@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. |
|
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) |
|
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. |
|
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. |
Could labels be a solution for this problem? Instead of closing, label as “dismissed” or something? |
|
I've submitted a "meta RFC" to clarify the RFC process: #200. Would love to hear your feedback! |
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. |
|
👍 Neat. This increases my motivation to write a little RFC I had in mind. |
@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 |
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.
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. |
I have started a discussion about the RFC process in one of the RFC threads, where it was not the appropriate place to discuss about it, so I move the discussion to here:
I think that we need to improve the process of handling RFC's. It looks like many RFC are becoming stale for years, most of them without even receiving any comment from the core team. The problem is clear- the core team is very small, the RFC's are very long and sometimes complicated to dive deep into. But I think there is still some room for improvements.
The first thing that comes up to my mind is to not be afraid of closing PR's: In my original comment I was referring to a very simple RFC (simple by terms of getting to a concrete decision) that was left stale for years. I am sure that we could have close this PR ages ago with a concrete action item (merge/dismiss).
My hunch is that lot's of PR become stale because merging sounds too obligatory and it's a hard decision to take. maybe we should add more steps, like stages, and promote RFC in greater stage so they will receive more attention from the community?
Bottom line is that I took the time and went over all of the merged PR's, and all of them were PR's of the core team itself. In 3 years not even a single PR from the community had been merged. So we really need to rethink the process (dismissing the process completely is a very legit decision in my opinion, if it doesn't prove to be working)
The text was updated successfully, but these errors were encountered: