| 10 Dec 2023 |
 infinisil | https://github.com/NixOS/rfcs/pull/165#discussion_r1379148280 | 20:52:51 |
 raitobezarius | In reply to @infinisil:matrix.org
If you scroll down a couple replies you'll see that I agreed with it being an RFC this is not how I read it though | 20:53:14 |
| raitobezarius | but maybe that's a language barrier | 20:53:21 |
| infinisil | Ah, so I agree that it's fine to have an RFC for that, just not that the RFC itself should be the canonical place for the bootspec specification itself | 20:54:08 |
| infinisil | Agree that that discussion was a bit all over the place though and hard to read | 20:54:33 |
 @joepie91:pixie.town | infinisil: sorry, I should've been clearer; I read your comment to imply that RFCs should only be used for more or less immutable specification changes, ie. things which are not expected to change any time soon after being accepted/passed, but this doesn't match my understanding of the intent behind the RFC process (where the immutability refers to the RFCs themselves and it is entirely fine to quickly follow up with another RFC that re-changes a just-changed thing), and I wanted to sort this out :) | 20:54:39 |
| @joepie91:pixie.town | since it's important that everyone is aligned on what the RFC process is for and how it should work | 20:54:50 |
| @joepie91:pixie.town | In reply to @raitobezarius:matrix.org
Let's move to #team-members:nixos.org I cannot seem to talk there, unfortunately | 20:56:20 |
| infinisil | I think RFCs themselves should be immutable, giving all the arguments for a decision at a specific point in time. After an RFC is accepted, it should be implemented so that you don't need the original RFC text anymore | 20:57:07 |
| infinisil | * joepie91 🏳️🌈: raitobezarius: I think RFCs themselves should be immutable, giving all the arguments for a decision at a specific point in time. After an RFC is accepted, it should be implemented so that you don't need the original RFC text anymore | 20:57:28 |
| @joepie91:pixie.town | infinisil: right, so in conclusion, you were not opposed to the bootspec RFC being an RFC? | 20:58:10 |
| infinisil | I think we made a good example for a specification with https://github.com/NixOS/rfcs/pull/166 | 20:58:08 |
| @joepie91:pixie.town | * infinisil: right, so in conclusion, you were not opposed to the bootspec RFC being an RFC, as opposed to "just a PR"? | 20:59:38 |
| infinisil | In reply to @joepie91:pixie.town
infinisil: right, so in conclusion, you were not opposed to the bootspec RFC being an RFC? Indeed, I only doubted whether the extra overhead of an RFC is needed and worth it | 20:59:35 |
| infinisil | (and the above) | 21:00:04 |
| @joepie91:pixie.town | infinisil: right, on that point I would want to refer back to https://matrix.to/#/!CJXQiUGqNPcFonEdME:nixos.org/$s2h_thkms4LUz2L3K3Np7xc7f1HDde9aBPfEQKyx8Zg?via=nixos.org&via=matrix.org&via=fairydust.space then | 21:00:19 |
| @joepie91:pixie.town | I think it is important to err on the side of an RFC, to fully integrate the RFC process into community processes; in this case, expressing that doubt seems to have discouraged raitobezarius from making an RFC on another occasion | 21:00:53 |
| @joepie91:pixie.town | and that even 'easy' cases are worth doing as an RFC, to practice with and streamline the process, they'd just likely end up being uneventful ones | 21:01:21 |
| infinisil | Yeah true. There has to be a balance though, both extremes are not great | 21:02:28 |
| @joepie91:pixie.town | I feel like such a balance would fairly easily be reached by simply saying that you are always encouraged to create an RFC, but you are not required to do so unless it's a governance change that might be in dispute | 21:03:16 |
| @joepie91:pixie.town | * I feel like such a balance would fairly easily be reached by simply saying that you are always encouraged to create an RFC, but you are not required to do so unless it's a governance/policy change that might be in dispute | 21:03:22 |
| raitobezarius | In reply to @joepie91:pixie.town
I cannot seem to talk there, unfortunately Argh | 21:03:26 |
| raitobezarius | Let me fix that | 21:03:28 |
| raitobezarius | Ah no I'm not admin | 21:03:42 |
| @joepie91:pixie.town | that would create a minimal burden on contributors | 21:03:45 |
| @joepie91:pixie.town | * that would create a minimal burden on contributors, but also without discouraging them | 21:04:00 |
| raitobezarius | https://matrix.to/#/#platform-governance:nixos.org | 21:05:47 |
| raitobezarius | Here's a room where probably everyone can talk | 21:05:52 |
| 14 Dec 2023 |
 @emma:rory.gay | In reply to @raitobezarius:matrix.org
Right now, maintainers are not reconcilable, you cannot identify them at all and someone could duplicate themselves by adding an email, a matrix and a github all different in the maintainer list (absurd situation, I admit it) i know this is a yesterday discussion but i could duplicate my entry (at least by gh id and email) and it'd still semantically make sense if you spend enough time around me | 08:56:11 |
| @emma:rory.gay | though, making matrix id a list would make more sense, implementation wise | 08:56:30 |
