Ok? We’re not obligated to watch stuff just because it’s someone’s creative output. We don’t owe this person a paycheck through YouTube ads. Everyone’s got the right to have the necessities of life but that’s got nothing to do with this. Different people have different interests, and someone who’s really into this subject or this creator might want to watch the whole thing, but not everyone has to.

Death of attention span is real but not wanting to listen to ten minutes of bullshit waffle, please like and subscribe, for two minutes of information is not it.

the token is only used for governance (and possibly also fundraising)

That should make you just as worried

So you never stumbled upon bugs while doing work

That’s not what I said… Either the bug is related to the task, or it isn’t. If it’s not related to the task, there’s no reason to fix it on the same local branch either.

Also, some teams do care about building their work on atomic commits, because they understand the problems caused by mixing up unrelated work on the same PR, specially when auditing changes to track where a regression was introduced. You might feel it’s ok to post a PR that does multiple things like bumping up a package version, linting unrelated code, fixing an issue, and post comments on an unrelated package, but others know those are four separate PRs and should be pushed as four separate PRs.

Well, these things don’t meet the standards of your earlier example at all. Linting unrelated code and posting comments on an unrelated package clearly aren’t needed for someone to work on the main issue fix they’re doing. If it’s unrelated code you again lose nothing by switching branches to do the work.

Oh, okay. I’ve never encountered a situation where I needed that bug fixed for the task but it shouldn’t be fixed as part of the task; if they’re touching the same functionality like that I really don’t see the need for two PRs. But sure, sounds helpful in that really niche case.

I think I understood the example; I think it’s faster to switch branches for the bug-fix than to reorder those commits later

It doesn’t disrupt my workflow to switch branches and it’s much faster than some ugly rebase