Vuejs rejects close to 75% of outside contributions | Hacker News Reader

Vuejs rejects close to 75% of outside contributions

merge-chance.info

90 pointsgieksosz86 comments

Open articleView on HN

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

Svelte (57.23% acceptance): https://merge-chance.info/target?repo=sveltejs/svelte

React (45.99% acceptance): https://merge-chance.info/target?repo=facebook/react

Angular (1.63% acceptance): https://merge-chance.info/target?repo=angular/angular

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.

Thanks for pointing that out. I was a bit surprised about the low acceptance rate they had.

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.

You say acceptance rate doesn't correlate with code quality and then you give 2 data points where it does correlate in the expected way.

Added remarks. Probably the area I'm working on (educational) isn't reflective on the wider community, which seems to associate higher rejection rates to quality.

He's playing the long con.

I'm confused. My intuition is that the lower the acceptance rate, the higher the code quality would be. It demonstrates high standards.

Added remarks. Probably the area I'm working on (educational) isn't reflective on the wider community, which seems to associate higher rejection rates to quality.

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.

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).

This might be on GitHub more than maintainers, as there is no option to disable the pull requests feature right now (or to replace it with a link to what you actually use).

Why can't you use sqlite in js projects?

GP misses the quality of engineering that goes into sqlite when dealing with JS projects.

You can only use it with node I believe?

At least I would prefer to use sqlite over indexeddb, but haven't found a way yet.

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.

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.

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

Ya, here's some examples of spam:

https://github.com/vuejs/vue/pull/11847/files

https://github.com/vuejs/vue/pull/11853/files

https://github.com/vuejs/vue/pull/11820/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?

You’re exactly right re: tutorials. See the Hacktoberfest drama on HN from last October for more examples of this sort of thing.

That's was my thought, but it seems like those PRs aren't from last October...

Thank you, I had the best laugh of the day. Also has a point.

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.

Damn. They need to somehow discourage that. Do they blacklist those people?

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").

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.

It seems to happen more often for big JS projects like React and Vue. Julia projects do not seem to suffer from that.

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 is not the latest version of vue (see: https://github.com/vuejs/vue-next ).

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.

> 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.

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.

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.

Spam filtering is at least something I should be able to tackle in a somewhat reliable way. I am worried about telling outsiders from insiders, there are many ways projects go about organizing their contributors! Some use GitHub organizations and give contributors membership (easy to tell apart) some others invite to collaborate via giving access rights (also easy) but some others do neither of those things.

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)

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

You can obtain this data for all existing repositories by one request in one second:

https://gh-api.clickhouse.tech/play?user=play#U0VMRUNUCiAgIC...

might be useful for some broader analysis.

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).

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.

"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.

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.

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.

This. I wholeheartedly agree.

Which is why I disagree with Vue (and others) putting gigantic BLM banners on their sites.

Even if the cause is just, by mixing in politics, you create less of a common ground for those working on and using the code, thus creating rifts where there need not be any. Everything becomes "us" and "them".

Yeah there is a fine between espousing and radically shoving down someones throat a political point of view. The former is commendable the later is often divisive.

We may all agree, but that doesn't change the fact that it increasingly isn't nowdays.

With corps controlling main dev portals it will stay with us unless we have decentralized platform.

Everything is political.

> code itself is apolitical

I suggest you read Larry Lessig's Code 2.0 book.

I do not believe "read a 426-page book" should be considered a reasonable response here. At best this response is short-sighted.

You could at least post a link or say why this is a good book to read. While we are suggesting books I think "The Making of the Atomic Bomb" is a great work highlighting the political motives behind the making of the 20th centuries most important "tool".

The book is pretty much a thesis on why code is law, and therefore very political.

I can't put police at your door, whatever code I write.

You can literally disallow speech, by restricting what can be said. Or remove your ability to speak to people by shadow-banning you.

Everything is political. Everything is affected by, and affects, the political decisions we, the people, make. The last few years have been instructive in what happens if we ignore fascism and allow ourselves to relax when it comes to anti-fascist vigilance.

I'm going to be somewhat blunt in response, but I hope it's not seen as an attack. The phrase 'everything is political' is not a statement of truth, but rather a statement of demand: 'make everything political'. That is a tool to turn up the temperature of a given topic dramatically, not to encourage thoughtful change.

No, they got it right the first time. "Everything is political" is a reminder that we do not exist in a cultural vacuum. More pointedly, the simple act of existing in a space as a minority invites what you'd call "politics".

If your existence has never felt "political" to you, cherish that. I've been on the receiving end of many slurs and the occasional attempted assault, and I've watched politicians and pundits debate on cable TV whether I deserve to have the same rights afforded anyone else. I didn't choose to exist "politically", but I sure do notice when folks don't speak up against challenges to my existence because they view it as "politics" and therefore not worth their attention.

