Assign editors to this specification

[RubenVerborgh]

No description provided.

[RubenVerborgh]

I am a candidate to be an editor of the spec.

[justinwb]

I am a candidate to be an editor of the spec.

[Mitzi-Laszlo]

What is a spec editor? How do they apply? How are they assigned to the role?

The current decision making process proposal describes the Solid Team as spec editors. Please feel free to make suggestions on improving this.

My proposal would be to keep this issue to spec authors who would be part of a Solid Spec v1 team associated to a Solid Spec v1 project with the project manager as Ruben (if he agrees) and project aim = "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.". Project author candidates would be approved by the Solid Team. Spec authors would be responsible for submitting suggestions on the rewrite which would ultimately be approved or disapproved by the spec editors i.e. the Solid team.

[Mitzi-Laszlo]

I am a candidate to be an editor of the spec, also.

[HelloFillip]

@Mitzi-Laszlo That makes sense for the most part. There's currently not a list of external contributors (experts) who would also form part of the team. Implementors outside of the original Solid Team should also be able to take on the role of spec editors as long as they qualify as experts. I'm not sure how to qualify though.

I'd be willing to be a spec editor, but I simply don't qualify under the current proposal. That doesn't restrict me from making a contribution though.

[michielbdejong]

I think it's better if I'm not a spec editor, because I'm already involved in inrupt's pod-server implementation, node-solid-server maintenance, as well as the solid test-suite, so I think that's enough concentration of roles already for me as a single person. Also, I know of myself that I tend to get carried away by discussions, and it often ends up a productivity drain for me, so I think the prospect of not being a spec editor could actually feel kind of liberating for me! :)

[michielbdejong]

I also think @timbl should be the main author, mentioned first, and then mention the other people who work on the document text and the consensus process that produces it.

[kjetilk]

As a member of the Solid Team, I can also be a spec editor.

[Mitzi-Laszlo]

@Sliime great that you want to contribute, there's plenty of work to do :) The current proposal is certainly not intended to restrict contributions, there's far too much work to start doing that. Is there a specific element of the task that you would prefer to do?

Just to give a quick overview of previous conversations related to this topic for everyone to make sure we're all up to speed and on the same page. Ruben opened a pull request where anyone could list their name as long as there was at least one pull request or issue to the Solid spec related to that person. This is how 'contributors' was born. Also, there was also a point raised in the W3C Solid Community Group call about listing the editors and authors at the start of the readme of the three spec repos. They can be found here:
solid/solid-spec#155
solid/web-access-control-spec#42
solid/webid-oidc-spec#17

It's important that we define exactly what an editor/ author/ contributor is responsible for before starting the rewrite so that we know how to resolve differences of opinion both between multiple editors as well as between the editors and contributors etc.

The first step that needs to be taken is that one person or a group of people will need to write all the information from the existing three spec repositories and create the first draft of v.1 using the template in GitHub.com/solid/specification.

Once the first draft is ready, there will be suggestions in the form of pull requests and issues. Anyone can submit these as long as they have a GitHub account and the process of how to handle these is explained in solid-contrib/information#138. In short, the Solid Team would run votes on each suggestion in which the Solid Decision Panel can vote.

I propose that the Solid team are listed as an editors and editors would be responsible for executing the defined decision making process . @timbl is the main editor as Solid Leader and therefore has a unique veto.

I propose anyone who submits a pull request that is merged into the Solid spec is listed as an author. Additionally, the individual or group who write the first draft would also be listed as an 'author'.

The open undefined process is around the first step i.e. write all the information from the existing three spec repositories and create the first draft of v.1. The benefit of this being a single person is that they will have overview and we don't run the risk of differences of opinion. I would suggest @RubenVerborgh as this person.

If we have a group working on this, I would highly encourage a conversation about how this group should work. If it's the Solid team, there are defined decision making process for working together and dealing with differences.

