A better way to differentiate might be to say how many watts have been used for an answer.
> Humans reason
Are you sure? They reason in a way to match others predictions, right? The problem of humans transporting information from one individual to another remains. All reason can effectively only be prediction, as it requires two persons at minimum. And there is a lot of noise to filter.
> LLM predict.
Well, there is a human that needs to reason with what the LLM has predicted. So from that perspective, it should suffice already for the moment.
> We are the collective voice of the game development industry—developers, game designers, artists, and business minds. Passionate about our craft, we've invested years in shaping an industry that touches the lives of millions worldwide.
Clearly the "our craft" is "business minds" and the problem with increased Unity fees is that their add business is at risk despite all these "business minds" invested years to shape their model.
While I'm able to understand your argument, IMHO the MIT license is not displaying that well. Community is plural, and fork with MIT could be like Windows: Closed source. End of the (fork) line.
Given the project itself is still strong, this might not be a problem, but then I see no reason why it has chosen it in the first place if not for that specific option.
Everything was reverted with 48 hours, your arguments might all apply theoretically but given scope, size, practice and handling, I wonder - apart from the theory - what your opinion is how they practically apply for this case.
Thanks, that better helped me to understand your comment. Additionally I was not aware if that was with pull-requests or more with regular code-reviews as part of the development process. That was an additional insight, thanks for sharing.
Nevertheless, things can be different, e.g. if CI passes, it merges already, no need to have a request for merge, which are often a blocker to keep a steady development flow. Naturally, this benefits from tests that are already run during development, if not driving the development.
And I didn't read you're against testing nor aligning white space and comments at all, more the localization. Actually the points you raise are looking important to me, because if alignment comes in late, this can cause a lot of erosion, which can hinder any review if not even provoke merge conflicts which are stopping the process quite early and require re-iteration.
Your approach should also work towards non-release blocking code reviews, a property I personally like, as I've seen teams struggle with code reviews, becoming more and more of a burden, even after practicing it has found its way. But that is only a subjective comment of mine, every project is different, which makes it an interesting topic for me.
Your relatively short comment caught my interest and I'd like to learn more about your thoughts.
As, IMHO it depends (as so often). Code review is commonly the place that puts the current style under test (hence automated otherwise you don't have the results during review) and under review.
E.g. Code review finds out if a code-style is missing, incomplete or even outright wrong.
If that approach is taken, passing tests and code-style must be in there, otherwise it is not useful to argue about violations. From my understanding I would therefore see those results be available during review.
It may also be that there is code-style for automated test-code, and that code part of the review. Without taken this into context of the code-review, I miss a bit the boundary of your comment.
Could you elaborate a bit where you draw the line and why? E.g. I can imagine there is a benefit to keep a distinct context for code-reviews so that they are still practically feasible and those parts that need further adoption are put into a different phase, like steps before (preparation of the current increment) or after (preparation of next increments) the code-review itself.
IMHO this is also a good remark in context of those container images that most of all have /bin/sh. Technically not all, but many distro based containers.
so if someone plans to extend the script so that it injects it iself into the container or what not.
additionally modifying data in binary form was a longtime practice last time I looked, but I might not remember correctly.