Objection to Archiving the Solid Spec

[melvincarvalho]

@timbl @johnbizguy there is a proposal in another repo, to archive this Solid Spec. This is really a short hand for saying to deprecate the Solid Spec.

solid/process#198

That would be a premature optimization

This repo includes all the work we did at MIT and predates inrupt and the subsequently created process. Some people may want to work that way. And that's great, it gives the project much needed momentum. But not everyone does. IMHO, it suits full time employees, but Solid also should be welcoming to people that are hobbyists, volunteers, work in their spare time and at weekends, or casual members of the JavaScript and other communities.

I would like to join @kidehen in voicing objection to the to the proposal on the following grounds:

1. The Solid Spec was the result of at least 5 years hard work, and was a team effort. It was a mix of academics and power users that used solid on a daily basis. That had great experience and iterated on tiny details. A team coming to it afterwards does not necessarily have the unilateral right to deprecate it

2. There are multiple server instances coded and working on solid specs up to and including 0.7 (Go, PHP, Node) some of which are still catching up to 0.7. Namely to introduce webid-oidc to gold and ldphp. That work should not be stopped

3. There are multiple apps targeted to 0.7 and they should be given breathing room to adapt

4. The main solid reference implementation, node-solid-server is targeted at 0.7

5. This repo has over 1000 stars, is very much part of the solid history, and solid story. It should provide a historical record of how the project evolved. And issues should not be unilaterally moved from one repo to another without consent.

More importantly the nature of trying to sell a new spec in a somewhat heavy handed way might not have the desired effect, and in some cases could have the opposite:

"The way the Web spread was a piece at a time. So you could take html without taking http. So the failure of NEXT was a lesson, don’t try to sell it all at one time. Sell each piece on its own merits. Never insist that everybody take all. They will take all the pieces once they see how it fits together." -- Tim Berners-Lee

Furthermore the work on "specification" is not complete.

I would invite close reading of the following architectural principles of design:

https://www.w3.org/DesignIssues/Principles.html

Also pay attention to Brian Carpenter's architectural principles

ftp://ftp.isi.edu/in-notes/rfc1958.txt

And perhaps most important: Nothing gets standardised until
there are multiple instances of running code.

AFAIK The newer work does not have multiple implementations that conform to it. It is more complex. It is less modular. There are question marks over backwards compatibility.

I propose that the bar for replacing one spec with another should be very high

• You are replacing like for like
• It is backwards compatible
• It has implementations of the new work
• It has unanimous consent and no informal or formal objections

Quite happy for the work on specification to go ahead. But it should not be at the detriment to existing work.

I back the proposal of @kidehen to let both repos exist in parallel. At least for now.

There should be a path for people that have spent a lot of time working up to 0.7, and that have working systems and running code, to continue that work, and fix bugs where necessary.

Given that, there would perhaps be benefit to be a bridge between the two works that can join them together. One group works on solid v.next. One group will fix the pain points on existing work on 0.7. This is something we experience in the community and work on regularly. Then maybe we could have a 0.8 that pulls in the consensus from the new work and applies it to what exists.

That may create a smooth upgrade path that everyone can live with

If there is a wish to deprecate this work it should be first endorsed by @timbl with an open discussion here. And ought to give guidance to those that have spent a lot of time working here, what to do next

Thanks for reading!

[RubenVerborgh]

I’m confused. In #220 (review) and many others, there were day-long discussions on how 0.7 cannot be changed. So what better guarantee than to archive this repository? Then 0.7 remains unchanged forever and there can never be any compatibility problems.

[kidehen]

I’m confused. In #220 (review) and many others, there were day-long discussions on how 0.7 cannot be changed. So what better guarantee than to archive this repository? Then 0.7 remains unchanged forever and there can never be any compatibility problems.

When you archive a repo are you not changing its nature? Leaving it as is amounts to not changing it, as far as I understand :)

[RubenVerborgh]

When you archive a repo are you not changing its nature?

We're discussing on two levels here 🙂

