Back in October 2023, I shared some thoughts about the state of the Vue core PR queue. 7 months on, I figured it might be worth re-running the analysis to see how things have changed.

My original post is at:

• The Vue core PR queue #9437

I'm not going to repeat everything I said there. If you aren't familiar with the previous discussion I suggest reading that first, as it covers some important topics (e.g. why this matters) that I'm not going to repeat here.

My original analysis used data from October 19, 2023. The new analysis is from May 19, 2024. As previously, I've ignored PRs opened by bots, those marked as drafts, and those opened in the current month.

Some headline figures:

• In October 2023, the queue contained 450 open PRs.
• In May 2024, that's down to 317.

That's undoubtedly a significant improvement - about 30% smaller. Clearly there's a lot of work gone into making that happen, so a big thank you from me to everyone involved.

The charts

As previously, I split the PRs into 3 groups: open, merged and closed. I then plotted M / (M + O), grouped by the month they were opened:

Merge rate comparison

To learn more about what exactly those charts are showing, see https://gist.github.com/skirtles-code/a402e5008a38d08cd3ae8020656ca752.

At first glance, this doesn't look great for Vue. But rather than comparing Vue to other repos, it might be more constructive to focus on how things have changed in the last 7 months.

This next chart combines the data from May and October into a single chart. The grey bars represent where things were in October and green shows the progress since then:

Vue merge rate progress

Maybe it's more useful to stack the bars the other way up, so here's what that looks like:

Vue merge rate progress

Some caution is required when interpreting the green portions of those bars. While they might represent real progress, such as the merging of PRs, it could equally indicate that a PR was closed because the author deleted their fork, even though the changes were perfectly good. There wasn't an easy way for me to indicate that on the charts. All it really indicates is how much closer we are to having no open PRs for that month.

I'd encourage you to come up with your own interpretation of all these charts before reading mine...

My main thoughts are:

• The handling of new PRs seems to have improved significantly around December 2023. Or, to put it another way, since 3.4.
• Some of the big gaps from the October charts have been filled. e.g. August 2022 and June to August 2023. But it seems that the merge rate generally stalls at around 70% and progress beyond that is very slow. Those last few PRs (roughly 10 per month) just get stuck.

Are the old PRs still mergeable?

Merge conflicts are a significant obstacle to reviewing and merging old PRs. How many of the open PRs have conflicts? The chart below attempts to help answer that question. It shows the number of open PRs for each month, with colours indicating how many have conflicts and how many don't:

Vue open PRs

As expected, the further back in time we go the more conflicts we see.

But arguably it's more interesting that there are PRs from 2021 and 2022 that don't have conflicts.

There are a few reasons for that. In some cases it's just because the changes are really small, so a conflict would only be introduced if a specific line changed. In other cases, it's because the original author has kept resolving the conflicts over the last couple of years to ensure that their PR is still mergeable. Kudos to baiwusanyu-c and edison1105 in particular.

I think it would be really helpful if PRs were automatically assigned a label to indicate whether they have a conflict. For more about that idea, see:

• Automatic label for merge conflicts #10817

Are the old PRs junk?

That's complicated.

If a PR is obviously junk then it's relatively easy to close it. I don't think there are many left like that.

The most difficult PRs to handle are ones that have merit but need lots more work reviewing and iterating before they can be merged. Those can suck up huge amounts of time for fixes that aren't necessarily important.

So are all the old PRs like that? Not really.

I recently read through all the open PRs, just to try to understand what's there. It took me about a week, and that was just to read through them, not to review them. The job of reviewing all of those properly is huge. But there are still plenty of small changes that can be reviewed relatively quickly.

I found quite a few that could just be closed. I reported some of those in #10770, most of which are now closed.

But there are quite a lot of other 'easy' ones. Take these, for example:

• refactor(runtime-core): use 'createTextVNode' replacement 'createVNode' for to improve the readability of the code #5630
• types(core): added getSSRProps type argument #5691
• fix(ssr): fix hydration for node with empty text node #7216
• types(effect): pass type argument to return type in effect #7664
• docs(sfc-playground): add pnpm usage to download template #7815
• refactor(server-renderer): slotScopeId scopeId uses optional argument syntax #7891
• refactor: replace typeof with type guard #8505
• refactor(runtime-core): prevent users from manually calling lifecycle hook function #8731
• refactor: replace Object.assign with extend #8988
• refactor: return early when children == null #9041
• feat(compiler-core): support Symbol in template #9069
• chore: improve readonly/reactive warning message #9095
• fix(runtime-core): incorrect callback parameters when reactive array ref passes to watch #9417
• refactor(compiler-sfc): defineOptions avoid redundant conditional judgments #9453
• dx(runtime-core): log the component object when warning about missing template/render function #10263

Some of these could be merged, some should just be closed, but either way it doesn't seem too difficult to reach a decision.

The current process/strategy

I'm not exactly sure what the current process/strategy is for trying to work through the old PRs. I can see some work from sodatea in recent weeks, in particular adding labels to old PRs. It also looks like Issue / PR Management is being updated.

It wasn't clear to me whether anyone is actually doing any reviewing though. I'm not trying to point fingers, people are busy and the work is entirely voluntary... but, in practice, is the current process actually working?

