This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.

How is that different from other bug tracking systems? The devs have to triage submitted tickets there too

There are several automation solutions for GH issues. You could have an automatic “unconfirmed” tag applied to every user-created issue if you wanted.

RFC1925¹, section 2(3):

  With sufficient thrust, pigs fly just fine. However, this is
  not necessarily a good idea. It is hard to be sure where they
  are going to land, and it could be dangerous sitting under them
  as they fly overhead.

Translation: sure, you can make this work by piling automation on top. But that doesn't make it a good system to begin with, and won't really result in a robust result either. I'd really rather have a better foundation to start with.

¹ https://www.rfc-editor.org/rfc/rfc1925

I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.

> I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.

The rebuke to your comment is right in your comment: "other ticket systems do this by…"

The ticket system does it. As in, it has it built-in and/or well integrated. If GitHub had the same level of integration that other ticket systems achieve with their automation, this'd be a non-issue. But it doesn't, and it's a huge problem.

P.S.: I hate to break it to you, but "I hate to break it to you, but" is quite poor form.

No, it's not that well integrated. They don't call it 'tags' but they work exactly the same way. JIRA, the most commonly cited example in this thread, has a whole separate engine for it and your JIRA admin builds the ticket flow manually. All the way back in RT this sort of thing was handled by a cron job. Github leveraging actions to accomplish this isn't much of a difference.

P.S. I didn't ask

They're already doing that by moving discussions to issues. In fact it's more work for them because they have to actually create the issue instead of just adding a "confirmed bug" label or whatever.

I guess it probably leads to higher quality issue descriptions at least, but otherwise this seems pretty dumb and user-hostile.

There’s a one-click button to convert from discussion to issue (and vice versa). It’s hardly more work. But I do feel like discussions are kind of hidden and out of the way on GitHub.

On repos I maintain, I use an “untriaged” label for issues and I convert questions to discussions at issue triage time.

Isn't that basically what Ghostty is doing also?

That's always the case. Who else should triage?

Why would you need aria attributes if it's summary tag?

I presume it has to do with AT and how it typically interprets the tag. TBH IDK other than I’ve seen it come up in accessibility discussions / groups.

The beauty of open source is you can always fork the previous version. I don't see how it's anymore of a bait and switch than a vendor raising the price of a product.

> I don't see how it's anymore of a bait and switch than a vendor raising the price of a product.

That's often called bait and switch if a subscription price is hiked significantly.

No relation. This is free, open source, where you can fully use, modify, and continue it as far into the future as you want. A paid model, you lose access if you don't adhere. With this, you're losing nothing except future development time, which you were previously getting for free. These are completely different things.

My naive interoperation of this comment section says there were quite a few people making money on this work, without helping them pay their bills.

The ability to fork something doesn't mean its viable or reasonable for everyone. That's a risk to users in case of both extremes: bait-and-switch tactics (mostly due to commercial motivations) or abandoned projects (see ASF Attic).

> doesn't mean its viable or reasonable for everyone

Related, it's often not viable to give away something for free.

I don't think governments seizing domains are paying anything.

The rating is taking into consideration that it has 4 engines. The term is just confusing because it used to only apply to twin engine aircraft.

I think that is the method.

How can it both have no side effects and have undefined behaviour?

By being declared as that?

Division has no side effects, and division by 0 is UB. UBs only occur in invalid programs, so behaviour in case of UB is not relevant to a discussion of side effects or their lack thereof, in language terms these are not programs at all.

If print statement never completes then it is a well defined program. Because there will be no division by zero.

Is your grandmother a bike every time the receiving side of a pipe terminates before the sending side, or only when it happens to interrupt a printf?

Both statements don't need to be true. The compiler just has to prove that at least one of the statements will always be true.

True but it only has no side effects if it's well defined. The compiler can assume it's well defined but only if it's executed.

A side gig is something on the side, not your "main gig".

There's two products here Bluetooth trackers and phones. People don't want to buy phones that expose themselves to tracking by other people.

Every phone is already being being tracked and logged. What youre really saying is that people often tolerate some tracking if done by CIA/phone company/Apple/Google/FB. We're just playing with semantics here. Tracking is either acceptable or not. The only real solution is to go off-grid.

It's reasonable for a person to have a threat model that's more concerned about their violent narcissist ex attaching an AirTag to their car than about the CIA.

It's astonishing how few people actually seem to realise this.

If the FBI wants to obliterate me, they can get a warrant and send goons to my house. The costs of preparing for that threat model are excessive, so I don't.

If some scumbag ad company wants to track me, they can eat shit on my adblocker and not track me. The cost of preparing for that threat model is trivial, so I do.

CIA/phone company/Apple/Google/FB/some rando are all different, independent, situations; as a reasonable adult I have decided that some of them are acceptable, some of them are not.

They have ARN's which include the account which a glob match is useful. Something like "arn:aws:*:*:1234567890:*" is useful but "arn:aws:*:*:1234567*:*" isn't