Do we codify the proposal amendment process?

Evolution Discussion
1

I'm reading through the Swift Evolution Process and I don't see where we go into very many details about how to propose and review an amendment to an accepted proposal.

Some examples of questions about this:

  • Do we expect that an amendment must come from one of the original listed proposal authors?
  • Do we expect that an amendment review must be managed by the original proposal review manager?
  • Is there any practical "statute of limitations" length of time after which we do not accept amendments?
  • Under what general conditions should a proposed amendment instead belong in a new standalone proposal?
  • Do we generally encourage amendments for "bug fixes" in the original design and generally not encourage amendments for "new things" that expand the original design?
  • Would an amendment be appropriate for promoting one of the "future directions" to "detailed design" to then use amendments to incrementally ship new features?

Any more general advice or ideas about that? Is there any place we currently document some more guidance here?

2

In general, yes.

No, but in practice, yes.

Amendments do not span releases (including point releases). We stick to this quite rigorously.

(I can think of a rare exception in the past where a newly approved feature composed in some way with an existing, older feature that required a very targeted tweak which could not practicably be reviewed in any other way than as a small amendment to the older feature.)

Propose an amendment if the original feature is unimplementable (or has serious defects) without it. Otherwise it is a new proposal.

In broad strokes, amendments are for correcting errors.

No, that is not done.

Elements of the detailed design may be unimplementable, though, and later get demoted to a future direction (this doesn't require review because of our shrink-to-fit rule).

11 Likes
3

We will also occasionally accept without review 'shrink to fit' amendments where some portion of a proposal was never implemented. These are typically proposed as a PR agains the original proposal and summarily merged.

10 Likes
4

Fixing a typo does not generally require a new review, FWIW. Substantive changes should almost always be reviewed.

3 Likes
5

Another observation of the SE process over the years to add here is that the proposals are somewhat a “snapshot” of the given moment in time at which the proposal was done.

We generally don’t go back to reword or adjust proposals if say “Swift N+1” lifts some restriction that a past proposal might have referred to as “impossible” etc. So there’s few reasons to do amendments other than something which may have been incorrect in the proposal text (like a missed final change when a proposal is “accepted with changes”, or perhaps some section was left in there by accident, or just not implemented entirely etc).

That’s good, since they’re all just incremental and documenting progress of the language. It’s also how the proposals sometimes can be insufficient as “documentation” and live documents like the swift book still are super valuable, as those should be continuously updated to reflect the current state of the world :slight_smile:

1 Like