8 ms·

Vuejs rejects close to 75% of outside contributions

90 points by gieksosz 6y ago

BugsJustFindMe 6y ago
Looking at the PR history for the vuejs repo, I can't say that I'm surprised. Holy hell, what a wasteland.
- gieksosz 6y ago
  It seems to happen more often for big JS projects like React and Vue. Julia projects do not seem to suffer from that.
- judge2020 6y ago
  Ya, here's some examples of spam: https://github.com/vuejs/vue/pull/11847/files https://github.com/vuejs/vue/pull/11847/files https://github.com/vuejs/vue/pull/11853/files https://github.com/vuejs/vue/pull/11853/files https://github.com/vuejs/vue/pull/11820/files https://github.com/vuejs/vue/pull/11820/files https://github.com/vuejs/vue/pull/11818/files https://github.com/vuejs/vue/pull/11818/files All within the last month. Maybe there's some tutorial for 'how to submit a PR on GitHub' that links to Vue.js and people are following that?
  - szundi 6y ago
    Thank you, I had the best laugh of the day. Also has a point.
  - AlphaWeaver 6y ago
    You’re exactly right re: tutorials. See the Hacktoberfest drama on HN from last October for more examples of this sort of thing.
    - null_deref 6y ago
      That's was my thought, but it seems like those PRs aren't from last October...
  - bitwize 6y ago
    That third one reminds me of the "covfefe" meme a while back (our Dear Leader at the time was also attempting to type the word "coverage").
  - TiccyRobby 6y ago
    Damn. They need to somehow discourage that. Do they blacklist those people?
  - scpedicini 6y ago
    It would be neat if they could set up automatic filters based on the file type/size/etc. So they could automatically disallow any pull request to the README file for example.
- acemarke 6y ago
  Yep. The OP submitted a similar thread earlier today about 50% of external React PRs being rejected, and I left a comment saying that it's a combo of the React codebase being complex and most external PRs being junk or irrelevant.
- deleted 6y ago
  [deleted]
zoobab 6y ago
As long as you can play Doom.
mlthoughts2018 6y ago
I think this is a good thing generally, Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world, largely due to uncompromising enforcement of the design opinions and aesthetics it asserts. As long as the maintainers are responsive to bug fixes and key feature requirements (since they aren’t accepting of outside contributors adding them), then this is fine, possibly even optimal in terms of quality. The trouble comes in if they both don’t allow many outside contributions and at the same time they pull the same unjustified complaint of a lot of OSS and say because they aren’t paid for their time, they will prioritize what interests them rather than what resolves painpoints or missing features users need. You definitely can’t have it both ways.
- bird_monster 6y ago
  > I think this is a good thing generally, Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world, largely due to uncompromising enforcement of the design opinions and aesthetics it asserts. Which is much easier to attain if you're comfortable with only a single person being allowed to write code. Personally, I wouldn't use Vue in any business-oriented application for this exact reason. The "bus factor", or as I would call it, "If and when Evan decides to stop caring about Vue", is enough to make Vue dead in the water as a legitimate FE library choice (to me).
  - that_guy_iain 6y ago
    The org has 49 people on it. And every project that has one people who leads it can surive without that person, it's called they fork the project.
    - bird_monster 6y ago
      https://github.com/vuejs/vue/graphs/contributors?from=2016-04-10&to=2021-01-09&type=a https://github.com/vuejs/vue/graphs/contributors?from=2016-0... Here you can find the code additions Github Insight. The org can have 49 people in it, but 48 of them are not writing code for Vue.js.
spartanatreyu 6y ago
This is for the old version of vue (v2), not the current vue (v3). This title should read: Vue accepts 70% of outside contributions on latest version and only 23% on old version.
- deleted 6y ago
  [deleted]
- ohitsdom 6y ago
  Vue 3 included a re-write in Typescript. The Vue team was very vocal in the benefits TS would bring, including making it easier for outsiders to contribute.
