Thanks for thinking about this.

> First, to take pressure off of the SRFI 198 process, create an
> https://srfi-email.schemers.org/schemeerror/
> <https://srfi-email.schemers.org/schemepersist/> page that the SRFI can
> refer to.  Maybe create a schemeerror-meta list cited on it at the same
> time, to move this discussion from this SRFI API one to a more fitting
> place.

A mailing list is a good idea.

> Create a relaxed, micro-quasi-SRFI style process: the above page tells
> you the requirements for error-set collection "conventions", have a set
> of gatekeepers, if any two agree a submission is ready, it goes.  I know
> from experience elsewhere that this sort of process can work for these
> sorts of artifacts, where the stakes are much lower than for e.g.
> SRFIs.

All of that sounds good to me. E.g. on the mailing list:

Person A: "I sent a PR to add error set identifier 'libfoo. Is this OK?"
Person B: "Looks good to me. Merged."

> For example, there's no reason I can think of to limit an
> error-set to just one "best" convention.

What do you mean by this?

Ideally each error-set would have the same mnemonic error symbols in
each Scheme implementation so that portable code can be written. In
particular, the Windows API has error codes like this:

* ERROR_ACCESS_DENIED
* ERROR_ACPI_ERROR
* ERROR_ALREADY_INITIALIZED
* ...

And SQLite has error codes like this:

* SQLITE_CORRUPT_VTAB
* SQLITE_IOERR_AUTH
* SQLITE_READONLY_ROLLBACK

So all error mnemonics in those sets have the same prefix (in WinAPI,
"ERROR_" and in SQLite, "SQLITE_"). The error set registry should say
whether that prefix is kept in the Scheme-side symbols or omitted from them.

> Have a submission channel, a discussion forum (not email, because a list
> per submission would be crazy, and not everyone will be interested in
> every error-set; this is the biggest unknown I have), and maybe an
> announcement mailing list.

> But for the latter I'm thinking discovery
> might be better done more narrowly; at the extreme of the end user,
> he'll find out from libraries that uses SRFI 198 when he starts using them.

Indeed, ideally the registry works so well that most Scheme programmers
don't need to know about it at all; thanks to standardization, they will
have the same error sets with the same mnemonic identifiers everywhere
with no special effort.

In the same way that e.g. /etc/services is standardized across operating
systems so that typing "http://" anywhere will always lead to the same
TCP port number. IANA (Internet Assigned Numbers Authority,
<https://www.iana.org>) provides an example of how well this works --
they admin the port number and MIME type registries, for example.

(IANA is also a good example of how too heavyweight a process will be
circumvented. Their MIME type registry started off well but the
submission form is so daunting that few new MIME types are officially
registered anymore, even though new file types keep being invented all
the time.)

> Wild thought: the latter suggests REPL hooks to display errors in more
> useful ways.

That's a great idea. As noted, Common Lisp has a standard `print-object`
generic function for custom printers. Someone well versed in Scheme
printers should write a SRFI about something similar :-)

> Might as well use git for the database of them, since its multiple
> copies paradigm makes it easy to avoid complete dependence on a single
> site like GitHub.

Enthusiastically agreed. Programmers live around Git all day, so
anything Git-based will make it easy to send patches.

> But I'm still thinking about the details of that,
> include how good the fit is, organization of conventions, what their
> format should be, etc.

Storing the ground-truth information in simple S-expression files in Git
has worked very well in various Scheme repos. Scheme being as expressive
as it is, it's simple to write short scripts to munge that data into
different forms for display and post-processing as needed. Git diff is
nice enough for reviewing patches to S-expression data.

What I've done numerous times is to put the data in a foo.scm file, and
write a foo-gen.scm script next to it to read it in and generate various
outputs from it. Though some people said that .scm is not a good file
name extension for data files that are not executable Scheme code :-)