Proposal to archive solid/solid-spec

[csarven]

It appears to be that the solid/solid-spec repository still attracts enagement and causing confusion. In order to direct the energy to solid/specification and other relevant Solid repositories, I suggest to archive solid/solid-spec. Archiving the repository will continue to keep all information public while prohibits updates eg files, issues.

If agreed, how to proceed:

• Transfer useful issues to solid/specification or elsewhere.
• Update its README to indicate the freeze/archival.
• ?
• Archive

Including admins and editors for review so there is no oversight or surprises.

[dmitrizagidulin]

👍 agreed on all counts

[csarven]

Doesn't shut off entirely though. Header of the README needs to be simplified to guide the visitor to solid/specification.

The intention is not to have any issues in solid/solid-spec but to have it in solid/specification, so I'm not sure how a template would help with that other to say "stop. do it over there instead".

I still prefer archival. We don't need to dance around it anymore.

[justinwb]

I also agree that we should do this, though I'd like to make sure that we get the README text right before hitting the archive button to avoid any confusion.

[kidehen]

It appears to be that the solid/solid-spec repository still attracts enagement and causing confusion. In order to direct the energy to solid/specification and other relevant Solid repositories, I suggest to archive solid/solid-spec. Archiving the repository will continue to keep all information public while prohibits updates eg files, issues.

If agreed, how to proceed:

• Transfer useful issues to solid/specification or elsewhere.
• Update its README to indicate the freeze/archival.
• ?
• Archive

Including admins and editors for review so there is no oversight or surprises.

Situation:

We have two repos related to the same topic i.e., Solid Specs.

I would encourage leaving the "original draft" version of the spec as is while simply focusing on the new "official specification" going forward.

If the old spec generates traffic, so be it. There's no obligation to respond to issues and comments i.e., it can fade away if it has too or act as a natural reminder about various aspects of the project.

Conclusion:
Let the nature of a repo just take its course. Traffic will go wherever it needs to go, over time :)

Let's be as transparent as possible.

[csarven]

Beyond solid/solid-spec's historical role, there is no particular reason for it to receive any traffic. It is preferable to direct all energy towards solid/specification. Keeping solid/solid-spec active subtracts from the potential. It also sends the wrong message eg. a contributor may get the impression that the spec work is inactive, or worse, their input is not valued due to lack of attention. It has become a recurring cost that we can easily cut off.

[kidehen]

Beyond solid/solid-spec's historical role, there is no particular reason for it to receive any traffic. It is preferable to direct all energy towards solid/specification. Keeping solid/solid-spec active subtracts from the potential. It also sends the wrong message eg. a contributor may get the impression that the spec work is inactive, or worse, their input is not valued due to lack of attention. It has become a recurring cost that we can easily cut off.

The thing about community projects is that transparency has to be paramount, at all times.

If you don't have an obligation to act on an issue in the specs repo, it won't you cost anything in terms of time etc. In addition, anyone could courteously point an issue placed in the spec repo to the specifications repo etc..

Fundamentally, I advice transparency and caution when dealing with community projects. These issues aren't easy due to the fundamental nature of individuality i.e., one person can never really speak effectively for a community of individuals endowed with a cocktail of intentions :)

[csarven]

Archiving merely turns the repository into read-only. We are having this discussion in the open with exact steps outlined. Is there a particular criteria that you're thinking of that's not met in the proposal or how we are approaching it?

Even if I/we don't respond to an issue in solid/solid-spec, it costs me/us. That's input we'd rather have in solid/specification than not have. In the event someone responds, that's two additional steps; redirecting and re-creating issue. Three steps we can do without.

I'm all with you on transparency but I don't understand - and really I want to! - how leaving the old repo as is maintains transparency or how archiving it possibly goes against transparency.

[akuckartz]

There are quite a few open issues in solid/solid-spec

What should happen with them?

[csarven]

@akuckartz , as I've mentioned in the proposal:

If agreed, how to proceed:

• Transfer useful issues to solid/specification or elsewhere.

[kidehen]

Archiving merely turns the repository into read-only. We are having this discussion in the open with exact steps outlined. Is there a particular criteria that you're thinking of that's not met in the proposal or how we are approaching it?

My concern is about the consensus protocol. How many consenters or dissenters determine the final outcome here?

[kidehen]

Even if I/we don't respond to an issue in solid/solid-spec, it costs me/us. That's input we'd rather have in solid/specification than not have. In the event someone responds, that's two additional steps; redirecting and re-creating issue. Three steps we can do without.

How does it cost you?
Who do you refer to when using the term "us" ?

Note, I am speaking from the perspective of the Solid Project as a Community effort and its natural evolution over time.

You shouldn't be maintaining two specs. And I am not asking you to do that. I am suggesting you maintain one spec (i.e., the current version) while leaving the draft variant to its own destiny, so to speak.

[kidehen]

I'm all with you on transparency but I don't understand - and really I want to! - how leaving the old repo as is maintains transparency or how archiving it possibly goes against transparency.

If you archive the original draft spec you are sort of closing it down. What happens to those who may interpret such actions differently, based on their world views?

