2023-03-06 RFC 138 Developing RFCs in Repositories Meeting #1

https://github.com/NixOS/rfcs/pull/138

We are searching for 1 or 2 more RFC shepherds, if you’re interested let us know!

Present: @infinisil (author), @lheckemann (lead shepherd), @Winter (shepherd, first half)

  • Not having inline comments is a drawback of the suggested process and that should be mentioned in the Drawbacks section

    • As a mitigation: an issue can reference specific code lines and GitHub will embed them.
    • @infinisil: Doesn’t replace the line-comment view, can’t see all comments for a file
    • @lheckemann: It’s a drawback, should be documented, if accepted we took it into account
  • More Pre-RFC discussions

    • @lheckemann: What does it entail?
    • @winter: The question is where the boundary between “Pre-RFC” and “actual RFC” lies
    • @infinisil:
      • With this idea you can develop and discuss an RFC together before publishing it
      • To publish it, just open an issue in the NixOS/rfcs repo, the process of discussing and developing stays the same
  • @lheckemann: What about using a fork of the rfcs repo and creating a PR?

    • @infinisil: Discussions are tied to the repository, not the branch → Can’t have multiple rfcs at the same time in discussion for one GitHub organization/user
      • Could avoid with different accounts, or for time-distinct rfcs, detach/rename the old fork, create a new one
    • @infinisil: PR’s would invite duplicate discussions in the PR code review comments
  • @lheckemann: Easy to lose discussions if repository is not under the NixOS organizations control, are we okay with that risk?

    • @infinisil: Ideally in the future: Automation that creates repositories in the NixOS organization
    • @infinisil: What about archiving RFC repositories, is that possible?
      • @lheckemann: Archiving shouldn’t be needed because the RFC should take the feedback into account in some section
    • @infinisil: Maybe it should be a blocker for this RFC
      • @lheckemann: Not sure if it needs to block, but we should document the decision as part of the RFC text
    • @infinisil: Happens very rarely in any case
    • @Winter: User could delete the repository for cleanup. How about asking the user to transfer the repository under the NixOS organization, require it as a condition
  • Tied too much to GitHub?

    • @lheckemann: Would not be tied to GitHub if we don’t require transferring the repository (see above)
      • @infinisil: Already tied to it, so another discussion
  • How to find more shepherds?

  • @infinisil: How to proceed? Try it out?

    • @lheckemann: Does this even need an RFC? People could just do it, you kind of did already
      • @infinisil: It’s simpler to only have one process
      • @infinisil: If optional, the RFC’s not being developed/discussed in a repository may still invite huge threads, there’s no way to know in advance how big a discussion will get
        • @lheckemann: Not much point in a “suggestion” RFC
  • @infinisil: Point out how to watch for changes/issues in an RFC discussion repo

Action items

  • Cover line-comment view in Drawbacks section
  • Cover fork/PR approach in Alternatives section
  • Require transfer of the merged RFC repository to the NixOS organization
  • Mention potential future automation
  • Publish meeting notes on Discourse with a call for shepherds
  • Cover alternative of this being optional and not required
  • Cover how to watch a repository RFC
  • Create calendar event for regular bi-weekly meeting, same time

Radical counter-proposal: let the steering committee merge RFCs in any state, but put them in the drafts directory and make them say DRAFT in the text until they are accepted. Then use labelled issues and pull requests to discuss and progress their state.