Email list hosting service & mailing list manager

How to decide when to declare a new SRFI draft John Cowan (09 Aug 2020 17:35 UTC)
Re: How to decide when to declare a new SRFI draft Lassi Kortela (09 Aug 2020 17:51 UTC)
Re: How to decide when to declare a new SRFI draft Lassi Kortela (09 Aug 2020 17:54 UTC)
Re: How to decide when to declare a new SRFI draft John Cowan (09 Aug 2020 18:01 UTC)
Re: How to decide when to declare a new SRFI draft Lassi Kortela (09 Aug 2020 18:23 UTC)
Re: How to decide when to declare a new SRFI draft Marc Nieper-Wi├čkirchen (09 Aug 2020 19:14 UTC)
Re: How to decide when to declare a new SRFI draft Lassi Kortela (09 Aug 2020 19:35 UTC)
Re: How to decide when to declare a new SRFI draft hga@xxxxxx (09 Aug 2020 19:55 UTC)
Re: How to decide when to declare a new SRFI draft Arthur A. Gleckler (09 Aug 2020 21:39 UTC)
Re: How to decide when to declare a new SRFI draft Marc Nieper-Wi├čkirchen (18 Aug 2020 06:53 UTC)

Re: How to decide when to declare a new SRFI draft Lassi Kortela 09 Aug 2020 19:35 UTC

> 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.

+1

> 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.

+1

Maybe there could be a running number in the document to indicate which
sub-draft it is. The sub-draft number would get erased and reset back to
one when a new draft is announced.

Sub-draft 1 would not have a visible marker as it's the first version of
that draft. Sub-draft 3 would be marked something like this:

* Draft #3 published: 2020-07-18
* (Draft #3.2 published: 2020-07-20)
* (Draft #3.3 published: 2020-07-27)

When draft #4 is published, those parenthesized lines would be deleted.

In practice, we'd increment the subdraft number each time when accepting
a pull request.

At this point (no pun intended) we should stop to consider what is too
much work for Arthur as the editor. At the present pace his post is
starting to be a substantial obligation for a volunteer. By far the most
important thing is that the editor's job doesn't feel like a burden long
term.

> 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".

The answer may (unfortunately) be that we already have everyone on board
who is substantially interested. Hopefully more people in the future.
This year we already have more active people than last year.

But in case anyone is lurking and feeling shy about posting comments
about SRFIs, please post :) Being an expert is not required, and even
the regulars often get things wrong or lack knowledge or ideas, as can
be witnessed. There are too many issues to consider for anyone to master
everything so additional points of view are helpful.