jdieiueejjene 6y ago
The best part about Vue is it isn’t sponsored by giant evil corporation like Facebook who have enabled violence and racism for the past 4 years. We as developers need to do better and support people like Evan out there. Eventually, we should also hold individual engineers who work at Facebook/similar accountable to a higher standard and reject their software even if it’s open source or wonderful (React).
- MaKey 6y ago
  There is no need to bring politics into software development wherever possible. I don't care who has written the code, code itself is apolitical.
  - ipsocannibal 6y ago
    "I don't care who has written the code, code itself is apolitical" When backdoors are added to your service framework, when dragnet data collection services copy every artifact of your digital existence in the name of "national security" or when algorithms have been trained to distinguish faces specificly of your race you will damn sure want to know who wrote that code and why. Its just naive to think tools exist outside of their intended function and political ends often determine those functions.
    - MaKey 6y ago
      I agree. I was aiming at the context of the parent comment. The employer of someone (e. g. Facebook) shouldn't have an effect on how their code is treated.
      - gnud 6y ago
        But when you use projects pushed by big companies, you are giving those companies word-of-mouth advertising, and when their projects become popular they get a pool of pre-trained engineers for free. So if you honestly feel that a company is pure evil, you really ought to avoid any open source project they publish. Not because the code is political, but because everything surrounding the code is.
deleted 6y ago
[deleted]
zinekeller 6y ago
I will talk about accepting outside contributions in a general sense (beyond JS and Julia comparisons). In my personal experience, the acceptance rates doesn't really matter and does not correlate to the quality of the code. On one hand, you have SQLite which really discourages direct code submissions due to the nature of the IP management of SQLite (they need to ensure that it is 100% in public domain), instead relying on bug reports instead. SQLite however is a very good product, something that I personally miss when I work on JS projects. On the other hand, I've seen projects (multiple, which I prefer not naming to prevent flame wars) with very high acceptance rates - the problem is that the coding style and availability of comments are inconsistent to the point that we have to forego using some libraries and writing our own despite those libraries will fit into the bill nicely. Edit: some have commented "this is what I've expected!", but there are some projects (obviously will be unnamed) that are not accepting contributions but the code consistency is less-than-ideal, and some projects with well-behaved outside contributors that have kept the quality despite having high acceptance rates (usually writing in relatively niche languages). Probably the area I'm working on (educational) isn't reflective on the wider community, which seems to associate higher rejection rates to quality.
- gieksosz 6y ago
  On top of that some repos, like Bazel for instance close all PRs and import them via a process which happens outside GitHub. Some repositories do not use GitHub organisations at all, other do it a lot - those factors make merge-chance.info analysis more difficult, but I still think it is interesting. I hope it might even help someone chose what project to contribute to.
  - zinekeller 6y ago
    I think that if you want to contribute, they should at least be upfront on the processes, or even the absence of it. Some do not accept at all, some do only accept on bugfixes, and some are happy to extend the project. The chance of merging of course is a decent barometer for contributors who wants to work on projects who are allegedly open to contributions, but I will not use it as a barometer of the quality of the code itself (or at least as a minor barometer - never as a major one).
thih9 6y ago
I wish the submitter added their comment or gave some context, if there is any. For me this is an arbitrary number for a random popular repository. Especially since the linked github project https://github.com/vuejs/vue https://github.com/vuejs/vue is not the latest version of vue (see: https://github.com/vuejs/vue-next https://github.com/vuejs/vue-next ).
- gieksosz 6y ago
  Author here. I am still exploring useful metrics for classifying open source projects. My initial intent was to find a way to judge if given project is a good use of time for a first time contributor, someone not affiliated with original authors.
  - detaro 6y ago
    > My initial intent was to find a way to judge if given project is a good use of time for a first time contributor, someone not affiliated with original authors. so what does this contextless number you submitted here tells us about that? Please be careful with spreading around stats like that without context.
    - gieksosz 6y ago
      Thanks for feedback. In principle it is a measure that says - this repo will handle your PR quickly, but the base chance of it getting merged is low. The result in this case is skewed by spam however. Until I find a way to filter the spam PRs from counting it will remain uneven for repos like this one.
      - detaro 6y ago
        That's exactly the problem. If you present a number but it's uneven for all kinds of reason it's a bad measure. And people will go around and unfairly point at projects being "bad for new contributors" with how you present it.
notretarded 6y ago
Ahhh the applying Torvalds approach to code reviews.
zhirzh 6y ago
not sure if there's a point to checking this stat this is interesting, though checkout vim. it has 0% acceptance: https://merge-chance.info/target?repo=vim/vim https://merge-chance.info/target?repo=vim/vim
- sdfhbdf 6y ago
  Yeah looking at the PRs they're improperly marked as closed instead of merged because the contributors seems to merge manually.
