Current editor PRs do not provide sufficient details for an informed decision

[RubenVerborgh]

No description provided.

[Mitzi-Laszlo]

@RubenVerborgh The pull requests you mentioned are all following the current process which includes a description of the role of an editor as well as how to submit a new process proposal and how the process proposal can be legitimised. Perhaps you could put together a new process proposal and get consensus? In the meantime fortunately we have a process to be able to advance.

[Mitzi-Laszlo]

What the editors are editing is covered in the first line of https://github.com/solid/culture "This repository details how changes to the Solid Specification, Solid Roadmap, and Supporting Documentation may be proposed and accepted."

[Mitzi-Laszlo]

The line "Candidate proposals to the Solid Specification, Solid Roadmap, or Supporting Documentation submitted for review go through an editorial process before they are accepted." on https://github.com/solid/culture#reviewing-proposals is also relevant

[dmitrizagidulin]

I agree with @RubenVerborgh here. I re-read the current culture README several times, and it's not clear at all what the general Editors listed in editors.md actually do.
I do think we should clarify, to not have general Editors, but panel-specific ones.

[Mitzi-Laszlo]

At the moment there isn't even a clear legitimate collective decision if there are one or multiple Solid specs and if there are multiple Solid specs what they would be.

We need a process to get to that point.

"Editors may abstain." was intended for editors to be able to not have to vote on issues they do not feel they are in a position to vote.

Agreed that eventually we will need to clarify the editors scope and likely much, much more detail on other concerns too. Fortunately we have a working process to be able to advance today as well as a clear path on how to submit new process proposals. @RubenVerborgh great that you've started a concrete proposal on #37 I've added my thoughts to it there and I'm sure others will want to comment too.

Was there anything blocking raising this concern in the months of conversation put into the previous conversation before it was finally approved yesterday?

[Mitzi-Laszlo]

Implementation is part of the process. What you are talking about is scope, which is very fundamental to the process.

Squeezing things into editors.md opens up the possibility for others to do the same and then we have instability and uncertainty which makes it difficult to progress with legitimacy.

Fortunately there is an agreed way to make new process proposals.

[Mitzi-Laszlo]

Deciding who has a voice on what is the fundamental question being answered in the process.

[Mitzi-Laszlo]

If you don't have time for the process then perhaps it's best you don't question it after weeks if not months of conversation to come to an agreement together that has been approved yesterday.

[Mitzi-Laszlo]

It's less about my work and more about OUR work. Together.

There is nothing stopping you writing, you are the one that started this conversation.

If what you were proposing were not a change, then why does it matter right now? Perhaps we could revise in 6 months, for example.

What is moving us backward is you questioning co-created agreements that have been approved only one day later.

Indeed “We now have a high-level process that is legitimized.”

“Yet I think that we can also just trust people to make helpful decisions under the mandate provided already by the process.” Agreed! Let’s go

[csarven]

I can understand that it'd may be (for the most part) possible to deduce some listed under a panel and editors, they're an editor of a relevant spec (possibly hinted by the panel but granted it is not always the case).

I did originally find the editors list generic ie. it didn't actually indicate who is doing what editing or whether by being listed as an editor authorises them to work on any spec. I went along with the other folks to make a PR thinking that I probably missed something for the time being.

I think it'd be useful to add another column to the editors listed with "Specs". That can be useful for look up as well as serve to know who is allowed to do what. Alternatively, yes, #37 works too but it may be redundant in addition to the editors list - unless of course 37 is intended to include more information than what could go on the current editors list (table or whatever).

[Mitzi-Laszlo]

Excellent, thank you Ruben, we can use this co-created legitimised process for now.

Meanwhile, for those who are interested, let's work on putting together a new process proposal on #37 in the coming weeks. There are many ways to improve the current process if we want to open that can of worms. Importantly, let's not make this new proposal a blocker to starting writing and agreeing on a stable spec.

If a temporary lightweight process is too difficult to agree on and the seeds of doubt are too strong despite the approval, perhaps it is faster and more efficient to use the W3C Working Group process.

[shaunagm]

It seems to me there are two distinct questions here:

1. Should editors be given approval rights over all documents in the specification, or over individual documents in the specification?
2. Does the decision to clarify question 1 require updating the process/readme, and therefore going through the current update process (which as far as I can tell means "writing up the clarification we want to make, submitting it as a PR, discussing it with commenters, and getting approved by Tim")?

