Three month spec freeze

[Andrew Singleton]

This kind of sork is like writing a book. It is always tempting to go back
and revize and edit because yu are never happy eith it.

As someone that is lookingto use this on api zero acting as a
tinkerboxservet? I am lookingforward to the serverand client software that
can be written jn this time now that the spec is at least momentarily in
place.

On Sun, Mar 1, 2020, 11:07 AM solderpunk <solderpunk at sdf.org> wrote:

> Greetings all,
>
> After today's change to the spec to introduce some new line types, I am
> announcing a three month spec freeze.  I am happy to make small changes
> to correct typos, fixing inconsistencies or reduce ambiguities (and I
> have no doubt the latest change intorduced some of these things).  But I
> will not make any substantive changes until June 1st 2020.  The reason
> for this, as previously stated, is that I think in general we are doing
> far too much "designing in a vacuum".
>
> Designing protocols in the abstract on a mailing list is fun, but there
> will *always* be reasonable arguments for adding just one more thing.
> We'll never be finished and we'll move ever further away from the ethos
> that people should be realistically able to write their own
> feature-complete Gemini software in a weekend or two.  I am strongly of
> the opinion that, now that we have defined something which is
> (hopefully!) manageably small and simple, we should build the best
> possible space we can within the limits that small and simple thing
> imposes, and then ask ourselves "are we content with this?".  Not
> "wouldn't it be nicer if we also had X?", because of course it would,
> but "if this really were it, forever, would using this be genuinely
> unpleasant?".
>
> At this point I would really like to consider making changes if and
> only if they fix actual real-world problems which we can point at that
> are affecting multiple non-hypothetical servers or users.  Right now
> there's just not enough stuff out there for this kind of "real world
> driven design" to happen, and until that changes I think our time is
> better used writing content than specs or code.
>
> Moving forward, I strongly advocate for a model something like:
>
> 1. INTERVAL = 3 months
> 2. Spend INTERVAL actually building Geminispace and associated tools,
>    with no major spec changes.
> 3. Ask "What is the *single* biggest problem/shortcoming of the current
>    spec, based on everything that has actually been done or been tried
>    in the past INTERVAL?"
> 4. Possibly (but not necessarily) change the spec to address the
>    answer to 3, if the problem is deemed bad enough and can be
>    addressed without adding too much extra complexity.
> 5. Set INTERVAL = 2*INTERVAL
> 6. GOTO 2, or END.
>
> This way the protocol solidifies pretty rapidly, and all our attention
> is focussed on demonstrable problems, which are tackled in order of
> severity.  This model strongly encourages solving most problems not
> through changes to the spec, which are precious rareties, but through
> extra layers of optional convention, e.g. defining well-known endpoints
> like robots.txt or sitemap.xml.  This, in turn, minimises breakage of
> existing tooling.
>
> So, let's spend most of our Gemini energy until June on creating
> content and tools!  In addition to finally starting some gemlogs, I
> still plan to prioritise the creation of an Atom-based aggregator to
> play the role of Bongusta for Geminispace.  This, I hope, will encourage
> content creation by making new content easily discoverable.  In
> Gopherspace, Bongusta and, before Bongusta existed, the SDF phlog
> listing played a strong role in easy content discovery.  Geminispace is
> still stuck with manually checking every known server every day to find
> infrequent updates, which is not something many people are going to want
> to do (even I quickly stopped doing it!).  This discourages writing
> content, due to the feeling that it will never be seen.  Fixing this is,
> I think, important.
>
> Cheers,
> Solderpunk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200301/0272bfc9/attachment.htm>