chickin

No, I think he wants to ban a slogan on a work uniform. Much more limited scope.

Twitter is a product that is seen as a digital town square.

Initially it sounded implausible that a small size increase could noticably raise connection establishment, but it's possible the small size increase causes MTU to be exceeded, and thus an additional roundtrip.

I'm excited to have an affordable decent RISC-V device.

I'm glad to see the audio on Pinephone Pro improving! That has been a weakness of the Pinephone Pro.

PineBuds looks like a cool product, but I don't see much value in it over off-the-shelf alternatives. What am I missing?

It doesn't.

This shouldn't block adoption, since a dual stack would still be able to access v4, and even a v6-only stack would be able to access v4 via NAT64.

Small/medium sites don't need to be bullied into adoption just yet.

No, my passwords are only on my desktop.

If I need to log into something on my phone, I have to be near my desktop.

I'd be happy to sync my passwords via git-over-ssh-over-wireguard if the need arose.

Obligatory https://lock.cmpxchg8b.com/passmgrs.html#conclusion

I don't follow the advice, and instead choose pass(1) with Yubikey touch-to-decrypt. Being offline, this removes a large attack surface.

How many large tech companies do you think can do that? Each service wants to benefit from the use of other services. Ensuring there aren't dependency loops in this complex graph sounds tricky.

Firstly, congrats on having a popular project, caring about contributors, and seeking advice on how to handle this tricky situation.

When giving pushback, try to avoid raising the stakes, i.e. avoid public criticism, don't issue ultimatums.

If you have a private chat, that'd be great.

If not, try to state your concerns as plainly and non-judgementally as possible, from the perspective of your project.

"Hey X, I'm glad that you are and have been contributing so much to the project. There's a few different ways I see the program and codebase evolving, and I'm keen to work together on figuring out that right path.

It looks like there are places that have different visions, and if you could split PRs into smaller PRs, we can more easily find the changes that fit both our visions."

If there truly is disagreement on some PRs, you can be polite but firm, "I can see the value in X because Y, but this compromises Z, which is a core value of the project."

You have merge access, and should also consider whether this contributor is worth the hassle of all of what I just said. (In which case, skip straight to "polite but firm").

Sharing the repo link here might help us help you better.

If you do this, it might embarrass the PR author, and PRs might become inundated with HN comments.

I wouldn't share the repo link.