6 ms·

My experience with contributing there is that they are too 'Google'-ized. I guess they pay for the language, so that's their right. Myself and another non-Goo

My experience with contributing there is that they are too 'Google'-ized. I guess they pay for the language, so that's their right. Myself and another non-Googler wrote and worked on a portion of the code. We'd of course have to get it blessed and merged by G, which wasn't that bad. My problem became when a Googler started messing around in that portion of the code, changed it, got it approved, without it notifying the two of us who wrote it. Not that we'd need to be approvers or anything, just would have been nice to have gotten some heads up so we could see how it was changing. I only know as it ended up having bad behavior, went to see what changed, and wrote a rant on the mailing list about it :).

endorphine 4y ago
Care to share the link to that particular discussion?
- silisili 4y ago
  In the name of what anonymity I've tried to keep here, I'm going to refrain, sorry.
dcormier 4y ago
Sounds like the tests around what you were trying to achieve with your changes weren’t complete enough, possibly?
- silisili 4y ago
  IIRC, it was an overhaul and improvement some months later. I didn't mean to at all imply that our code was better or that we knew better - the overhaul was much needed, only that the review process seemed broken. This was 8-9 years ago, so not exactly fresh in my brain.
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
  - sangnoir 4y ago
    > I didn't mean to at all imply that our code was better or that we knew better >> [...]when a Googler started messing around in that portion of the code, changed it,[...] it ended up having bad behavior Your word choice did no favors to your intention.
afandian 4y ago
Did you have test cases provided an intended contract for the code? Did they break? And did they provide a justification for the change of contract?
ajgrover 4y ago
is your expectation that if you contribute to an open source project that you would get notified if your code is later modified? if I was in your shoes, I would assume that once the feature is merged, the maintainers have final say and can modify or remove your code as they wish. An RFC for a breaking change would surely be nice but I wouldn’t expect any kind of notification if the change was some kind of minor update or enhancement.
- flir 4y ago
  Would be a nice feature though, wouldn't it... sort of git-blame-by-email. "Hi, this PR is modifying a line of code that you submitted. You don't have to do anything, we're just notifying you in case you want to weigh in on the PR". You could extend it into a general purpose "subscribe" mechanism - if someone raises a PR against this bock of code, please email me.
  - tracker1 4y ago
    For that matter, simply attaching a @notify to the pull request (assuming it's a public repo) then the repository manager can notify you with the PR. There are automation tools that do this already.
  - kevincox 4y ago
    Sounds like a great way to help share knowledge about a particular bit of code. I can even imagine something like take the top 3 authors of code changed or removed by the PR and if they aren't already the author or reviewer CC them. That way you can pull in some people with context.
  - bborud 4y ago
    Yeah, I think this is something that has to be solved by the tooling. It isn't reasonable to expect people to do a git blame and remember to email everyone whose code you want to change. That being said: I don't even expect people to notify me when changing code I have written at work. In fact, if people bothered me about code someone else should be perfectly capable of reviewing without me, I'd be a bit annoyed. I really don't need MORE interruptions. The fact that a breaking change was introduced is really an orthogonal issue. It isn't a given that the original authors would catch the problem. Maybe in this case they would, but I don't think this is a given. I have certainly experienced reviewing pull requests against code I have written only to let breaks slip by me. :-) To me this sounds more like the code didn't have sufficient tests to catch the breakage. If I had written the code I would probably have looked at improving the tests after helping fix the breakage so at least it doesn't happen again. But of course, that's just speculation since I don't know what was broken and how.
guynamedloren 4y ago
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
infogulch 4y ago
This is an interesting problem for any kind of significant contribution made to a big project. To summarize, you seem to have some expectation that you would at least be notified when your past contribution is undergoing changes, with the intention to provide feedback at your discretion. Personally I find this expectation relatable and reasonable, but I'm not exactly sure why. To counterpoint, it's pretty easy to explain why you might not have been pinged; if every engineer was pinged every time any of the code they wrote changed I expect they'd be buried in notifications. Also, whose responsibility is it to send the notifications? the org's? the engineer making the changes? This seems like a lot of organizational and/or social complexity that has no chance of actually being implemented. Maybe the solution is that it's the engineer's responsibility to watch the code they care about. This model is better aligned with everyone's goals, but it highlights the lack of tooling to watch for proposed changes and manage your desired notifications.
perrygeo 4y ago
So, if the correct behavior was known, why did you not write a test asserting the correct behavior? I understand that it can get complicated, just legitimately curious if the behavior could or could not be easily captured by the test suite.

