• Consolidated Boris Nagaev, Rijndael (rot13maxi), and Adam Gibson (waxwing/AdamISZ) under canonical names.
• Removed 'admin' from the developer network.
• Switched to a log-damping heuristic ($1 + \log_2(n)$) to avoid biasing the map with raw volume counts. This is a judicious manual choice for now; still exploring more data-driven ways to model this. let me know if you have thoughts.

I used BIP data to categorize messages and thread headers. Will show more data on orange-dev-tracker. If you have ideas on what kind of BIP analysis we should do, let me know

Thanks. let me check.

this part is fixed.

I'll refine the impact profile to make it more explanatory, in case it's confusing

I'll take this 'concern' as worth exploring.

methodology: compare pre/post commit activity (count and consistency) to see if there's any correlation with the drama. I'll use May 2025 as one cutoff date to start, and we can repeat this for other key moments or drill down into specific developers/maintainers

Issue: 2024 Tests Not Showing

Root cause: My categorisation logic had a priority flaw. I defined:

Wallet category rule: src/wallet/
Tests/QA category rule: src/test/, test/, or src/bench/

Conflict: Files in src/wallet/test/ matched both patterns. The wallet rule took precedence, so test files were incorrectly categorized as wallet code rather than tests/QA.

Fix: Adjusting logic to catch component-level test directories (e.g., src/[component]/test/) before falling back to component categorisation.

On Maintainer Tracking

Fixed the 'relay race' chart using:

Static file source: Your Stack Exchange maintainer list
Merge commits to identify maintainer activity
Verification: Cross-checking against the trusted-keys file to confirm maintainer identities

Thanks for pointing out the discrepancy. I'd appreciate it if you could flag any other data points that don't look right and need fixing

Thanks for jumping in. Curious to know what do you see in the chart.

Also,

1: You’ve been in the trenches, so love to get your thoughts on: what numbers or views would actually help you day-to-day?

2: Any buckets or labels feel off? Happy to re-cut the data so it maps to how contributors really think about the code

If this turns out useful, will love to make it some sort of engineering analytics or developer health dashboard.

Thanks for pointing that out. In the new report I do pull everything, but I treat merge commits separately—check the Total/Author toggle in the Contributor Galaxy charts.

https://sorukumar.github.io/orange-dev-tracker/contributors.html

Any numbers look off to you?

Appreciate you taking the time to comment

Yes, for sure, that's the right way to do it. I'll add them in the next iteration

Good to hear from you. trying to wrap up a couple of projects. will visit soon.

i wonder why in the viz you are class of 2014

https://m.stacker.news/46226

yes.

if it interest you, we can certainly do more. the next step could be log analysis, and this is a useful link i found with a quick search. We can try using any of the tool/libs that are useful.
https://livablesoftware.com/tools-mine-analyze-github-git-software-data/

No. it would be a good next step.

Additionally, i am debating whether it make sense to break commits into components like wallet, consensus, networking, GUI and others. it would add insights on the kind of work that is being done. What could those components be? and, then I need to figure out a way to group it from the commit log.

deleted by author

intriguing and thought-provoking writeup.

Even though it is about one idea of compression, it is getting applied in so many diverse contexts that my mind is numb in a good way. So I may be off track here.

First, it is not that the only benefit of compression is coordination, it does bring incremental insight. If we agree with 'I write to know what I am thinking' we have to agree that we don't have a good sense of our thoughts and experiences if we don't compress them, and in some cases, condense them into metrics.

In general, by compressing an idea or experience, we gain wisdom, and when we uncompress a number or a thing we may get incremental wisdom that we didn't get while compressing it. So both are necessary and both are great.

It is a cycle.

On KPIs for a company: I agree with both perspectives and don't view it as a dichotomy. One person suggests condensing company goals into meaningful metrics, while another, after careful consideration, chooses not to. In many cases, the process of debating and creating metrics provides insights and wisdom, It is not about following it dogmatically

Similar thoughts on Inflation. I don't take it as measuring inflation with a single number is 'wrong', I take it as it is not the best way to track it now, and it is due for a change.

I guess the conversation on this thread is in line with my feedback.

I had it bookmarked to look at when I had time.

A quick thought, I feel like we should have basic data like # of posts or # of comments. this gives an idea of how noisy or reliable the calculated metrics per post are. Alternatively, we could have an error bar.

Extending the same thought again, I am not sure whether you have taken the outlier out for your analysis. A couple of highly successful posts may make a territory rank high. This post #450871 by @davidw reminded me of outlier posts.

There is a 'truth' to it, but I would have put it differently.