4 ms·

If I: - built Project A - left Project A and started the competitor Project B - contributed a lot of PRs to Project B each week, and - saw that a guy in a simil

If I: - built Project A - left Project A and started the competitor Project B - contributed a lot of PRs to Project B each week, and - saw that a guy in a similar role at Project A, has relatively few weekly contributions to Project A 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.

tarruda 5y ago
> 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.
charlespierce 5y ago
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.
HWR_14 5y ago
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.

tarruda 5y ago

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

charlespierce 5y ago

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.

HWR_14 5y ago

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.