Email list hosting service & mailing list manager

Scheme.org: Protecting Scheme's name for the next 20 years Lassi Kortela (22 Nov 2020 21:54 UTC)
Re: Scheme.org: Protecting Scheme's name for the next 20 years Amirouche Boubekki (24 Nov 2020 16:37 UTC)
Re: Scheme.org: Protecting Scheme's name for the next 20 years Marc Nieper-Wißkirchen (01 Dec 2020 18:39 UTC)
Who owns Scheme? Lassi Kortela (01 Dec 2020 17:33 UTC)
Re: Who owns Scheme? John Cowan (26 Dec 2020 05:49 UTC)
Re: Scheme.org: Protecting Scheme's name for the next 20 years Arthur A. Gleckler (01 Dec 2020 18:45 UTC)
Re: Scheme.org: Protecting Scheme's name for the next 20 years Amirouche Boubekki (24 Dec 2020 16:59 UTC)

Re: Scheme.org: Protecting Scheme's name for the next 20 years Amirouche Boubekki 24 Nov 2020 09:45 UTC

Hello,

That is a great idea! Thanks for working on this.

Will the scheme.org domain work like https://js.org/ ?

Le dim. 22 nov. 2020 à 22:54, Lassi Kortela <xxxxxx@lassi.io> a écrit :
>
> Welcome to the mailing list for the Scheme.org domain name.
>
>
> First, some fundamentals. The registrant on file for Scheme.org is
> Magnus Ahltorp from Sweden. The administrative and technical contact
> is Arthur Gleckler (known to Schemers as the current SRFI editor). The
> previous admin and tech contact was Shriram Krishnamurthi (known for
> running Schemers.org among many other contributions). Shriram was
> happy to hand over Scheme.org to people who have time to develop to
> it, and would like to phase out Schemers.org in favor of Scheme.org
> once the latter has been properly established. Magnus is also happy to
> be hands-off but would like to retain ownership of the domain to
> ensure that it stays non-commercial and does not track the behavior of
> visitors. Magnus has kindly pre-paid the domain until 2029. The domain
> registrar and DNS provider is Gandi.net.
>
>
> On to the plans: The essay below is an attempt to lay out a particular
> vision for Scheme.org. It has been hashed out by me and Arthur with
> input from a handful of other Schemers. It advocates for an unusual
> approach because Scheme is governed differently from most programming
> languages. It is long and detailed; please bear with it, think about
> it for a while, and tell us what you think on this list so we can get
> a conversation started. Going forward, we want the administration of
> Scheme.org to happen entirely in public so that everyone is clear on
> where things stand with this important domain.
>
>
> The title of this essay is chosen to make a particular point.
>
> As programmers, we are used to fast-moving projects, changing plans
> and informal customs. Getting software written at all is so hard that
> we have little patience for elaborate social protocol.
>
> We believe Scheme.org should be viewed as a fundamentally different
> kind of project: a conservative one that prioritizes preservation and
> planning even when that makes new development more difficult.
>
> Scheme is not a new language. It comes with almost half a century of
> history. It has a well established reputation, now guarded by us.
>
> Scheme's continuity rests on a loosely organized network of volunteers
> who come and go. While this is wonderful, the risk of key people going
> out of reach is ever with us. We must take care not to jeopardize the
> continued availability, maintenance and development of our resources.
>
> Schemers are known to prize independent thought, sometimes to a fault.
> Our most notable disagreement was the R6RS vs R7RS split. We should
> take care to preserve neutral ground at the center of Scheme so that
> adherents of different sub-communities can continue to work together
> on shared interests even during times when there is widespread
> disagreement over the future direction of Scheme. Likewise, we should
> take care that no particular sub-community can alter the public image
> of Scheme to the detriment of others.
>
> Finally, we should protect the Scheme community from being co-opted by
> commercial, academic or political interests for their own purposes.
>
> All of the above concerns are fundamentally tied to the name itself:
> Scheme. Whoever owns the name holds significant power over the public
> image of the language and the ability of people to organize around it.
> That is fine for languages headed by a definite person or group, but
> Scheme has no owner. The closest thing we have is the Scheme Steering
> Committee. They ratify the RnRS reports but are far too busy to tend
> to the day-to-day matters of the language and its community. Running
> the language community thus falls on its most avid users. That is us.
>
> As the internet domain most obviously linked to Scheme's name,
> Scheme.org is the one entity best placed to represent Scheme in the
> world. With Scheme.org now in friendly hands, we should take this
> opportunity to gather around it, make it the best we can, and do our
> best to ensure it carries on to the next generation of Schemers.
>
>
> Why think about the next 20 years? A lot can happen in a couple of
> decades, and it's not guaranteed that any of us will still be involved
> with Scheme after so much time. Setting our sights that far into the
> future forces us to design a social and technical structure to outlast
> ourselves. We can start with a template and gradually refine it. If we
> do this right, the rate of change will slow down over time and the
> community will increasingly trust in the stability of the structure.
>
> Since humans are bad at predicting the future, the most likely success
> formula is extreme simplicity in the core processes:
>
> - We cannot have any rules that are hard to interpret since we may not
>    be around in the future to give advice about them. Rules, procedures
>    and responsibilities need to be simple and straightforward.
>
> - We have to codify all knowledge in either code or written documents.
>    We can't rely on word-of-mouth and knowing people who know things.
>
> - We have to take maintainer fatigue into account. Scheme.org needs to
>    have an administrator at all times, and it's a lot easier to get
>    someone to commit to a job when it's easy and doesn't take much
>    time. We can't have routine procedures that take a lot of effort.
>    Likewise, training a new administrator has to be quick and easy.
>
> - Scheme.org is predicated on the idea that Scheme, the DNS (Domain
>    Name System) and the WWW will still be around 20 years from now.
>    However, it's difficult to say what other tools will be popular. We
>    should favor simple, well-known and platform-neutral tools without
>    elaborate dependencies.
>
> Moving further away from the core of Scheme.org, the stakes are lower
> and we can be more relaxed. But as with the Scheme language itself, we
> should put a great deal of thought and care into a core that will
> stand the test of time.
>
>
> On the technology front, we believe one trick in particular holds the
> key to success: subdomains. The internet is naturally divided by DNS
> delegation. This exactly mirrors a desirable governing structure for
> Scheme.org: The root Scheme.org and its web front page should be
> simple, conservative, and closely guarded -- like a constitution. Less
> critical subdomains can afford to be more free-wheeling and
> experimental about both their technical and social aspects.
>
> Subdomains are simple to add and cost no extra money. They are a
> convenient unit of division to work with in various networking,
> security, and sysadmin contexts. We can freely make lots of them:
>
> * r5rs.scheme.org
> * r6rs.scheme.org
> * r7rs.scheme.org
> * srfi.scheme.org (should move late -- will be a big ordeal)
> * docs.scheme.org
> * pkgs.scheme.org
> * lists.scheme.org
> * files.scheme.org
> * registry.scheme.org
> * fantastic.scheme.org (your adventurous Scheme implementation here)
> * ...
>
> It's important to note that we could have as many as 50 subdomains and
> the site would still be navigable. The front page can group them into
> categories, with a short explanation next to each subdomain.
>
> There would naturally be two kinds of subdomains:
>
> * Those owned by a particular group based around a given standard,
>    implementation, or tool. Each subdomain of this kind should be
>    controlled by the group in question.
>
> * Those that are community-owned resources about a particular topic,
>    similar to the new Scheme Topics mailing lists at srfi.schemers.org
>    and our many GitHub organizations. They should operate by consensus,
>    with decision making on a public forum such as a mailing list, and
>    with the top level Scheme.org administrators acting as last-resort
>    tie breakers for any disputes.
>
> Each subdomain should be responsible for setting up and maintaining
> its own servers. The top level Scheme.org administration should only
> be tasked with updating DNS records as requested, and with maintenance
> of the Scheme.org front page. Delegating all other responsibilities to
> subdomain admins will naturally ensure the fault tolerance of
> Scheme.org as a whole and enable a light workload for the people
> committed to be the top level administrators.
>
>
> One important angle missing from the above treatment is the legal one.
> No amount of goodwill or technical savvy can help us if we are no
> longer the registered owner of Scheme.org. Scheme is a common English
> word, and Scheme.org could be sold for upwards of 10k USD if someone
> was either greedy or desperate for money. It could also be taken over
> by an organization incompatible with our goals.
>
> To that end, a few of us have pondered whether it might be a good idea
> to set up a formal non-profit association to act as the legal owner of
> Scheme.org and any other important internet properties related to
> Scheme that people wish to donate to it. We may not have anyone in the
> Scheme community who is excited about the paperwork involved, but the
> stakes are high enough that if the cost is not prohibitive this step
> is worth taking anyway.
>
> Ideally Scheme.org would become so reliable that Scheme implementors
> could feel as comfortable hosting their implementation's primary
> website at fantastic.scheme.org as they would at their own separate
> domain fantastic-scheme.org. There would be nothing like gathering
> implementations under the umbrella of Scheme.org to signal the
> cohesion and organization of the Scheme community to outsiders -- a
> level of cohesion that is probably unmatched by any other significant
> language. But authors hold their implementations dear, and major ones
> will not take such a drastic step without a deep trust in the social
> and legal basis of Scheme.org. If we work hard at building that trust
> for a number of years, this may eventually be our ultimate prize. But
> even without such an accomplishment, every extra resource we add under
> Scheme.org builds the reputation of Scheme as a collaborative
> community and provides direct benefit to users who can thus more
> easily find their way around Scheme.
>
> If you're interested in helping us bring Scheme.org and its subdomains
> to life, please join this discussion. We're looking for volunteers to
> create and maintain Scheme.org and interesting and useful subdomains,
> and to help us figure out the process for organizing this effort for
> the long haul.

--
Amirouche ~ https://hyper.dev