rglullis

So every user that decides to get notified will add a comment to the thread?

If 100 people trigger it, 100 comments will be the exact same response?

Also, if people end up "deleting the comment to keep the thread clean", will they get purged as well?

Organizations that feel that they desperately need to take that risk, are doing it because they disrespect their team’s time.

Or they are aware they are not in a position to block deployments for 60 hours every week? I've felt more discouraged working at companies that blocked Friday deployments because "it could wait until Monday", and then when Monday came half of the team was blocked or waiting for some new data report that could have been running during the weekend.

It can be the smallest risk in the world, but it’s still a risk.

And it's up to the Engineering manager (or at least the Release Manager in places where that role still exists) to evaluate what would be the trade-off. If you say that a bug coming from a Thursday deployment could've waited until Monday, why can't a bug that has come from a Friday deployment?

I guess my issue is not in saying "Some things should not be deployed on a Friday", but with the generalization. Of course there are things that should be okay to deploy on a Friday, or a Thursday night, or when the manager is on vacation... Being strict about it seems anything but "respect for the team", but a general distrust of the people and the process.

Every change that isn’t already an active disaster recovery can wait for Monday.

I honestly fail to see the difference between "don't deploy on Friday if this can wait until Monday" and "don't deploy on the evening if it can wait until the next morning".

The idea of CD is that changes are small and cheap. No one is saying "it's okay to push huge PRs with huge database migrations on a Friday", what is being said is "if your team is used to ship frequently and incrementally, it won't matter when you ship and your risk will always be small."

I finally accepted that Docker Swarm is not enough for my use cases, so my plan is to put together a k8s cluster with my workstation and my 2 home servers.

Again: if the changes are small enough and you have automated checks in place, they should not require manual intervention.

Plus, what happens if a deploy on Thursday has a bug which only is manifested on a Saturday?

How is that not easily reversible?

I think ask_historians is in itself a community with such an specific goal that it makes it hard to be subdivided, but I see your point. The bigger question is how this could be replicated for other communities, if at all.

possible new ways

Name two, please.

If my theoretical approach causes people to leave, that’s OK.

Right, but that will also mean that the community will no longer be "big". That's my point.

If mods started going as far as deleting threads on the basis of "this discussion is already beaten to death and is not bringing anything new", you can bet that this will be taken as an act of "censorship" and will cause everyone to leave to form their own factions - except maybe the ones that are aligned with the mods enough to understand the principles behind the decision.

The author ended up creating a strawman. Allen's argument was pretty clear: if your deltas are small and your deploy system is fully automated, then no one should be afraid of the risk of deploying.

Given that, if I deploy on a Monday morning and there is a bug on the new release, you revert, reproduce the issue in staging and push only new code when it is fixed. Same thing if I were deploying on a Thursday afternoon or a Friday at 7PM.

The extent of how single-topic a community is depends on the community and moderators. I don’t know what you’re trying to say here.

The discussion started because OP wants to have "more hard tech" and less "tech biz news". How do you think you'd enforce that, and how would you avoid splitting the ones that do not agree with that direction?

On HN, it's easy to avoid splittering the community because there is no "sub-HN". The ones that are not interested or oppose the guidelines have no other option but to leave.

On Reddit or Lemmy, it's quite easy to "fork" a community or simply creating another for the more specific niches. So you don't end up with a single /c/technology, but instead we get a "popular" /c/technology (for the lowest denominator) and the more specific "/c/hard_tech" or "/c/true_tech".

that is a single entity controlling the process.

At any given individual event, yes. But if there is any abuse, it is easy to change said entity.

What I have in mind would be that we can take all these separate functions performed by a large company and break them apart. A centralized organization could be broken apart, but that would require a lot more political power than by simply designing up the system in a way that all functionality is spilt and has to conform to a specific interface.

transfer fees... more expensive

Are you talking about the blockchain fees or the ones established by the "smart contract"? If the former, those can easily be avoidable by using a separate blockchain (specific for the use case and backed/supported by the participating venues, which would be glad to pay anything reasonable compared to the racket run by Ticketmaster), or like I said, not even use a blockchain at all and just stick with a permissioned consensus system.