4 ms·

Without any additional context (which may be critical to understanding fully!) this sounds like an unreasonable expectation on your part. Imagine the sheer num

Without any additional context (which may be critical to understanding fully!) this sounds like an unreasonable expectation on your part. Imagine the sheer number of contributors to a large open source project (that number is nearly 2000 for golang), and then managing the web of contributions and subsequently triaging notifications whenever a change is made. Sounds like a nightmare. Granted I've never contributed to a project of this scale personally, my but experience (as a developer working with other developers for many years) is that the existing processes and tooling are sufficient enough to stay in the loop on things as a contributor.

kevincox 4y ago
If GP wrote a significant part of the code that is being modified it seems like it would be a good idea to involve them in the review. It is a chance to share their expertise and catch bugs early. I don't think it shuold be required or blocking but automatically CCing a few people who have recently changed the code seems like a smart idea. I don't think "managing the web of contributions" seems too impractical. If for example you CC the top 3 contributors who authored the lines that were changed or modified (excluding large automate or "tree-wide" changes) then for any line you write you are getting notified at most once. In practice it will be much less than that since multiple lines will be changed at a time and you won't always be in the top 2 or 3. Plus consider that many of these people are qualified to review the code and would need to be in that discussion anyways. What I'm trying to say is that the data is there and available automatically and the cost of reviewing follow-ups is bounded.
eberkund 4y ago
Doesn't sound like that much of a nightmare to me. Maybe I am missing something but when making a change, you could just use `git blame` and you would see the previous author of the portion of code and add them as a reviewer.
junofan 4y ago
It’s pretty normal to give a heads up in a project of this size.
marcosdumay 4y ago
> Imagine the sheer number of contributors to a large open source project (that number is nearly 2000 for golang), and then managing the web of contributions and subsequently triaging notifications whenever a change is made. Imagining the Linux repository (because I have no idea how the golang one looks), creating this doesn't look like a big deal. I don't think it's reasonable to expect to be contacted, because most projects don't do it. But it's also not unreasonable to contact everybody that touched the code either.

kevincox 4y ago

If GP wrote a significant part of the code that is being modified it seems like it would be a good idea to involve them in the review. It is a chance to share their expertise and catch bugs early. I don't think it shuold be required or blocking but automatically CCing a few people who have recently changed the code seems like a smart idea. I don't think "managing the web of contributions" seems too impractical. If for example you CC the top 3 contributors who authored the lines that were changed or modified (excluding large automate or "tree-wide" changes) then for any line you write you are getting notified at most once. In practice it will be much less than that since multiple lines will be changed at a time and you won't always be in the top 2 or 3. Plus consider that many of these people are qualified to review the code and would need to be in that discussion anyways. What I'm trying to say is that the data is there and available automatically and the cost of reviewing follow-ups is bounded.

eberkund 4y ago

Doesn't sound like that much of a nightmare to me. Maybe I am missing something but when making a change, you could just use `git blame` and you would see the previous author of the portion of code and add them as a reviewer.

junofan 4y ago

It’s pretty normal to give a heads up in a project of this size.

marcosdumay 4y ago

> Imagine the sheer number of contributors to a large open source project (that number is nearly 2000 for golang), and then managing the web of contributions and subsequently triaging notifications whenever a change is made. Imagining the Linux repository (because I have no idea how the golang one looks), creating this doesn't look like a big deal. I don't think it's reasonable to expect to be contacted, because most projects don't do it. But it's also not unreasonable to contact everybody that touched the code either.