It looks like there's some consensus around the answer to question 1 - that editors should be selected for individual documents in the specification. I'm not very familiar with Solid but that sounds like a good plan to me as well.

Where the debate appears to be happening is around question 2. Questions over what's allowed by a process and when the process needs to be updated to do something new are very normal and to be expected -- though that doesn't make them any less exasperating to resolve. But you wouldn't expect a piece of code to run perfectly and be completely clear right away either.

Let me propose two options here:

The "implementation-first" option: as originally suggested by @RubenVerborgh, you go ahead and implement the document-specific editors list without making any changes to the process/readme. Presumably you'll give people a chance now to say they disagree with having a document-specific editors list, and that won't be an issue, but maybe in the future everyone will think "oh that was a mistake, let's do it differently" and then you can change it directly as well. If there's ever not consensus on what to do, you can resolve it by going through the steps of updating the process/readme, with all the debate that entails. Whatever PR Tim selects will record the 'chosen' resolution getting recorded in the process/readme. Then, only implementations consistent with the chosen resolution will be legitimate. Here, you implement first, and use updating the process/readme as a fallback.

The "process-first" option: alternately, you can update the process/readme first to reflect this change in how the editors list works. If there's a lack of consensus on whether the document-specific editors list is a good idea, going through the work of updating the process/readme is a good way to clarify and resolve that conflict and come to a firm answer. Then you can move forward with confidence. The downside of this approach is that it gives you extra work at the beginning, which may not be necessary if everyone agrees on what to do.

Both of these options are legitimate and in line with your existing process. I would recommend the implementation-first option if you have consensus around question 1 and the process-first option if you have conflict around question 1.

[justinwb]

It seems to me that the main points under debate in this issue are:

1. Should we designate editors for very specific items?
2. If we provided some level of designation for each editor, would that require a change to the current process?

My perspective on not officially designating specific assignments per editor in the process description was to try and keep things simpler at the official level, and rely on editors to self-manage where they focus their efforts without having to impose much official oversight over that. That said, I think that having an "Areas of Focus" column alongside each editor is a great idea (from @csarven's suggestion above (though i changed the title), and i think in the spirit with @RubenVerborgh's original proposal). IMO, I don't believe this constitutes a normative process change. Let me explain why...

I believe it's important that "Areas of Focus" is not designated too rigidly, because there is important value in editors being able to review changes to solid that might seemingly be outside of their direct areas of focus. For example, an editor with an area of focus including security may have important reasons to provide review on a spec tied to interoperability. At the same time, they should know enough to abstain when they can't provide informed editorial review. If it isn't part of their area of focus, or if they haven't spent time getting educated on the substance by the authors, they should know enough to abstain. If an issue arises, or someone is abusing their editorial responsibilities, there is already a mechanism for timbl to intervene. I believe all of this fits in the process we've outlined, which is why I don't believe it is a normative change. We could certainly add some of this color to the process documentation if that added clarity is helpful - though I don't think that addition should be considered a substantive adjustment.

TLDR; I think we should add an "Areas of Focus" column to editors.md, next to each editor. I don't think these should be rigidly enforced, but used as a way for editors to self-manage. I don't think this is a normative change to the process as we've laid it out.

[Mitzi-Laszlo]

Thank you all for the input and engaging in possible solutions. Just to recap and confirm the route forward:

We would add a third column to editors.md called “area of focus” per editor. Here editors would include areas of expertise they believe they have. This would not influence which editors can vote on what.

Any objections to submitting this pull request to be approved?

[justinwb]

Here editors would include areas of expertise they believe they have.

I think it's important to differentiate between expertise and areas of focus. To me, areas of focus are the places they will most often be expected to perform editorial review. I think this is what is most important. In their request to be an editor, they can specify any expertise they believe supports their requested areas of focus, but I don't think we should let the column turn into a summarized CV - cause that can get unwieldy.

[maxidorius]

We would add a third column to editors.md called “area of focus” per editor. Here editors would include areas of expertise they believe they have. This would not influence which editors can vote on what.

+1 to this. It was my very first feeling about the whole repo: who should I reach out to for a specific area.

---

Overall I am of the opinion to go with "Let's just try it out, see where this takes us". There is a process which is great, and until we try it out, we can discuss about it as much as we want, it won't really take us anywhere. Things that don't work will become obvious quickly enough!

