solid-spec
solid-spec copied to clipboard
solid
Objection to Archiving the Solid Spec
@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.
https://github.com/solid/process/issues/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:
-
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
-
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
-
There are multiple apps targeted to 0.7 and they should be given breathing room to adapt
-
The main solid reference implementation, node-solid-server is targeted at 0.7
-
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!
I’m confused. In https://github.com/solid/solid-spec/pull/220#pullrequestreview-389804068 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.
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 :)
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.
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 :)
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 https://github.com/solid/process/issues/198 explicitly demands showing them the way.
In any case, @melvincarvalho, please close this issue here and continue the discussion with @timbl, @kidehen and others at https://github.com/solid/process/issues/198. We don't need multiple issue for the exact same thing. I will transfer this issue to the appropriate place.
Seriously, @melvincarvalho, can you stop doing that? Process discussions belong in process, thank you.
There is an issue open at https://github.com/solid/process/issues/198, please discuss it there.
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!
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.
Melvin objects to the issue being moved; however, that doesn't change the fact that it is a duplicate of https://github.com/solid/process/issues/198. All further discussion will happen there.
@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.
156 people people are watching this repo
After the 20 notification e-mails those 156 people have received of this thread, I trust they know how to find their way to https://github.com/solid/process/issues/198.
Assigning to you; please resolve in a way that benefits the community.
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.
hi @RubenVerborgh thanks for looking at this. What I actuatlly asked for was to freeze the pointer to 0.7.0 so that it's unambiguous. And that's exactly what you did. ie by bumping the version. Thanks again for that, that satisfied my concerns.
The freezing of a repo is a slightly different issue. I hope I was clear in my OP why I think the timing of a repo freeze would not be ideal.
Having reviewed the concerns in the other repository:
The solution that I find most attractive so far, is that of @RubenVerborgh :
https://github.com/solid/process/issues/198#issuecomment-624064887
"another option might be to have issue templates that force people to make choices before they submit anything."
An issue template seems to be a solution that would
- avoid archiving the repo (+1)
- guide newcomers to work in the right place (+1)
- limit or avoid potential confusion (+1)
I can have a go at writing some text for this and see if it can help address concerns incorporating @timbl 's comment.
What I think the gist of what is wanted is: that newer work goes to specification but existing work, for support and maintenance can continue here. We still have production problems that bubble up to spec level, and it would be easier to triage here.
Perhaps a better solution will emerge. But working on an issue template seems a path to progress, right now. So, I'll work on some text.
As an outsider currently in the process of creating a Solid Server in PHP (as part of @pdsinterop) , the only reason I noticed this issue at all is that I was curious about the issues and MRs a project such as this receives.
If @melvincarvalho had not opened this issue here, I would have no way of knowing solid/process#198 even existed!
I can see the need/value to keep the discussion about this topic in one place but I think having the information that the discussion is taking place should be available in all relevant repos (like this one).
If whatever is written in this repo is behind/out of date/headed for deprecation/whatever, it would be good to change the leading text in the README file as it currently says:
For the time being, the present document contains the best approximation of expected server and client behavior.
Regardless of any opinion I might have about whether this repo should be archived or not, I have to say, I am somewhat taken aback by the tone and content in (response to) this issue... It makes it sounds like there is a lot of politics going on behind the scenes, which really makes me reconsider how much I would want to get involved with the "specs" side of things.
