Complaints ahead.

Le mer. 10 juil. 2019 à 23:54, Lassi Kortela <xxxxxx@lassi.io> a écrit :
Since all of us have lots of ideas and it's a big open-ended topic, how
should we proceed with making websites for Scheme?

I think we should first and for most define the mission of the schemedoc effort.

The srfi website claims the following:

> collecting, organizing, and serving indexes of Scheme code found in SRFIs, Scheme implementations, RnRS standards, etc.

Is the above mission statement taken from the SRFI website still valid?

From recent discussion, it seems much more than that. Since it includes
at least getting together a cookbook, I proposed a search engine too.
we started the awesome-scheme repository.
I think that is all, I take the blame for opening the pandora box about
something more akin to a community website even peer-to-peer stuff...
 
I regret that the only approach I can do is basically to follow
instincts. The approach is difficult to communicate or sounds
pretentious and alienating, and I don't want to reduce anyone's
excitement and productivity.

Ok.
 
Yesterday I also wrote a long reply to Amirouche's mail on the website
content, which was inspiring, but got so tired from working so much
recently and perfectionistic that it's still in drafts folder :| I'm
sorry to not reply in a timely manner.

No worries, you can still send it, privately if you prefer, please.
 

If you want to make websites in a more traditional way, I can let you
design them and focus just on coding myself, or alternatively we could
make more than one site, then compare and keep changing them.

That's the thing that I would like to avoid. There is a lot of competition
already in Scheme community between implementations and sadly
also between people.

If we can agree on something, our proposal will have more strength.

 
In the end, we can choose one to be the "official" site (or combine them
somehow if it makes sense). The other sites can still continue to exist.

I don't want to disjoint efforts. I have done too much of that already.
 
IMHO the most important thing is that we share the common API.

By the way, I think that running biwascheme in nodejs to expose a
graphql endpoint is not a good idea: a) biwascheme is basically a toy
until JS VM implement tail-call-optimisation, which is not happening any
time soon. b) graphql will slow down the overall progress because we
need to understand how it works and same for people that would like
to consume the API. Since there is no existing library, it is far from easy
to get started. c) running nodejs doesn't deserve an explanation why it is
a bad idea. It will send a bad signal to the users. SchemeDoc should
promote Scheme, preferably scheme that actively support Scheme.

Obviously I would prefer to continue to work on Arew Scheme and continue
to work in Chibi Scheme.
 
That way there is less risk in experimenting with new kinds of sites (since if a
design doesn't work out, at least the data is still available). In fact,
the API will probably improve faster if it needs to support different
kinds of sites.

In another mail I did not send (!) I was arguing that requiring a backend software
would be difficult to maintain. So, the idea that popped is to use git to store the data
and build a new version of the website when it is merged in master. This makes
contribution from developers easy (they just need git and an editor), it is easy to
maintain, it is fail-safe in the sens that the schemedoc or the server disappear
there will be copies around that will be able to re-launch the project.

It might seem dull to rely on git, but we can be creative in this regard and
store more than simple markdown files and instead rely on s-expr to represent
more complex data, like scheme metadata repo does.

What do you think?

I think we should define the mission of the website:

According to (first paragraph) wikipedia page about mission statement,
we should have a few key points explained out:
  • Key market: the target audience
  • Contribution: the product or service
  • Distinction: what makes the product unique or why the audience should buy [or use] it over another
https://en.wikipedia.org/wiki/Mission_statement

I have plenty of time and I want to invest it correctly.

--
Amirouche ~ amz3 ~ https://hyper.dev