The repeated question has been to not touch the 0.7 draft spec in any way. Literally every time anyone tried to change something, even if they were bugs, it was a painful multi-day process for all involved.

Archiving the repository would not constitute any change to the specification, and in fact lock that specification for changes, which is exactly what has been demanded so many times before, in particular by @melvincarvalho.

In fact, every single of the 5 points listed above by Melvin is addressed by archiving. So I am very, very confused.

[kidehen]

When you archive a repo are you not changing its nature?

We're discussing on two levels here 🙂

The repeated question has been to not touch the 0.7 draft spec in any way. Literally every time anyone tried to change something, even if they were bugs, it was a painful multi-day process for all involved.

Archiving the repository would not constitute any change to the specification, and in fact lock that specification for changes, which is exactly what has been demanded so many times before, in particular by @melvincarvalho.

In fact, every single of the 5 points listed above by Melvin is addressed by archiving. So I am very, very confused.

To be specific, this is about not changing the nature of the repo that contains the draft spec. Changing the repo changes the dynamics for the project for dissenters. I think that's a clearer articulation of the issue at hand.

As I always suggest, let the "Wisdom of Solomon" prevail, always defer to keeping the baby alive :)

[RubenVerborgh]

Only thing I want to add here is, let's not make this proposal a religious issue.

We believe that people can do their work better if there is one repository were all issues arrive. It's clear that 0.7 cannot and will not evolve anymore, yet (mainly newer) people are confused and still post issues here. But those issues cannot be addressed, because every minor change here is a painful multi-day journey.

The main reason for archiving this repo is to direct people to the correct place https://github.com/solid/specification/

Archiving or not archiving does not change the nature of this repo: it's a draft that will not change (see Melvin's 5 points). New work happens in https://github.com/solid/specification/. That is already explained in the process and ratified by Tim as a Community Leader.

The only thing archiving achieves, is making sure that issues and discussion end up in the right place.

If we choose not to archive, the main thing we achieve is overhead for people creating issues and people working on the new spec.

In any case, archiving or not is just cosmetic, in the sense that people working on the spec text will not be contributing to solid/solid-spec anyway. This repo is de-facto archived, explicitly indicating it as such only makes things a little clearer. If you read the process, you can see that a next version of the spec will not arrive here; that has already been decided a long time ago.

Changing the repo changes the dynamics for the project for dissenters.

They are most welcome at https://github.com/solid/specification/, and in fact solid/process#198 explicitly demands showing them the way.

[RubenVerborgh]

In any case, @melvincarvalho, please close this issue here and continue the discussion with @timbl, @kidehen and others at solid/process#198. We don't need multiple issue for the exact same thing. I will transfer this issue to the appropriate place.

[RubenVerborgh]

Seriously, @melvincarvalho, can you stop doing that?
Process discussions belong in process, thank you.

There is an issue open at solid/process#198, please discuss it there.

[melvincarvalho]

This issue was raised in solid-spec as it refers to solid spec.

There are 156 people watching solid spec.

The moving of issues from solid spec was highlighted as disruptive to the history. This is part of the problem.

Admin privs to allow that have been removed to prevent this happening again. If that is agreed, they will be restored. Thanks much!

[RubenVerborgh]

Admin privs to allow that have been removed to prevent this happening again.

You are not allowed to remove anyone's admin privileges. I need them for my job.
Put them back.

[RubenVerborgh]

Melvin objects to the issue being moved; however, that doesn't change the fact that it is a duplicate of solid/process#198. All further discussion will happen there.

[melvincarvalho]

@RubenVerborgh Respectfully, I disagree with that this is a duplicate because it has a different audience. If there is an issue regarding archiving a repo. At a minimum it should be flagged in that repo, in case anyone wants to object. I only came across this by chance, as I do not follow the other repo. But I care alot about the solid spec.

156 people people are watching this repo and are those that are most likely to care about the fate of this work. The people in the other repo care about other things, meta issues. So, I think there's room for people that care about different things to weigh in. So, with your permission, I'd like to leave this open. If that's OK.