It's good that your team is empowered to tailor its rituals to its needs. It seems that a lot of people forget that the Agile manifesto[1] is loose enough to allow for team-specific customization: "Individuals and interactions over processes and tools".
Companies should not dictate a team's process. If they do, you should leave (if you can) or change it (if you can).
Process should always be owned by the team as a whole. It should also be ever improving (even if this means complete change) and, almost more importantly, you should have as little of it as possible (it shouldn't get in the way).
True, but not at all in line with how Scrum was sold back in the days. I even believe there was a rule saying if you do not follow all the rules of Scrum it is not Scrum.
I can't imagine (haven't tried it so I'm just speculating here) that Magit functions very comfortably on something like a deep clone of the Linux repo, but I think there would be very few monolithic projects most of us would encounter with that kind of lengthy history in our day-to-day work. Maybe some Googlers could weigh in on how their large repos are handled by Magit?
> but the performance profiles & characteristics that we must know about in order to make a choice on which tool to use. And it shouldn't be that each user has to figure it out on their own, dig into PR's or whatever.
That's an interesting take – I like the idea of a catalog of standard tasks with implementations in several languages as well as their performance characteristics. I suppose Rosetta Code gets the ball rolling with this, but it's missing some performance metrics. It reminds me of Ben Hoyt's piece[1] on counting unique words in the KJV Bible in different languages.
Somewhat related: part of the Government of Canada (ESDC) has started their own pilot for making micro-acquisition opportunities much easier to both set up on the government side, and bid for on the contractor side. https://twitter.com/MicroBuysGC
The advantage of having it in a comment vs in a commit message is that the source is immediately available to another developer browsing the code. Otherwise they will have to use git blame (or equivalent) to see why you did it that way.
The advantage of having it in a commit message vs a comment is that there's no chance of the comment just hanging around once it inevitably becomes irrelevant. Once it's irrelevant it's anti-productive to leave it in. Since there is no direct link between a comment and the code it applies to (it could be at the top of the function or class, for example), it's also really easy to forget removing it once it is no longer relevant.
That is a really great idea. I love that wiki page. Some of them are harder to follow in a team that prefers "expressiveness". Quotes because I think it's easier to follow Go's prescription especially for always returning concrete types instead of interfaces.
> return a concrete type and let the consumer mock the producer implementation
It still works great for me! And the only issue I’ve ran into can be entirely avoided just by using mode numbers directly instead of specifying each setting.
Staticcheck for Go kind of does something similar in that it outputs Googleable error codes, but doesn't actually print a link to the pages. It's also included as part of golangci-lint.
It is 100% a Google language. Step 0 of their contributor guidelines is to use a Google product (ie a Google account) for authorship of your commits[1]. It's insane to me that this is required for contribution to the language's development.
1: https://agilemanifesto.org