As a reviewer, I would prefer a fluent latest draft in the official
SRFI repository (and on the SRFI website), which is then tagged and
archived (by a draft number) from time to time whenever some major
change has been made.

While I may know where to look for your latest author drafts, John, I
may not know this for most other SRFI authors, nor would I be able to
keep up with such information. Thus, seeing changes on the official
SRFI website as soon as possible, makes reviewing much easier.

In any case, I think we should try to do everything to get more
reviewers. Most (recent?) SRFIs are often only reviewed by its small
circle of "insiders".

Am So., 9. Aug. 2020 um 20:23 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > My concern is that although numbers are not a scarce resource, having a
> > zillion Draft: lines in the Status section pushes the actual content
> > further down the page.
>
> Agreed.
>
> > Batching works fine for DIY authors, but when
> > the interface is being worked out collaboratively, it's probably
> > important to publish every time *something* is agreed upon.  On the
> > gripping hand, we don't want to drown reviewers in drafts either.
>
> I would say it depends on how substantial the change being agreed upon
> is. E.g. in SRFI 170 we could decide to change an argument that affects
> how a procedure handles symlinks. That's clearly an API change but it's
> a very minor one given the scope of 170. If we changed how _all_
> procedures handle symlinks, that would call for a new draft.
>
> If the collaboration happens on the SRFI's mailing list, and we use
> halfway sensible subject lines in our email threads, people can monitor
> the threads in their email reader to spot things of interest to them
> even if there's no new draft.
>
> > Furthermore, semver is about warning people about incompatible changes,
> > but drafts are "use at your own risk" anyway:  Draft #5 should be
> > understood in semver terms as 0.5 or 0.0.5, depending.
>
> Incompatible spec changes in a draft often signify a change in design
> direction. I think that's analogous to a semver API change. It doesn't
> make a difference that the SRFI is not finalized.