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