Definition of substantive changes in the editorial process might cause trouble

[RubenVerborgh]

No description provided.

[acoburn]

Ultimately, the question of substantive vs. non-substantive will be a judgement call by the editors, and it may be helpful if this process document allows that level of flexibility. @RubenVerborgh is correct that there could be non-substantive changes to normative text.

In fact, here is one such example of a non-substantive change to normative text in the W3C Web Annotation repository.

I liked the way that WG handled these cases, where an issue or PR would be explicitly flagged as non-substantive" by an editor.

[justinwb]

Thanks for flagging this and breaking down the problem cleanly @RubenVerborgh. I agree with the issues as you listed them, and with the suggestion that we need additional clarity. I'll take a crack at working up some language this weekend.

[justinwb]

@RubenVerborgh Would these changes or something close to them address the points that you raised? Inline comments directly on that commit are more than welcome. After we've established better language that clears up any ambiguity we can figure out if the end result is substantive and requires another approval by @timbl.

[Mitzi-Laszlo]

(@justinwb the link to the suggested changes is broken)

[justinwb]

(@justinwb the link to the suggested changes is broken)

The link is good - github has been having issues and you likely ran into them.

[Mitzi-Laszlo]

If editors explicitly make the final decision about if a change is substantive then we would need to detail what happens when two editors disagree. A possible solution is to state that there needs to be a unanimous decision from all editors. If there are any disagreements the judgement is made by the Solid Director. However...before getting into the nitty gritty of strict interpretations etc..

There's another factor here....

Fiddling around with non-substantive changes to the process and debating about if a change is substantive or not could be really unproductive.

Let's take 10 steps back and think about why we are doing this.

The purpose of this agreement on how to agree is to be able to move forward as a team for now. There's no way you can make everyone happy with a process and I'm really impressed with the collaborative effort to write this agreement together in a way that everyone compromised and we delivered a final result.

There is a point when you need to draw a line underneath it for now and agree to pick it up in some months, years, or when there is a real substantive ( :) ) gridlock block.

For this reason I prefer @acoburn suggestion of allowing for level of flexibility and working with what we have now.

The process is there to help us work together. The sprit and culture of how we use this process when we work together is also important. We need to remember we are team and we need to support each other and use it to progress our collective mission, vision, and values.

[justinwb]

If editors explicitly make the final decision about if a change is substantive then we would need to detail what happens when two editors disagree. A possible solution is to state that there needs to be a unanimous decision from all editors. If there are any disagreements the judgement is made by the Solid Director.

If there's disagreement, then I think it is better for it to automatically default to substantive, which we've got existing process for. I reflected that in this new commit.

There is a point when you need to draw a line underneath it for now and agree to pick it up in some months, years, or when there is a real substantive ( :) ) gridlock block.

Completely agree, although I don't think that time is now. A brand new process is like a brand new piece of software that no one has used yet. We design both with the best of intentions, but once you put it out there and have others attempting to use it, they alert you to all kinds of problems, gaps, bugs, or logical issues that exist within it. If we don't take advantage of feedback as it comes in, especially in these early days, we lose valuable opportunities to improve the process and get to that mature state. We also run the risk of alienating contributors who raise valid issues with the process as it stands.

[Mitzi-Laszlo]

@justinwb this new commit is a good solution.

Here's another issue about the offshoot conversation.

[kjetilk]

Just a short note on

A change is considered substantive when it alters the normative text of the Solid Specification or the Solid Roadmap.

I think the intention was to capture changes that influences behaviour, and so just saying "normative text" was a bit unfortunate. We could say something like "alters the semantics of the normative text"? So, grammar changes could also be considered non-substantiative?

[TallTed]

"alters the semantics of the normative text"

and/or something like "changes that would require revision of an existing implementation of the old text in order for that implementation to comply with the new text" are substantive.

[justinwb]

Please see #95 for a proposed resolution to the items raised in this issue.

[justinwb]

@RubenVerborgh With the merge of #95, as the OP do you feel that we have now sufficiently addressed this issue and can safely close this issue out?