Re: Writing v1.0 of the Solid specification

Yup. I agree this is a constructive way of going forward.

I’ll start looking at contributing to this over the next few days.

Thanks Ruben.

> On 15 May 2019, at 2.09, Sina Bahram <sina@sinabahram.com> wrote:
> 
> +1 to both of those suggestions and the original ones.
> 
> I'll try my best to contribute, even if it's asynchronously reading and asking questions, etc., but I'm very much in favor of this and think it will help move the entire project forward.
> 
> President, Prime Access Consulting, Inc.
> Phone: 919-345-3832
> https://www.PAC.bz
> Twitter: @SinaBahram
> Personal Website: https://www.sinabahram.com
> 
> -----Original Message-----
> From: elf-pavlik@hackers4peace.net <elf-pavlik@hackers4peace.net> 
> Sent: Tuesday, May 14, 2019 7:05 PM
> To: Ruben Verborgh <ruben.verborgh@ugent.be>
> Cc: public-solid <public-solid@w3.org>
> Subject: Re: Writing v1.0 of the Solid specification
> 
> +1 overall
> +1 to Ruben as one of the editors if he would like to take that 
> responsibility
> 
> 
>> On 2019-05-14 17:12, Ruben Verborgh wrote:
>> Dear all,
>> 
>> The current specification for Solid is located at
>> https://github.com/solid/solid-spec/.
>> There are a couple of issues with this version:
>> 
>> – It is a loose set of markdown documents, not a single, authoritative
>> looking spec.
>> 
>> – These documents are out of sync with reality:
>>  – Some features that are described, are purposely not implemented.
>>  – Some features that are purposely implemented, are not described.
>>  – Some features are purposely implemented differently than the spec
>> prescribes.
>> 
>> – The documents leave ambiguity in many places,
>>   meaning that they are insufficient to implement Solid.
>> 
>> – Not everything in these documents has gone through a decision 
>> process:
>>  – Some features might be undesirable as basic requirements of Solid,
>>     for instance, for computational reasons.
>>  – Some decisions were taken pragmatically some time ago,
>>     but do not necessarily reflect how we want to continue.
>> 
>> 
>> The reasons above should show that there is a need
>> to arrive at a consistent Solid specification.
>> 
>> 
>> My proposal for this is to start a new document for v1.0
>> that follows the W3C specification template,
>> and to use GitHub’s pull request mechanism
>> to add curated sections of content to it.
>> 
>> As a follow-up on https://github.com/solid/solid-spec/issues/170,
>> I have currently created the repository
>> at https://github.com/solid/specification/commits/gh-pages
>> with a live version at https://solid.github.io/specification/.
>> 
>> These curated sections would come from the current spec documents,
>> but they would be rewritten to be accurate and unambiguous,
>> and people in the community should be given the opportunity
>> to comment on texts that get into the spec.
>> 
>> This process will require processes for moving forward:
>> https://github.com/solid/specification/issues/1
>> and likely 2–3 spec editors
>> (in addition to all of the past and current spec authors):
>> https://github.com/solid/specification/issues/2
>> 
>> I have also proposed this as a discussion topic for the next meeting:
>> https://www.w3.org/community/solid/wiki/Meetings#20190516_1000CEST
>> 
>> As always, feedback most welcome.
>> 
>> Best,
>> 
>> Ruben
> 
> 

Received on Wednesday, 15 May 2019 01:37:19 UTC