# -*- mode:org -*- #+TITLE: #+DATE: + Issue: + Status: + Supporter: + Co-supporter(s): * Summary A one-paragraph explanation. Main sales pitch. * Motivation Describe the problem·s this RFC attempts to address as clearly as possible and optionally give an example. Explain how the status quo is insufficient or not ideal. * Detail design Main part. The sections answers What are the tradeoffs of this proposal compared to status quo or potential alternatives? Explain details, corner cases, provide examples. Explain it so that someone familiar can understand. It is best to exemplify, contrived example too. If the Motivation section describes something that is hard to do without this proposal, this is a good place to show how easy that thing is to do with the proposal. ** Backward compatibility # Christopher Baines: # I'm struggling to think of exactly how backwards compatibility would # apply to potential RFCs for Guix. Will your proposed change cause a behaviour change? Assess the expected impact on existing code on the following scale: 0. No breakage 1. Breakage only in extremely rare cases (exotic or unknown cases) 2. Breakage in rare cases (user living in cutting-edge) 3. Breakage in common cases Explain why the benefits of the change outweigh the costs of breakage. Describe the migration path. Consider specifying a compatibility warning for one or more releases. Give examples of error that will be reported for previously-working cases; do they make it easy for users to understand what needs to change and why? The aim is to explicitely consider beforehand potential Backward Compatibility issue. ** Forward compatibility # Christopher Baines: # I do think it's worth explicitly bringing up something like the "cost of # reverting". That is, it's important to discuss things more if there's a # high cost to changing the approach later. For these "high cost of later # change" situations, the RFC process will probably be particularly # valuable. # Noé Lopez: # I think this section could apply very well to governance proposals. How will your proposed change evolve with time? What is the cost of changing the approach later? * Unresolved questions Explicitly list any remaining issues. At submitting time, be upfront and trust that the community will help. At reviewing time, this section tracks the details about the status of the process. At the end of the process, this section will be empty. If not, please be explicit with the known issues by adding a dedicated subsection under Detail design.