Xevi 6y ago
That's the old Vue 2 repository, which has been pretty inactive for a while due to the full rewrite of Vue. Vue 3 (70.62% acceptance): https://merge-chance.info/target?repo=vuejs/vue-next https://merge-chance.info/target?repo=vuejs/vue-next Svelte (57.23% acceptance): https://merge-chance.info/target?repo=sveltejs/svelte https://merge-chance.info/target?repo=sveltejs/svelte React (45.99% acceptance): https://merge-chance.info/target?repo=facebook/react https://merge-chance.info/target?repo=facebook/react Angular (1.63% acceptance): https://merge-chance.info/target?repo=angular/angular https://merge-chance.info/target?repo=angular/angular
- dancek 6y ago
  Side note: Angular tends to create new commits (keeping the author, changing the committer) instead of directly merging the PRs. The real acceptance rate seems to be high.
  - Xevi 6y ago
    Thanks for pointing that out. I was a bit surprised about the low acceptance rate they had.
captain_price7 6y ago
Maybe significantly more work, but can you try to filter out very small (or spam) PRs before these calculations? Maybe limit this analysis to PRs that edits source code (not just comment and docs). Or maybe include those, but only when "amount" of changes cross a certain threshold? (e.g. exclude PRs that fix just one typo)
- gieksosz 6y ago
  Thanks for feedback! I am in fact working on features to improve that. Spam filtering is one of them.
zX41ZdbW 6y ago
You can obtain this data for all existing repositories by one request in one second: https://gh-api.clickhouse.tech/play?user=play#U0VMRUNUCiAgICByZXBvX25hbWUsIAogICAgdW5pcShhY3Rvcl9sb2dpbiksIAogICAgdW5pcShudW1iZXIpLCAKICAgIHN1bShtZXJnZWQpLCAKICAgIHJvdW5kKHN1bShtZXJnZWQpIC8gdW5pcShudW1iZXIpICogMTAwKSBBUyBwZXJjZW50IApGUk9NIGdpdGh1Yl9ldmVudHMgCldIRVJFIGNyZWF0ZWRfYXQgPj0gdG9kYXkoKSAtIElOVEVSVkFMIDkwIERBWSAKICAgIEFORCBldmVudF90eXBlID0gJ1B1bGxSZXF1ZXN0RXZlbnQnIApHUk9VUCBCWSByZXBvX25hbWUgCk9SREVSIEJZIHVuaXEoYWN0b3JfbG9naW4pIERFU0M= https://gh-api.clickhouse.tech/play?user=play#U0VMRUNUCiAgIC...
- gieksosz 6y ago
  might be useful for some broader analysis.

90 points by gieksosz 6y ago

BugsJustFindMe 6y ago

Looking at the PR history for the vuejs repo, I can't say that I'm surprised. Holy hell, what a wasteland.

gieksosz 6y ago
It seems to happen more often for big JS projects like React and Vue. Julia projects do not seem to suffer from that.
judge2020 6y ago
Ya, here's some examples of spam: https://github.com/vuejs/vue/pull/11847/files https://github.com/vuejs/vue/pull/11847/files https://github.com/vuejs/vue/pull/11853/files https://github.com/vuejs/vue/pull/11853/files https://github.com/vuejs/vue/pull/11820/files https://github.com/vuejs/vue/pull/11820/files https://github.com/vuejs/vue/pull/11818/files https://github.com/vuejs/vue/pull/11818/files All within the last month. Maybe there's some tutorial for 'how to submit a PR on GitHub' that links to Vue.js and people are following that?
- szundi 6y ago
  Thank you, I had the best laugh of the day. Also has a point.
- AlphaWeaver 6y ago
  You’re exactly right re: tutorials. See the Hacktoberfest drama on HN from last October for more examples of this sort of thing.
  - null_deref 6y ago
    That's was my thought, but it seems like those PRs aren't from last October...
- bitwize 6y ago
  That third one reminds me of the "covfefe" meme a while back (our Dear Leader at the time was also attempting to type the word "coverage").
- TiccyRobby 6y ago
  Damn. They need to somehow discourage that. Do they blacklist those people?
- scpedicini 6y ago
  It would be neat if they could set up automatic filters based on the file type/size/etc. So they could automatically disallow any pull request to the README file for example.
acemarke 6y ago
Yep. The OP submitted a similar thread earlier today about 50% of external React PRs being rejected, and I left a comment saying that it's a combo of the React codebase being complex and most external PRs being junk or irrelevant.
deleted 6y ago
[deleted]

zoobab 6y ago

As long as you can play Doom.

mlthoughts2018 6y ago

