Over the years I've experimented with getting rid of pull requests quite a few times. As a whole and solely as an abstract idea I wholeheartedly agree with the article. Code Review is not the same as a pull request.
With that said, despite advocating at points for pair programming, mobbing, incremental reviews and having worked on a variety of different systems, and having success with some of them, I keep ending up back with PR's for the majority of places I've worked.
The reason why, I think, is one of cognitive load. Pull requests are easy. I don't think they're the best approach to code review ( big PR's often don't get reviewed effectively, and being an effective PR reviewer is a hard skill ) but, it's a good fallback. Everyone knows what a pull request is, the tooling for supporting them is excellent and it requires the least upfront work to get a code review.
With that said, I would highly encourage folk to look at different ways of reviewing code. I don't think many people will fully replace Pull Requests with a solely straight to master development approach utilising non-pr code review styles, but, having the alternatives in your box of tools for specific situations is really powerful.
However, I don't see pull requests going away because, if nothing else, they're an easy, low cognitive load approach for having a second set of eyes on some code.
However there are a lot of checks and balances to it. Not all land falls under the criteria and there's a lot of requirements around forming a group and the proposed use of the land ( such as being geographically local /etc ).
When I last looked into it, I think there'd only been 2 occurrences of the right to buy happening over a 4 year period.
Which does raise the question on 'Does the act achieve the goals it was setout to achieve' or is it mainly political posturing.
That's not something I can really comment on (nor would I want to).
So its a little more complex and a little bit more nuanced.
The mechanism is part of the land reform policy and called the ‘Community Right To Buy’.
Ahead of time, a community body (which has a legal definition) can register an interest in buying qualifying land. All of these notes of interest are available from the registers of scotland and has to be renewed regularly/etc.
At the point that a landowner indicates to the land register that a piece of land is to be transferred (which could be due to public sale, or a private sale or direct transfer), the bodies with notes of interest are notified.
This then kicks off a whole process, including an independent market price evaluation, reviewing of land development/business plans and if that all goes through, final ministerial approval.
It can lead to land being sold at less than the offers over price (scotland has a weird way of doing land/property sales), or for more, depending on if the land transfer was a public sale or a private shift around.
Its not a perfect system and has a lot of flaws, but its worth being aware of the implementation.
With that said, despite advocating at points for pair programming, mobbing, incremental reviews and having worked on a variety of different systems, and having success with some of them, I keep ending up back with PR's for the majority of places I've worked.
The reason why, I think, is one of cognitive load. Pull requests are easy. I don't think they're the best approach to code review ( big PR's often don't get reviewed effectively, and being an effective PR reviewer is a hard skill ) but, it's a good fallback. Everyone knows what a pull request is, the tooling for supporting them is excellent and it requires the least upfront work to get a code review.
With that said, I would highly encourage folk to look at different ways of reviewing code. I don't think many people will fully replace Pull Requests with a solely straight to master development approach utilising non-pr code review styles, but, having the alternatives in your box of tools for specific situations is really powerful.
However, I don't see pull requests going away because, if nothing else, they're an easy, low cognitive load approach for having a second set of eyes on some code.