endorphine 4y ago

Care to share the link to that particular discussion?

silisili 4y ago
In the name of what anonymity I've tried to keep here, I'm going to refrain, sorry.

dcormier 4y ago

Sounds like the tests around what you were trying to achieve with your changes weren’t complete enough, possibly?

silisili 4y ago
IIRC, it was an overhaul and improvement some months later. I didn't mean to at all imply that our code was better or that we knew better - the overhaul was much needed, only that the review process seemed broken. This was 8-9 years ago, so not exactly fresh in my brain.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- sangnoir 4y ago
  > I didn't mean to at all imply that our code was better or that we knew better >> [...]when a Googler started messing around in that portion of the code, changed it,[...] it ended up having bad behavior Your word choice did no favors to your intention.

afandian 4y ago

Did you have test cases provided an intended contract for the code? Did they break? And did they provide a justification for the change of contract?

ajgrover 4y ago

is your expectation that if you contribute to an open source project that you would get notified if your code is later modified? if I was in your shoes, I would assume that once the feature is merged, the maintainers have final say and can modify or remove your code as they wish. An RFC for a breaking change would surely be nice but I wouldn’t expect any kind of notification if the change was some kind of minor update or enhancement.

flir 4y ago
Would be a nice feature though, wouldn't it... sort of git-blame-by-email. "Hi, this PR is modifying a line of code that you submitted. You don't have to do anything, we're just notifying you in case you want to weigh in on the PR". You could extend it into a general purpose "subscribe" mechanism - if someone raises a PR against this bock of code, please email me.
- tracker1 4y ago
  For that matter, simply attaching a @notify to the pull request (assuming it's a public repo) then the repository manager can notify you with the PR. There are automation tools that do this already.
- kevincox 4y ago
  Sounds like a great way to help share knowledge about a particular bit of code. I can even imagine something like take the top 3 authors of code changed or removed by the PR and if they aren't already the author or reviewer CC them. That way you can pull in some people with context.
- bborud 4y ago
  Yeah, I think this is something that has to be solved by the tooling. It isn't reasonable to expect people to do a git blame and remember to email everyone whose code you want to change. That being said: I don't even expect people to notify me when changing code I have written at work. In fact, if people bothered me about code someone else should be perfectly capable of reviewing without me, I'd be a bit annoyed. I really don't need MORE interruptions. The fact that a breaking change was introduced is really an orthogonal issue. It isn't a given that the original authors would catch the problem. Maybe in this case they would, but I don't think this is a given. I have certainly experienced reviewing pull requests against code I have written only to let breaks slip by me. :-) To me this sounds more like the code didn't have sufficient tests to catch the breakage. If I had written the code I would probably have looked at improving the tests after helping fix the breakage so at least it doesn't happen again. But of course, that's just speculation since I don't know what was broken and how.

guynamedloren 4y ago

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

infogulch 4y ago

This is an interesting problem for any kind of significant contribution made to a big project. To summarize, you seem to have some expectation that you would at least be notified when your past contribution is undergoing changes, with the intention to provide feedback at your discretion. Personally I find this expectation relatable and reasonable, but I'm not exactly sure why. To counterpoint, it's pretty easy to explain why you might not have been pinged; if every engineer was pinged every time any of the code they wrote changed I expect they'd be buried in notifications. Also, whose responsibility is it to send the notifications? the org's? the engineer making the changes? This seems like a lot of organizational and/or social complexity that has no chance of actually being implemented. Maybe the solution is that it's the engineer's responsibility to watch the code they care about. This model is better aligned with everyone's goals, but it highlights the lack of tooling to watch for proposed changes and manage your desired notifications.

perrygeo 4y ago

So, if the correct behavior was known, why did you not write a test asserting the correct behavior? I understand that it can get complicated, just legitimately curious if the behavior could or could not be easily captured by the test suite.