My understanding is the GPL based on copyright - and that copyright only protects a specific expression, not a general idea or concept. To suggest that if something is copyrighted, humans cannot learn from it and generate thier own material seems to be absurd.
PullRequest actually reviews the reviewers (I actually became a better reviewer via this).
'LGTM' is considered a bad practise, and I've been pulled up on this several times. Instead, we're trained to take more time, go deeper, and be very clear about what the changes do, and how well they are written even on relatively trivial changes.
I've gotten pushback on best practises, especially from more junior developers or developers on a tight deadline.
I do C# and one common, yet trivial example is poor naming conventions.
As a reviewer we have certain tools we can use to encourage change:
* We can make comments low priority, so the advice is there, but it's skippable.
* We can make summary comments, that are opinionated but don't expect any immediate or direct resolution (great for architectural thoughts).
* We can include example code snippets in our comments. This reduces the burden for the developer to adopt a certain change. I've even gone to the extent of writing small programs to validate a refactor or prove an error exists.
* Sometimes it's not an error, but how that company wants X done. We take note of these for future reviewers.
Overall, this is a diplomacy game, the only power we have is soft power. I find it good practise, as I'm typically a direct kinda guy.
Results?
I've seen a lot of developers, after being introduced to new ways of working, implement that on later PR's. Sometimes immediately, sometimes after it arises a few times. Examples include improved naming, better code structure, usage of newer language features, more clarity in the code, or better SQL injection protection!
I'm a reviewer on PullRequest, and thought I'd share some perspective. Happy to answer any questions in comments.
Background - I've built and led engineering teams at multiple fast-growing startups. In doing so I've seen the incredible value PR's can provide, but also the huge cost of them on small teams. I review on PullRequest part-time as I work full-time building a startup.
Many of the critics here are right. The PullRequest service won't catch every bug. As reviewers on this service, we lack context* to fully understand the impact of every code change.
However, this can be a blessing in disguise. As an outsider, I bring an entirely different set of context to the project. I can see errors or improvements that teams have become blind to, I don't have the pressure of shipping for X release, and I've often been not only where these teams are, but where these teams want to be in X months.
This is all done without using any man-hours on the client team - which is often a critically short resource.
Ultimately the proof is in the pudding, I raise comments on almost every single review I do, raising from best practice to architectural to security vulnerability, and the majority of the time teams take that feedback onboard.
Other QA:
Where are you located? I'm located in San Francisco.
Who approves PR's? I tend to consider my role to advise and sometimes mentor. I will give opinions, but it ultimately the client's job to approve/reject PR's.
My code is great, I don’t need this! Have you tried it? As an outsider, I catch peoples blind-spots. That said, PR is always looking for great reviewers to join the team!
* It's worth noting, that between seeing the code, optionally having access to the full code base, and asking questions of developers - I develop a decent mental model of most projects.