gieksosz

14 ms·

31.
by gieksosz 5y ago
it is indeed that.
32.
Google Maps ToS can be summarised as: Don't use it(twitter.com)
68 points by gieksosz 5y ago|20 comments
33.
Show HN: Make Taylor Proud of Your Estimates(github.com)
1 points by gieksosz 5y ago|0 comments
34.
Fastest way to get city data(medium.com)
2 points by gieksosz 5y ago|0 comments
35.
You might need to dump JSON faster than you think(medium.com)
1 points by gieksosz 5y ago|0 comments
36.
Matching GPS Measurements to a Road(medium.com)
2 points by gieksosz 5y ago|0 comments
37.
by gieksosz 6y ago
There was not enough outsiders PRs among recent prs. It will be possible to check this one after I deploy new version with improved methodology.
38.
by gieksosz 6y ago
There is more repos like this and it is hard to detect them. Especially that sometimes they do have some actual merged PRs in GitHub for some special circumstances (for instance bazelbuild).
39.
by gieksosz 6y ago
I am working on addressing that. So far spam detection is the most difficult one. Ignoring PRs that were closed by the author themselves or changed readme.md helps but is obviously not enough.
40.
by gieksosz 6y ago
This is an interesting idea. There certainly are pretty crisp modes in distribution. In a typical company backed project some devs will make and merge multiple PRs a month while outsiders will make a couple PRs in total out of which one or
41.
by gieksosz 6y ago
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 organizatio
42.
by 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 P
43.
by gieksosz 6y ago
might be useful for some broader analysis.
44.
by gieksosz 6y ago
Thanks for feedback! I am in fact working on features to improve that. Spam filtering is one of them.
45.
by 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 au
46.
by 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
47.
by 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.
48.
Vuejs rejects close to 75% of outside contributions(merge-chance.info)
90 points by gieksosz 6y ago|86 comments
49.
by gieksosz 6y ago
Vue is even "worse" by this metric, 24% https://merge-chance.info/target?repo=vuejs/vue
50.
by gieksosz 6y ago
Author here. React devs do respond to PRs very fast! It is definitely a pattern among company backed open source projects.
51.
by gieksosz 6y ago
I am working on adding more metrics, like stale PRs. Maybe I will incorporate response time if it is feasible. Thanks for feedback!
52.
by gieksosz 6y ago
Hmm maybe I could find a way to exclude bot made PRs from the stats. Thanks for your feedback!
53.
by gieksosz 6y ago
Sadly I cannot account for this .. In theory I could check if the commits/or just head commit from PR founds its way into the main/master tree. But for now it just checks the status of the PR.
54.
by gieksosz 6y ago
Thanks! I am also thinking about adding percentage of stale PRs and/or median time to get merged.
55.
by gieksosz 6y ago
fixed and deployed
56.
by gieksosz 6y ago
true! I have just realised that. I will fix that. Thanks for feedback!
57.
by gieksosz 6y ago
Author here! This is a small web app written in Python Flask and deployed on Cloud Run. It extracts data from GitHub via their GraphQL API and caches it in Firestore (just because it is way cheaper for a low traffic side project than runnin
58.
Show HN: Check if a GitHub repo is open to contributions(merge-chance.info)
17 points by gieksosz 6y ago|12 comments
59.
Minimal Implementation of Macrobase Diff from Stanford Data Group(github.com)
1 points by gieksosz 6y ago|0 comments
60.
GraphQL with keep-alive not slower than gRPC(blog.q42.nl)
5 points by gieksosz 8y ago|0 comments

More ›