The problem with that mindset is that there is a huge difference between leading a greenfield project with very few users and leading an established project that's a major piece of the infrastructure in basically every front-end app. In the former case, the bulk of the work is actually building the functionality, so looking at PRs / commits can make some sense. In the latter case, there are more constraints to consider and a lot of the work is in determining _what_ needs to be worked on, as opposed to actually writing new code. Also in things like project management, fundraising, etc., which don't show up as GH commits.

> My eyebrows would be a little raised. Not that I would call them out in a tweet, but I would at least be curious where that guy is spending his time.

It is one thing to raise the issue in private with "Project A", another thing is to tweet this to thousands of followers. Especially after "Project A" already had resolved the issue on its own.

Why? Once Project A gets to feature complete, does it need to be worked on at anywhere near the same rate? Other than fixing bugs/upgrading because of APIs they are using upgrading, the number of commits should be really small. Or should people change CSS constantly to have a string of useless PRs?

At that point, a huge amount of someone's time is spent managing bug tickets, attempting to isolate debug, etc.