Politics happens any time you've got at least three people deciding over what to do with a given resource. If anyone is wondering why three people? Three people is the minimum number for a coalition to form.

On the contrary, the only people making a demand are developers who insist that their work does, or should, exist in a vacuum, outside of and independent of what is going on in the world, i.e. politics.

Reality, however, is there, whether we would like it to be there or not.

Look, I get it: sometimes you just want to put your head down and focus on technical details, and let someone else worry about the context. But keeping your head buried in the sand all the time isn't the answer.

Reality is also a lot larger and more complicated than the simplistic context a small slice of it is placed in, with everyone demanding their particular context is _the_ important one. We dumb down our reality all the time in order to fit it to our agenda, selectively picking and choosing the bits we like, and what else can we do in a world with over 7 billion conscious minds?

My worry about your line of thinking, and the everything is political one, is that it feels a bit like eradicating diversity of thought and experience. To relate it to the start of this thread, plenty of the world outside the US will have so much of their own shit to deal with than the politics that are _important to you_ are not at all important to them.

For anyone to suggest or demand or require otherwise would seem to be quite imperialistic to me.

> But keeping your head buried in the sand all the time isn't the answer.

It isn't, but I can't see a benefit of dragging unrelated politics into software development, even though the topics might be important.

Developing software in ignorance of the surrounding social context is -- well, it's worse than writing a file picker and neglecting to add a thumbnail feature.

I recommend you read about Allison Parrish's new hacker ethic: http://opentranscripts.org/transcript/programming-forgetting...

The core questions she proposes are essential things every software professional should ask themselves and keep in mind as they work. The political context, and which players in that context benefit from the work you do, is not unrelated at all.

This is a bit extreme, and also quite unhelpful, truthfully. It just happens to sound virtuous because the crosshairs are pointed at fascism, and that's ignoring the myopic focus on the US' issues.

Pick your battles, as the saying goes. It is possible to care about issues without carpet bombing everyone with your concerns, or wedging politics into every discussion.

And similarly, be careful what you wish for. It sounds like a terrible and exhausting way to live.

Is that racism as defined by Luther King or as defined by anti-racism?

https://www.vanderbilt.edu/oacs/wp-content/uploads/sites/140...

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

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

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.

> Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world

I wonder how you justify that, because I'm currently maintaining a vue project in production and couldn't disagree more (honest question)

> I wonder how you justify that, because I'm currently maintaining a vue project in production and couldn't disagree more (honest question)

I am sure majority of developers have had two or more projects using the same framework/library and found the difficulty of maintaining them different.

I manage (different) teams with Vue, RiotJS, React, Django, Slim and Rails as large components of the project stack.

Maintenance of revenue generating code is a unique beast - and rarely has the framework been the magical differentiator.

do you mind sharing the problems? if you could start over, would you have chosen react instead?

What problems are you having?

Maybe it is a problem with the application rather than the framework?

That's not a problem with the framework itself right

I think the opposite: it's a sign that your API is too wide and users expect more special cases and edge features to solve their needs.

If a user felt that way, it would make no sense for them to choose Vue. Vue’s up-front, stated design goal is omit special cases or edge features intentionally and directly assert that’s not a good way to design a framework.

Vue may be right or wrong, but nobody wishing for special case features can claim to be surprised. If you picked Vue knowing you need a bunch of special case features, that’s on you.

Everyone always needs a bunch of "special case features". Always. If you're not doing something new, why are you bothering to write code?

I use Vue and haven’t found it hinders me from doing this myself. Are you suggesting Vue should not just release a framework but also solve every user’s special case? Your comment isn’t making sense to me.

That's like saying that if you don't need to invent new words, why are you bothering to write books.

The abstractions a framework makes available are not analogous to words, but rather ideas. Indeed you should not bother writing a book if you have no new ideas.

Right, I think this is evidence that they're not doing as well at that stated goal as they could be.

Exactly, the users are not doing well because they’re expecting to be able to misuse Vue and demand special case features, while Vue itself is doing good by resisting this and sticking to the plan in terms of framework design.

> 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).

This is why you should always avoid every giant "do everything" framework. Use libraries that are small, focused, and do their one job well enough right now. Then it doesn't matter if it stops being maintained: it still keeps doing its job well. If you do have to replace it, it's much easier, because it doesn't do too much. Vue, Angular, React -- all of them are "build your application around our framework" libraries, not "easily incorporate our library into your workflow" libraries. That is enough for me to immediately reject all of them.

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.

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.

Ahhh the applying Torvalds approach to code reviews.

As long as you can play Doom.

Reply on news.ycombinator.com