When I wrote my analysis in October, I felt that the main bottleneck was on Evan doing the merging. I think that was a fair assessment at the time, but I'm not sure whether that's still true. I could be totally off base here, but it seems that right now there's a problem further upstream with getting things reviewed. It is very hard to judge, though.

I also wonder how much value most of those labels really add. Does labelling a PR as p1, p2, p3, etc. actually make any difference? I mean, if a PR is already 12 months old, does it really matter whether it's p1 or p3? Likewise, does the ready for review label have any real impact? I get the theory, but is it working in practice?

I quite liked the easy for merge label. That seemed like a nice idea, but it seems to have fallen into disuse.

Suggestions for reviewers

Suggestion 1

One reason reviewing an old PR is difficult is that the original author is no longer interested in making updates. You could spend hours writing feedback, only for it to be ignored.

If that's putting you off doing reviews, I have a suggestion: just review PRs from people you know. baiwusanyu-c has 31 open PRs. edison1105 has 26, Alfred-Skyblue has 25. That's 82 PRs where you can be confident that the original author is still interested.

Is that unfair on everyone else, like a form of nepotism? Yes it is, but I think it's a pragmatic way to make some progress towards clearing the PR queue. I know it helps me to stay motivated when I'm reviewing a PR from a team member.

Suggestion 2

I know it's tempting just to review the new PRs and ignore the old ones. It's also tempting to skim through the list and only review PRs that sound interesting.

When I went through all the open PRs, I started at the end of the queue, with the open PRs from 2019. Some PRs I only looked at very briefly, but I forced myself to make notes about each PR. That ensured that I had understood roughly what it was about before moving on.

I found this quite an effective approach. By forcing myself to read through all the old PRs it allowed me to find lots of interesting PRs that I would never have looked at just based on their titles.

As I mentioned earlier, I think it would be beneficial if the PRs were automatically labelled to indicate whether they have merge conflicts. I think reviewing the oldest PRs first is a good (and fair) approach to reducing the size of the queue, but it would be more effective if we could filter the list to ignore PRs with conflicts.

Other ideas

Perhaps we need to take a slightly more aggressive approach towards closing old PRs?

There are 3 open PRs from 2019, 5 from 2020, and 26 from 2021. Perhaps some still have merit, but surely most of them are never going to be merged. If there are valuable ideas in those PRs, perhaps an issue should be opened instead so the PR can be closed?

Maybe PRs with merge conflicts should be closed? I think the automatic labelling could help with that. Closing the PRs has the potential to really annoy the original authors, so perhaps it could be done in stages: first posting a comment asking them to resolve the conflicts, then closing the PR if they aren't resolved within 2 weeks? I realise we may lose some valuable PRs to this strategy, but it might be worth it to reduce the size of the queue, especially given the difficulty in reviewing/merging PRs with conflicts.

Another idea, and I know this may sound nuts, but would it be helpful if those of us with old open PRs just closed them and opened new PRs to replace them? It seems the review process works well for new PRs, but struggles to work through the old PRs. So maybe it'd be easier just to 'bump' PRs by re-opening them?

A tangent

While compiling the comparison between October and May, I noticed some PRs had disappeared. They aren't just closed, they're gone altogether. They were all created by the same user, who seems to have had their account deleted. For reference, these are the 'vanished' PRs:

• replace switch with config in escapeHtml #1099
• refactor(shared): replace switch with config in escapeHtml #1101
• support static tbody tr td elements #1268
• test(reactivity): 100% reactivity coverage #1299
• use ReactiveFlags instead of __v_ properties #1313
• fix(compiler-dom): add tfoot element on bail stringification #1332
• fix(compiler-dom): add tfoot,caption,col element on bail stringification #1333
• chore(shared): remove useless remove function #1365
• perf(runtime-dom): Array.from and concat is more efficient than ... #1367
• test(vue): 100% vue packages coverage #1371
• test(shared): test coverage for looseEqual #1381
• chore(runtime-dom): insertBefore anchor null equals appendChild #1463
• fix(sfc-compiler): fix duplicated declarations of macros #6778
• fix(compiler-sfc): require <template> or <script> in SFC #6781
• fix(runtime-core): keep-alive exclude component in hmrDirtyComponents... #6809
• chore: better bit clear in keep-alive component #7079
• better shape-flags bit clear #7092
• types: support typecheck --isolatedModules flag is provided (vite-vue-ts-template by default) #8574
• fix(reactivity): check rawValue exists in target via set.add #8647 #8649
• fix(reactivity): onCleanup also needs to be cleaned #8655
• fix(reactivity): watchEffect should allow multiple onCleanup calls #8661
• chore: input[type='date'], the modifier number could converted to a timestamp #8687
• feat(keep-alive): allow custom caching strategy #8701
• refactor: refactor utils code #8703
• chore: acceptable color in dark mode for custom formatter #8704
• chore: add a time-consuming log for building #8720
• chore: update vitest coverage #8721
• fix(customElement): allow defineCustomElement add style with nonce for content security policies (CSP) #8728
• feat(compiler-core): export error message #8729

GitHub still shows their titles and merge status, but if I click on them, I get a 404. Perhaps they are still visible to those with higher permissions, I don't know. I found it interesting that PRs can be deleted like this.

They didn't significantly impact the charts, so I didn't attempt to correct for their disappearance.

I actually have the diffs for the 5 'open' PRs in an old data dump, so I may take a look at some point to see whether they're worth salvaging.

---

Thanks for reading.