I think this is a good thing generally, Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world, largely due to uncompromising enforcement of the design opinions and aesthetics it asserts. As long as the maintainers are responsive to bug fixes and key feature requirements (since they aren’t accepting of outside contributors adding them), then this is fine, possibly even optimal in terms of quality. The trouble comes in if they both don’t allow many outside contributions and at the same time they pull the same unjustified complaint of a lot of OSS and say because they aren’t paid for their time, they will prioritize what interests them rather than what resolves painpoints or missing features users need. You definitely can’t have it both ways.

bird_monster 6y ago
> I think this is a good thing generally, Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world, largely due to uncompromising enforcement of the design opinions and aesthetics it asserts. Which is much easier to attain if you're comfortable with only a single person being allowed to write code. Personally, I wouldn't use Vue in any business-oriented application for this exact reason. The "bus factor", or as I would call it, "If and when Evan decides to stop caring about Vue", is enough to make Vue dead in the water as a legitimate FE library choice (to me).
- that_guy_iain 6y ago
  The org has 49 people on it. And every project that has one people who leads it can surive without that person, it's called they fork the project.
  - bird_monster 6y ago
    https://github.com/vuejs/vue/graphs/contributors?from=2016-04-10&to=2021-01-09&type=a https://github.com/vuejs/vue/graphs/contributors?from=2016-0... Here you can find the code additions Github Insight. The org can have 49 people in it, but 48 of them are not writing code for Vue.js.

spartanatreyu 6y ago

This is for the old version of vue (v2), not the current vue (v3). This title should read: Vue accepts 70% of outside contributions on latest version and only 23% on old version.

deleted 6y ago
[deleted]
ohitsdom 6y ago
Vue 3 included a re-write in Typescript. The Vue team was very vocal in the benefits TS would bring, including making it easier for outsiders to contribute.

jdieiueejjene 6y ago

The best part about Vue is it isn’t sponsored by giant evil corporation like Facebook who have enabled violence and racism for the past 4 years. We as developers need to do better and support people like Evan out there. Eventually, we should also hold individual engineers who work at Facebook/similar accountable to a higher standard and reject their software even if it’s open source or wonderful (React).

MaKey 6y ago
There is no need to bring politics into software development wherever possible. I don't care who has written the code, code itself is apolitical.
- ipsocannibal 6y ago
  "I don't care who has written the code, code itself is apolitical" When backdoors are added to your service framework, when dragnet data collection services copy every artifact of your digital existence in the name of "national security" or when algorithms have been trained to distinguish faces specificly of your race you will damn sure want to know who wrote that code and why. Its just naive to think tools exist outside of their intended function and political ends often determine those functions.
  - MaKey 6y ago
    I agree. I was aiming at the context of the parent comment. The employer of someone (e. g. Facebook) shouldn't have an effect on how their code is treated.
    - gnud 6y ago
      But when you use projects pushed by big companies, you are giving those companies word-of-mouth advertising, and when their projects become popular they get a pool of pre-trained engineers for free. So if you honestly feel that a company is pure evil, you really ought to avoid any open source project they publish. Not because the code is political, but because everything surrounding the code is.

deleted 6y ago

[deleted]

zinekeller 6y ago

I will talk about accepting outside contributions in a general sense (beyond JS and Julia comparisons). In my personal experience, the acceptance rates doesn't really matter and does not correlate to the quality of the code. On one hand, you have SQLite which really discourages direct code submissions due to the nature of the IP management of SQLite (they need to ensure that it is 100% in public domain), instead relying on bug reports instead. SQLite however is a very good product, something that I personally miss when I work on JS projects. On the other hand, I've seen projects (multiple, which I prefer not naming to prevent flame wars) with very high acceptance rates - the problem is that the coding style and availability of comments are inconsistent to the point that we have to forego using some libraries and writing our own despite those libraries will fit into the bill nicely. Edit: some have commented "this is what I've expected!", but there are some projects (obviously will be unnamed) that are not accepting contributions but the code consistency is less-than-ideal, and some projects with well-behaved outside contributors that have kept the quality despite having high acceptance rates (usually writing in relatively niche languages). Probably the area I'm working on (educational) isn't reflective on the wider community, which seems to associate higher rejection rates to quality.

gieksosz 6y ago
On top of that some repos, like Bazel for instance close all PRs and import them via a process which happens outside GitHub. Some repositories do not use GitHub organisations at all, other do it a lot - those factors make merge-chance.info analysis more difficult, but I still think it is interesting. I hope it might even help someone chose what project to contribute to.
- zinekeller 6y ago
  I think that if you want to contribute, they should at least be upfront on the processes, or even the absence of it. Some do not accept at all, some do only accept on bugfixes, and some are happy to extend the project. The chance of merging of course is a decent barometer for contributors who wants to work on projects who are allegedly open to contributions, but I will not use it as a barometer of the quality of the code itself (or at least as a minor barometer - never as a major one).