One option would be to have a Solid project (see: Soild Specification v1 project on https://github.com/orgs/solid/projects) with a dedicated team that anyone could join with the aim of creating the draft. The Solid project could be led by the Solid Team meaning difference of opinion would be resolved by the Solid Team.

Agreeing on the processes does not mean that the operations have to change rather that the processes to resolving inevitable differences of opinion are clearly defined and legitimate.

[RubenVerborgh]

It's important that we define exactly what an editor/ author/ contributor is responsible for before starting the rewrite so that we know how to resolve differences of opinion both between multiple editors as well as between the editors and contributors etc.

Would be good to check if W3C has definitions. I have a "feeling" about what this is from earlier experience, but not more than that.

I propose that the Solid team are listed as an editors and editors would be responsible for executing the defined decision making process . @timbl is the main editor as Solid Leader and therefore has a unique veto.

Let's not have too many people though. 2–3 concrete editors are fine; there will be plenty of documents to edit in the future.

I propose anyone who submits a pull request that is merged into the Solid spec is listed as an author. Additionally, the individual or group who write the first draft would also be listed as an 'author'.

Not opposed, but that is not usually how it works within W3C.
Contributions have to be sufficiently substantial to be explicitly listed as an author; there is a placeholder for a link to "other contributors", which could be a document.

I've been in academia too long to care about exactly how authorship is determined, but we do want to avoid opportunistic authorship, i.e., people whose primary intention is to be listed on a document to be a co-author with certain others. I of course welcome all contributions, but writership is different from authorship, in the sense that authorship would also assume a technical contribution. Boundaries are very hard to define though.

And we should not forget about the people who have written the first draft of the spec (current v0.7). Even if they cannot contribute anymore now, their contributions have been crucial and should be acknowledged as such.

The open undefined process is around the first step i.e. write all the information from the existing three spec repositories and create the first draft of v.1. The benefit of this being a single person is that they will have overview and we don't run the risk of differences of opinion. I would suggest @RubenVerborgh as this person.

I would indeed suggest to let someone experienced write a first section, as an example. Happy to take up that role, to for instance create an outline and write a first section. This will give an indication of the required level of technical depth, in order to kickstart further contributions.

[Mitzi-Laszlo]

Do you have links to preferred W3C processes? The Community Group process is quite flexible. Perhaps you also are thinking about W3C Working Group processes?

The reason I'm bringing the process up is not to make it unwieldy, or change the daily operations, rather to give the process and the people doing the work legitimacy. Also, to set expectations and to make us more efficient as a team, it would be helpful to define where who can contribute usefully and how to expect their contributions to be handled.

[RubenVerborgh]

Do you have links to preferred W3C processes? The Community Group process is quite flexible. Perhaps you also are thinking about W3C Working Group processes?

Indeed, my experience comes from Working Groups—which we are not.

CGs are more flexible, importantly because no consensus is required.
It's always a trade-off between making progress at a steady pace, and negotiating everyone's concerns.

rather to give the process and the people doing the work legitimacy.

Perfect.

it would be helpful to define where who can contribute usefully and how to expect their contributions to be handled.

Specifically for editors of the technical spec, I am looking for people with sufficient technical knowledge to understand all details (at the level of things like HTTP headers), with a solid knowledge of Solid, with clear writing skills, and preferably with some experience with specs.

I myself have no strong opinion on how the process should be organized, as long as we indeed have the legitimacy and are able to make steady progress.

[HelloFillip]

I believe this is a good way forward @Mitzi-Laszlo.

Specifically for editors of the technical spec, I am looking for people with sufficient technical knowledge to understand all details (at the level of things like HTTP headers), with a solid knowledge of Solid, with clear writing skills, and preferably with some experience with specs.

I also agree @RubenVerborgh. I'm working on low-level (systems) components for distributed & decentralised standards already, rather than the Node.js components. I think that in itself is a critical difference to the majority of technical contributions.

I legitimately feel there's a bias towards seeing the world from a JavaScript-oriented perspective (unsurprisingly considering it's the language of the Web), but languages like Go, Rust, and Swift are going to be instrumental in developing distributed services for the Web and that's where my focus is. Much lower-level, much more commoditised.

I'm also looking outside of SOLID, at complementary projects like DAT (where work to migrate components from Node.js to Rust are also of interest), the Swift core library (where I'm intending to add support to SOLID-based protocols whilst supporting existing HTTP-level improvements), and I'm heavily involved in real commercial use-cases for large industry leading companies who are still driving focus towards blockchain or DLT solutions where distributed apps built on SOLID-like standards would be much more suitable (and ethical).

I would like to see SOLID, and its related components (Web ID, JSON-LD / RDFa) built with performant systems-level code, and in commercially-viable domains, where privacy and security-first is a complementary and not a costly artefact of any decision to implement. Essentially, I am working on how to best remove the technical barriers to make it an easy decision regardless of the industry.

Specifically talking about the specifications, (as the implementations are only an influence to those and complementary to the process), I'd like to see the standards process running inline with real-world technical efforts across stacks. Multiple reference implementations would help gain momentum and legitimise the standard. This, with a strong view to evolving into a WG is how I'd like to drive the work going forward.

[RubenVerborgh]

I legitimately feel there's a bias towards seeing the world from a JavaScript-oriented perspective

That should definitely not end up in the spec, good action point.

[RubenVerborgh]

The currently proposed spec structure has 5 documents (#5); we can have different editors for each of those documents.

Will leave this to #1, and thus subsequently solid/process#6.