Will your PR ever be Merged?

You are right. I am planning to exclude PRs with label spam and bot made PRs. Thanks for looking into this!

I made a few issues on merge-chance GitHub repo, including for the problem you mentioned: https://github.com/PiotrZakrzewski/merge-chance/issues Feel free to give feedback / your ideas!

Piotr Zakrzewski You might want to mention near the start of the current version of this article that you are working on refining your method because of your new insights. Especially the conclusion should be reworded in my view ;-)

done, again thanks for your feedback. Hans Klunder

Hans Klunder Have a look at this: https://acceptance.merge-chance.info/target?repo=vuejs/vue (still not officially released version) even after accounting for spam (mostly ..) the merge chance for the old Vue version is really low .. Now you can download the data that it takes into account to verify (still a bit of spam but no longer dominant).

Piotr Zakrzewski (disclaimer: I am in no way related to the Vue project, just took this one as an example ;-)) I downloaded your data on Vue and found some details:

1) you only have PR's from 2020 whereas Vue's PR's start at 2014 2) it is indeed the old version 2.x version of Vue

Popular projects can attract way more submitters, but that does not mean those are all good developers e.g.: 1) some PR's are closed because of submitter tries to fix something that is not broken (e.g. see https://github.com/vuejs/vue/pull/11595 ) 2) some PR's are closed because the submitter does not provide info to reproduce the error that the PR would fix (e.g. https://github.com/vuejs/vue/pull/11598)

So while the numbers might be correct, it does not automatically prove that a project is less hospitable. There might be other reasons for these figures. Correlation and Causation etc ;-)

Ps. if you still want to name Vue then using the current 3.x Repo might be more current https://acceptance.merge-chance.info/target?repo=vuejs/vue-next

Btw: there also seems to be something wrong with the calculations, e.g.:

https://acceptance.merge-chance.info/target?repo=JuliaLang/julia

It says your chance on getting merged is 91.67% However downloading the data gives me 60 records of which 57 were by contributors and got merged. 3 were by outsiders ("none" in your data) and did not get merged.

Based on this data I could say that JuliaLang/julia is rather inhospitable as JuliaLang/julia always merges from contributors but never from outsiders ;-)

Your chance on getting merged is (based on this data ;-)) 0% and not 91.67%

That 0% sounds rather odd to me (and so does 91.67% ;-)) so I would never publish strong conclusions without more research

Hans Klunder The CONTRIBUTOR authorAffiliation means only the someone merged anything before to the repo. Not that they are an insider. Only members and owners are currently excluded, plus those who merged more than 5 times recently. None is (in most cases) a first time contributor. The Julia repo calculation seems alright to me :)

Hans Klunder What I want to achieve with my stats crunching (and merge-chance.info) is to help people find repos that are likely to accept their contributions. It is true that these (simple after all) stats won't take into account many cases, such as the one you mentioned - a contributor not knowledgeable enough - but I think it may still help tell an active and open project from a non-responsive and insider-focused one. Again, thanks for thinking along!

Piotr Zakrzewski the 5 merges rule is only on acceptance environment. The merge-chance.info version still runs the simple way of calculating stats.

Piotr Zakrzewski Thanks for clarifying this, that does indeed explain the 91.67%

The 5 merges rule sounds reasonable but without supporting evidence it could skew your results.

Once you got your first PR through then you know (and appearantly aligned with ;-)) the "culture" of the project (coding style, doc style etc, way of commenting). The project also gets to know you a bit ("that person from last PR") so you start to build trust. Both items will make it easier to get a second PR merged.

On the other hand: newbies with more ambition than skill will get their PR rejected and will never try again. Only the newbies with good enough skills and/or willingness to invest time will get their PR merged.

I have submitted to repo's where people asked me to rebase twice because they put their own PR's first. I got my PR merged, but it was not really a hospitable experience. Looking at the cold hard figures I got my PR merged, so it counts towards an increased chance of getting merged.

So although the figures are right (even the ones on Julia ;-)) I would not draw any conclusions on hospitality based on this data.

If you really want to know what your chances are on a succesful PR then my advice would be to get to know the project and raise an issue stating that you intent to submit a PR to do XYZ. If that issue goes stale or your intent is dismissed then you know enough ;-)

Personally I also prefer people to first submit an issue and discuss instead of starting stealth and suddenly submerge with a fully loaded PR that changes 75% of my project ;-)

And then some suggestions for other stats that could be useful:

• last time since merge (helps to find projects that most likely been abandoned)
• time between creation of issue/PR and first action (comment/triage/merge/close) (if this takes too long the project might be understaffed)
• total number of issues/PR's over time (is a project still mainstream or moving towards maintainance mode or worse)

Kind regards, Hans