"And then the actual repo owners/contributors have a chance to comment on the change (with nice tools like you can comment on individual lines of code), and ask for corrections. (And then the author of the PR can make corrections, and they'll show up automatically in the pull request.) Then, finally, if they approve of the contribution, the pull request is merged."

There is a workflow of discussion for contributors , commits can have comments and those comments can form discussions. You can also open�� issues and have a discussion there pointing to specific commits. Github issues are not just there for bugs and now with its powerful tagging system you can use it for all sort of discussion without polluting other kinds of issues like bugs. Wiki can also be used for roadmap , again linking to specific commits its easy etc. Thats what I love about Github its so flexible.

The main difference of pull requests is a way for forks to exchange code. I am not saying you cant have a fork that closely follows the main repo and just send pull requests but as I said in that case it would make more sense to be a contributor directly. The whole process of accepting is not a such a huge deal since you can always revert or even edit specific commits.

"As a contributor to a repo, you can create a branch and a pull request towards another branch in that very same repo, so you have access to the same social mechanism if you want to use it."

yeah I kinda suspected that could be possible but why not just merge and get it done ? Again the social mechanism of pull request is not any more social that regular contributor commits.