>>> Personally, I'm pleased with the way this format turned out and would
>>> consider it almost done for publication.
>
> @Lassi I don't know what is your intended timeline for this project,
> but I would take a more "thorough" approach...  I would say that
> before we actually submit something for "ratification", we take our
> time to experiment, design, and implement the required tools.

I have to have the same timeline as everyone else since this is a group
effort :) I was just saying that the S-expression format has basically
all the information I'd like to have, and also supports everything
Arthur is tracking (well, we could add "see also" entries). I don't have
any further experiments to do so I'm done when you're done.

It seems that the HTML structure requires more thought, though again we
have basically exhausted the practical options. (It's either the current
HTML with some added classes, or your clean XHTML. I guess the decision
would rest on how much time it takes for a volunteer to convert to the
XHTML since we can't require all authors to submit SRFIs in it.)

I believe the HTML format is the only thing that will have implications
for future SRFI authors, so that would be the only thing that has to be
finalized in a "formal" manner (i.e. once we're done, we'd formally
announce requirements and suggestions for the new submission format).

I think the S-expression format and tool development can be more laid
back since they affect fewer people -- mostly Arthur and us for now :) I
wouldn't worry about a formal release or publication of these. We could
make one experimental repo with the new S-expression files. I could
update the <http://schemedoc.herokuapp.com/> API to use them and Arthur
could make versions of his personal scripts related to running the SRFI
process and website. Once the S-expression format is reasonably stable
so we can use it ourselves, we could push those files into the official
repo of each SRFI. Then we could make an announcement. But once again
this would not affect or disrupt the SRFI process, just people making
tools (currently just us).

The tools could have their own repo (or be in that same repo). We could
start with the personal tools we have now and gradually combine them
into an official tool written in Scheme. That tool would eventually
cross-validate the SRFI HTML and the metadata files to check that they
have the same information (as far as applicable).

> I say this, because if we are to "modify" anything in the SRFI
> process, I think it should be done only once (else it would lose
> credibility and traction).  Thus we should have everything
> "integrated" before we start going through old SRFI documents and
> propose the new process.

I definitely agree that the HTML format shouldn't be announced formally
until we are reasonably sure we have got it right. But I wouldn't stress
about the S-expressions and tools, as above.

> Therefore the "devil is in the details"...  Just saying that "a place
> would be held in the format" is not enough, as these SRFI's
> cross-reference each-other.

> As said above, at least for me, my time is quite limited on this
> project and it would take some while for me to go through my
> "experiment".

It would be great to have consistent types across all the SRFIs but it
sounds like that would take a lot more time to get correct than the rest
of the things we intend to do. Therefore I would suggest a formal
announcement just for the HTML structure. The types could remain in
continuous development as long as needed, and live in their own
S-expression files which continue to be updated as progress is made.

> I also propose that this experimental process should be
> done in the open, perhaps on this mailing list if there are no
> objections.

I think this has turned out to be a good place for discussion so far :)