[shaunagm]

Any objections to submitting this pull request to be approved?

Another objection: you will find multiple people above suggesting that this is not a change to the process, which hence does not need a PR and approval.

It is unclear to me whether editing editors.md requires a pull request, and approval of a maintainer to merge, but if it does, that may be what @Mitzi-Laszlo is referring to.

(This is why I like giving things formal names, as silly as it seems. Calling it something like a SEP (Solid-Enhancement Proposal, playing off Python Enhancement Proposals) seems pretentious but it's easy to distinguish from a regular old PR.)

@RubenVerborgh I hear you on finding this process frustrating. I have seen projects fail because they haven't gotten their decision-making systems figured out before a big conflict or controversy came up, but at the same time you don't want to create a system that really slows things down or makes it harder for you to work. It's very much a balancing act, and will involve a little wobbling at first. Thanks for making it clear that this seems like "too much process" for you. That's important to know in order for the community to collectively strike that right balance.

[justinwb]

It is unclear to me whether editing editors.md requires a pull request, and approval of a maintainer to merge, but if it does, that may be what @Mitzi-Laszlo is referring to.

@shaunagm From my perspective at least, here's what I believe that breakdown is:

• Adding or changing editors requires a pull to editors.md and approval (from timbl), which is detailed in the process.
• Changing text in editors.md that would constitute a substantive change to the process would similarly require a pull and approval.
• Adding clarifying information (for example, about areas of focus) that doesn't introduce a substantive change to any agreed upon process, or changes named editors, should only require a pull if the author is looking for feedback or review from their peers. For example, I sometimes use pulls as a way to get another set of eyes on what I put together in cases where they may not be mandatory.
• If the author doesn't have write permission to the repository, then they will have to fork and pull.

[Mitzi-Laszlo]

Absolutely agree with "people over process". Brazilians have led the way on paperwork tragic comedy. The process should absolutely be designed to work for people and never the other way around. If there is no process whatsoever or the process is ill-defined and imposed (see Brazilian favelas where paperwork does not touch) only the loudest, strongest, and bolshiest people get their way. I suggest that we should always be asking ourselves if we are adequately protecting the weakest members of our project and those who are impacted by it. Not out of kindness necessarily (although it is nice to be nice), but out of a desire to build a healthy project with strong outcomes.

@RubenVerborgh You are absolutely right that we will very likely reach points where editors are needing to make decisions out of their depth because of the homogenous professional background of the majority of the people on this project today and the scope of the project reaching well beyond that profession.

Here are some mechanisms to counteract that concern for now:

• The good thing is, there are panels. The purpose of a panel is to gather expertise and advise. No president has been a profound expert in all areas, that's why there are advisors.

• Another protection mechanism is that editors can abstain. So, for example, a person who is not an engineer, may often want to abstain from engineering decisions. Another example would be that a person who is not a privacy expert, may want to abstain from privacy decisions. Although, sometimes there is overlap between professions and it will make out average decisions more robust when we have varied professions working together.

• I trust Tim's judgement to appoint editors who have relevant knowledge, of some sort, to the Solid project.

• In the scenario that the outcome of the editors decision is ill informed and out of their depth then there is also a mechanism for Tim to intervene on the outcome and unilaterally decide on the way forward independent of the outcome.

In 6 months or so, maybe a year, or when there is a real block or we are really seeing the outcomes suffering we will definitely have to review how we make decisions together.

There is no way to make everyone happy which is why I am delighted we have something to work with for now. Like @maxidorius said let's just try it out, see where this takes us.

Sometimes the process will lead to outcomes that a few people don't agree with. It's important that we respect the voices of others and don't block the whole project when we don't get 100% of our way.

The purpose of the bureaucracy around changing the fundamentals of how we work togethe rand agree to agree is to make sure there is a degree of stability in the project and that the process is not constantly in flux every time one person is upset with one outcome (which will likely happen regularly).

The project stakeholders need to be sufficiently on board with the process for the outcomes of collective decisions to be accepted by all even when they don't agree. Extensive communication of process proposals along with sufficient time for everyone to reflect, make their points, and feel heard are important for the process outcomes to be be accepted by all.

I really appreciate everyones work at coming together and co-creating this agreement on how to agree. Everyone compromised, and that takes guts, so a big thank you to all contributors who got us to the point where we are now.

[Mitzi-Laszlo]

This is not my process. It is a co-created process over weeks of conversation with liberal public invitations to join in with the final result approved by Tim.

If there is an issue around interpretation of the current process, let's formulate the question very carefully and address it through a community vote and put it forward to Tim.

@RubenVerborgh perhaps you could have a first go at formulating the question?

[dmitrizagidulin]

@Mitzi-Laszlo I'll start, with regards to formulating the question:

Would there be any objection to clarifying the interpretation of the current process (or, if this is deemed a substantive change, to updating the process), to specify that the position of Editors should be panel-specific?

[justinwb]

If there is an issue around interpretation of the current process, let's formulate the question very carefully and address it through a community vote and put it forward to Tim.

As far as the issue pertaining to this thread - i thought we had already arrived at a resolution that the OP and others participating in the discussion were aligned on. If there's a larger question related to the process, that's totally fine, but we should continue it somewhere else, since this issue was about something specific. The resolution as I understood it:

• Add an "Areas of Focus" column to editors.md next to each editor.
• Areas of Focus are not rigidly designated, but are used as part of a mechanism for editors to collectively self-manage (see this comment)
• An explanation providing some more color about this should be added to the documentation, but it is not a normative change to the approved process
• Because it is not a normative change, adding some clarifying text to editors.md about it doesn't require a pull request and approval from timbl

Given all of that, I have something written and ready to merge that reflects these bullets above. If people genuinely believe that we're not already at a resolution, I'll hold off on merging it.

[Mitzi-Laszlo]

@dmitrizagidulin thank you for the suggestion.

@RubenVerborgh's thumbs down would indicate that the approach I suggested would not satisfy him. @RubenVerborgh did I interpret that correctly?

Ideally, we would find an approach that gets @RubenVerborgh on board while building from existing agreements. @justinwb thank you for your suggestion, that sounds like excellent alternative route forward if that satisfies the concerns raised enough to be able to more forward together.

[justinwb]

Ideally, we would find an approach that gets @RubenVerborgh on board while building from existing agreements. @justinwb thank you for your suggestion, that sounds like excellent alternative route forward if that satisfies the concerns raised enough to be able to more forward together.

I believe what I proposed accomplishes that, where the 👍's on this comment are validation of that. So I think we're at a place where we can move on and resolve this, but will wait a bit to see if anyone feels otherwise before doing so.

[kjetilk]

Having been absent for this discussion, but present for most of the preceding discussion, I wonder if you have distracted yourself from the path that we discussed previously. The basic principle, as I understood it from preceding discussion is this: Most of the work will happen in panels. Panels will be fairly autonomous units, they will need to consider their work in a wider context, but will not be held tightly to any rigorous process. Panel participants will have authors or "lower-case editors" actually writing specifications. It is only when they choose to submit their work as a substantiative change or addition to specs that the work will be subject to The Process, it is only then that The Capital Letter Editors will poke at it.

If most of the work happened as individual PRs to specs, it would indeed be an overly heavy process, and surely, some edits will be done that way. This practice is discouraged if not by the process document itself, then from the economy of the dynamic the process creates: The process encourages collaboration and elaboration in Panels before substantiative changes are submitted for editorial review, and the work in Panels is not process-heavy. The end result should not be very heavy to work with.

It is possible that this should have been clarified, but I don't think the process should detail it further, as it would then possibly disallow a simple single-PR change. All these ways of operating are possible, but work in Panels is usually the more efficient one.

So, to the original question of the thread: The Editors are the people who perform the final evaluation of submissions into the specs, not the people who work on fleshing out spec details. The latter group doesn't need Director approval, they just do work, mostly in panels.

Thus, I don't think areas of focus as proposed in #81 are what we want. Areas of focus are defined by the work done in panels, not in the editorial board.

The process document is itself a normative document, and so to clarify the expectation that work will happen in Panels doesn't seem to belong there, it is not normative. However, to say more clearly that The Editors are people evaluating the final submissions not the actual spec writers, could be considered a normative statement, and so could go in there.

To me, it feels like we do have what we need to start writing specs, in Panels.

[justinwb]

Please see #95, which includes a proposed resolution to this issue (recommended by @timbl)

[justinwb]

@RubenVerborgh With the merge of #95, and the subsequent updated rounds of editor applications - as the OP do you agree that this issue has been resolved and is now OK to close out?