When I refer to "transparency" it is always about removing any cause for misinterpretation in a composite world of individuals. This is why the consensus protocol and what it means to the community at large needs to be crystal clear.

I hope I've clarified my position a little better? If not, you can ask on :)

[timbl]

I suggest yes for each issue in solid/spec either create a carried over on in solid/specification, or declare that it has been overtaken by events, either made irrelevant, or met, by the move itself, etc.

Yes and make it very clear the action has moved to solid/specification in the README and readers should follow it there.

[kidehen]

It appears to be that the solid/solid-spec repository still attracts enagement and causing confusion. In order to direct the energy to solid/specification and other relevant Solid repositories, I suggest to archive solid/solid-spec. Archiving the repository will continue to keep all information public while prohibits updates eg files, issues.

Okay, but can't you see that prohibition of updates (e.g., files and issues) is the issue of dissent right now.

How do these issues get resolved in a transparent manner, bearing in mind the composite nature of the community?

Actions should never be taken that some might perceive as a select minority dictating to the majority. This is basically what I mean by transparency. None of us have control over the minds of other individuals and their world-views, which is why I personally suggest erring on the side of caution by being as flexible as possible i.e, don't kill the baby as per "Wisdom of Solomon" analogy.

The old repo isn't a perceived inconvenience to some. For instance, It is actually seen as a point of important historic reconciliation. Thus, why MUST the repo be archived bearing in mind these conflicting sentiments?

This issues are hard, but we shouldn't let them inflict damage on the broader project.

Let's try our best to see things both ways, for the greater good etc..

[dmitrizagidulin]

Like @RubenVerborgh, I am baffled by this argument.

Archiving the repo does not erase the historic reconciliation. All the issues are still there.
It is absolutely unacceptable to continue causing confusion for new developers, by presenting two similarly-named spec repos.

[kidehen]

Archiving the repo does not erase the historic reconciliation. All the issues are still there.
It is absolutely unacceptable to continue causing confusion for new developers, by presenting two similarly-named spec repos.

Put differently, repo archiving "prohibits updates eg files, issue" . That's the issue that has triggered dissent.

If folks can no longer post issues or generally discuss items associated with their preferred repo-of-reference it could be perceived as "silencing their voice" and blurring historic reconciliation.

I hope the fundamental issue here is clear i.e., "prohibiting updates eg files, issues" regarding the draft repo is the focal point of dissent.

If that doesn't work for a segment of the community it shouldn't be imposed by what may be perceived as a select few.

This is why I continue to refer to the "wisdom of Solomon" anecdote i.e., keep the baby alive, above all else. We don't need a fragmented community since everyone loses when that happens.

[akuckartz]

In any case, we want to make a big note in the solid/spec README about where to find what.

👍

Let's use that PR as an example to see how hard it is to get things done in that repo.

👍

[csarven]

I consider this discourse in response to a proposal that is publicly accessible to be transparent communication.

solid/solid-spec and solid/specification are both under the same organisation and community that follows the Solid process to its best abilities and intentions. We are all part of the Solid community.

I originally wanted to stop new issues from opening and preferred to keep existing issues open and visible. GitHub only allows turning issues off from view. Archiving seemed liked the next best option. It also reduces energy and information fragmentation.

[kidehen]

I originally wanted to stop new issues from opening and preferred to keep existing issues open and visible.

Yes, that was your intention. The problem is that in a community project of this nature those intentions could lead to unintended effects (in the worldview of others), hence the need to play as safely as possible.

As I've said, these issues are complex due to the fundamental nature of both individuality and community. Moving a diverse community in concert is hard++

[elf-pavlik]

IMO if repo is not meant to accept Pull Requests it better stays archived. When it comes to issues, moderators can transfer what they find relevant to new repository. We could also have 'solid-spec migration requests' ongoing issue in new repository, and we would comment in all the issues in old repository that one can request transfer of issue in that dedicated issue.

[kidehen]

The thing about community projects is that transparency has to be paramount, at all times.

I think I should have qualified my point a little better i.e., I should have said "transparency and flexibility" have to be paramount.

@csarven has been transparent i.e., his actions and intentions are in public view. Thus, in his case, I am requesting additional flexibility to complement demonstrated transparency re my "Wisdom of Solomon" anecdote :)

[dmitrizagidulin]

I strongly believe that explicitly archiving the solid-spec repository is the clearest implementation of what @timbl said:

Yes and make it very clear the action has moved to solid/specification in the README and readers should follow it there.

The 0.7 spec is frozen, per the request of the very part of the community that is currently fighting against archiving. No more alterations to it are possible. Continuing to confuse developers by having two seemingly-conflicted spec repositories, is irresponsible.

Why are we still arguing about this?

[kidehen]

Why are we still arguing about this?

Because this is a community that is composite in nature i.e., a collection of individuals. People regularly perceive the same thing differently, so a little bit of transparency and flexibility goes a long way to preserving harmony.

We are all in this together, so protecting the community by seeking harmony should always be paramount, IMHO.

This is much easier said than done, as I've alluded to repeatedly.