OS stands for "Oh Shit!"

They have taken over the ACF plugin in the plugin store. In an intransparent manner. It is GPL licensed, but had a pro license and features sold. And still does have them on their publishers side.

A strength of the GPL is that the community can fork and take over projects.

At the same time, and this instance is such a case, on a centralized platform, projects can be taken over instead of be forked.

They developed and published a plugin. Now it's been taken over by someone else, on the primary distribution and discovery platform, and they have no control over it. Worse than that, the takeover now offers their sold functionalities for free now.

This makes the "open source but not free, but after two years true FOSS licensed" licenses look very useful if not necessary for businesses and developers that want to monetize. At the very least when they [have to] use centralized platforms.

and Firefox still does not have proper PWA support

I recently had to learn about that, targeting PWA. :(

When I read "you can install an extension for it" I thought that would be simple enough. But that extension then requires an additional Firefox installation which causes it's own share of problems. (Comparatively complicated setup process despite simple walkthrough wizard with installer integration, program shortcuts being added, Firefox onboarding being triggered in the PWA.)

I agree. The split and collective nature makes it hard to assess and fundamentally support though - which is what I was referring to in one point.

oh, that's a cool website

adds it to bookmarks and search bookmarks

Have you tried clicking on rhythm? Have you tried different rhythms?

Interesting take I can't agree with. Maybe their product environment is very different.

once the feature finally arrives in production after a lengthy review, it is in truth no longer aligned with the user’s needs.

I've never had this happen in my development.

In my team, it's fine to skip reviews and commit on main, when it's reasonably small and confidence is high. An obvious and small change also does not take up much time to review.

The effort put into creating a well-/reasonably-described review is effort put into well design changesets and Git history. It helps you cover all bases, cases, and considerations while developing.

Review necessity, investment, and urgency are dynamic. If you as a reviewer don't have the time of mindspace, saying so is fine. Reviewers can be changed or skipped. Reviews can be to different depth and completeness, or partial.

Be mindful of what is reasonable and efficient and reviews are not hard blockers beyond what they should reasonably be. Reviews serve as significant quality, issue, and common understanding gates.

This anecdote only works for some forms of lead experiences. Leading is not cooking.

At work I use Jenkins, and I am very frustrated with it. I've worked with GitHub Actions, GitLab CI, and Azure Pipelines, and none were truly enjoyable to work with. They're acceptable.

The last change I made on our project was to send a build failure and build fix notification email on branches to the last committer. (After having disabled branch build failure notification emails because Jenkins (or its plugins) were not able to send to only the branch developer/new change pusher/author a while ago.)

The best thing we did was introducing commit message conventions and convco to verify them, and to generate changelogs automatically.

It is warranted, and your colleagues seem to agree.

and other people on the team will almost always agree that it’s a good idea and will happily accept my PRs

I think you may be misinterpreting what is happening.

Them not taking initiative does not correlate to its importance. It’s just that most people don’t take initiative - or at least here, evidently, for naming consistency.

How much of an issue ambiguous naming is or may become depends on context - on a lot of things. But ambiguity in naming, just like elsewhere, weakens certainty and reasonability. If you can define and keep clear terminology, then always do so.

09:30 on my team. Between multiple project teams I believe our dailies are between 9:00, maybe slightly before too, and 10:00. Can also depend on the customer if we're part of their development team. I believe not all teams have them every day.

It's a good time for me because I sometimes begin at around 9:00.

At 9:00 begins our central working hours where we're expected to be working. And I think that's late enough for the late starters. So I like where we're at.

I think it's good to have it "early" rather than late. If you struggled the previous day it's a good point of fresh start and possible discussion or follow-up support. It's also where you have [to make] a plan for the day.