> Adding filters so that developers only look at actionable tickets would be much more sane.
That's a reasonable approach, but I don't understand how it's any more or less sane than autoclosing them with a stale label.
Whether these sorts of bugs are "open but stale" or "closed because stale" seems like it depends on whether the project defines "closed" as "no work planned" or "fixed", which both seem valid.
Either way these bugs will be hidden from developer dashboards but still available in the database so there's no practical difference, you just need to make sure everyone is on the same page about the meaning of "closed".
I've heard various suggestions of only committing spec.md or change requests in the git repo and using that as source of truth.
We have spent decades working on reproducible builds or deterministic compilation. To achieve this, all steps must be deterministic. LLMs are not deterministic. You need to commit source code.
Room addresses/aliases (like #matrix:matrix.org) must point to a single room (in fact, they point to a room version, so when rooms are upgraded, addresses must be pointed towards the new room). But for communities, a better way to organize the rooms would be spaces. Spaces can be joined. Spaces can contain rooms and other spaces. Like discord "servers" (guilds), but more flexible.
It's clearly not free software, since the user freedom is restricted.
It's not libre, since that also refers to freedoms.
It's not really Open Source.
Source-Available has been used to describe this: https://en.wikipedia.org/wiki/Source-available_software
reply