thih9 6y ago

I wish the submitter added their comment or gave some context, if there is any. For me this is an arbitrary number for a random popular repository. Especially since the linked github project https://github.com/vuejs/vue https://github.com/vuejs/vue is not the latest version of vue (see: https://github.com/vuejs/vue-next https://github.com/vuejs/vue-next ).

gieksosz 6y ago
Author here. I am still exploring useful metrics for classifying open source projects. My initial intent was to find a way to judge if given project is a good use of time for a first time contributor, someone not affiliated with original authors.
- detaro 6y ago
  > My initial intent was to find a way to judge if given project is a good use of time for a first time contributor, someone not affiliated with original authors. so what does this contextless number you submitted here tells us about that? Please be careful with spreading around stats like that without context.
  - gieksosz 6y ago
    Thanks for feedback. In principle it is a measure that says - this repo will handle your PR quickly, but the base chance of it getting merged is low. The result in this case is skewed by spam however. Until I find a way to filter the spam PRs from counting it will remain uneven for repos like this one.
    - detaro 6y ago
      That's exactly the problem. If you present a number but it's uneven for all kinds of reason it's a bad measure. And people will go around and unfairly point at projects being "bad for new contributors" with how you present it.

notretarded 6y ago

Ahhh the applying Torvalds approach to code reviews.

zhirzh 6y ago

not sure if there's a point to checking this stat this is interesting, though checkout vim. it has 0% acceptance: https://merge-chance.info/target?repo=vim/vim https://merge-chance.info/target?repo=vim/vim

sdfhbdf 6y ago
Yeah looking at the PRs they're improperly marked as closed instead of merged because the contributors seems to merge manually.

Xevi 6y ago

That's the old Vue 2 repository, which has been pretty inactive for a while due to the full rewrite of Vue. Vue 3 (70.62% acceptance): https://merge-chance.info/target?repo=vuejs/vue-next https://merge-chance.info/target?repo=vuejs/vue-next Svelte (57.23% acceptance): https://merge-chance.info/target?repo=sveltejs/svelte https://merge-chance.info/target?repo=sveltejs/svelte React (45.99% acceptance): https://merge-chance.info/target?repo=facebook/react https://merge-chance.info/target?repo=facebook/react Angular (1.63% acceptance): https://merge-chance.info/target?repo=angular/angular https://merge-chance.info/target?repo=angular/angular

dancek 6y ago
Side note: Angular tends to create new commits (keeping the author, changing the committer) instead of directly merging the PRs. The real acceptance rate seems to be high.
- Xevi 6y ago
  Thanks for pointing that out. I was a bit surprised about the low acceptance rate they had.

captain_price7 6y ago

Maybe significantly more work, but can you try to filter out very small (or spam) PRs before these calculations? Maybe limit this analysis to PRs that edits source code (not just comment and docs). Or maybe include those, but only when "amount" of changes cross a certain threshold? (e.g. exclude PRs that fix just one typo)

gieksosz 6y ago
Thanks for feedback! I am in fact working on features to improve that. Spam filtering is one of them.

zX41ZdbW 6y ago

You can obtain this data for all existing repositories by one request in one second: https://gh-api.clickhouse.tech/play?user=play#U0VMRUNUCiAgICByZXBvX25hbWUsIAogICAgdW5pcShhY3Rvcl9sb2dpbiksIAogICAgdW5pcShudW1iZXIpLCAKICAgIHN1bShtZXJnZWQpLCAKICAgIHJvdW5kKHN1bShtZXJnZWQpIC8gdW5pcShudW1iZXIpICogMTAwKSBBUyBwZXJjZW50IApGUk9NIGdpdGh1Yl9ldmVudHMgCldIRVJFIGNyZWF0ZWRfYXQgPj0gdG9kYXkoKSAtIElOVEVSVkFMIDkwIERBWSAKICAgIEFORCBldmVudF90eXBlID0gJ1B1bGxSZXF1ZXN0RXZlbnQnIApHUk9VUCBCWSByZXBvX25hbWUgCk9SREVSIEJZIHVuaXEoYWN0b3JfbG9naW4pIERFU0M= https://gh-api.clickhouse.tech/play?user=play#U0VMRUNUCiAgIC...

gieksosz 6y ago
might be useful for some broader analysis.