Solution to accelerate solidproject.org updates' publishing #222
Conversation
proposal to solve the problem raised in #217
Mitzi-Laszlo
added
the
process proposal
| @@ -147,6 +147,10 @@ The solidproject.org website is linked to the [`master` branch of the GitHub rep | |||
|
|
|||
| Anyone can make suggestions by commenting or submitting pull requests to the [`staging` branch of solid/solidproject.org](https://github.com/solid/solidproject.org/tree/staging) to be reviewed by Editors, and be approved by the Solid Director before they go to `staging`. | |||
|
|
|||
| The Editorial review of website suggestions must happen within 24 hours of submitting the pull request. If the Editorial review of the website suggestion does not happen within 24 hours, then the website suggestion can be published with Creator review as long as the suggestion is technically in line with approved Solid website content. | |||
There was a problem hiding this comment.
48 hours seems more reasonable
There was a problem hiding this comment.
Surely one of six of the Editors can check the occasional website suggestions once every 24 hours. Perhaps you could arrange it between yourselves to take turns so you only have to check once every six days.
If that's too much of a burden then an alternative could be to trust the Creators to review the website suggestions as long as they are technically in line with previously approved website suggestions. If suggestions are not technically in line with previously approved website suggestions then it could go to the Editors for review.
There was a problem hiding this comment.
Several things are problematic with this, I will list the most important ones below:
-
The assumption that the problem would be related to editors reacting slowly. There seems to be plenty of evidence to the contrary, including https://github.com/solid/solidproject.org/pulls?q=is%3Apr+is%3Aclosed+reviewed-by%3Arubenverborgh
-
The assumption that there would be a trust problem, as opposed to a quality check that is very common in open-source projects (hence the built-in review functionality in GitHub).
As such, I propose that we first aim to understand what exactly is causing slowdowns, before trying to fix anything. Clearly, the two assumed causes (slow editors / lack of positive feedback) are not the correct ones; hence, this fix can't be the correct one either. Also, note that the issues in #217 are considered to be addressed by the existing process, which simply is not followed consistently. I have created and assigned this issue to identify the causes: #226
| @@ -147,6 +147,10 @@ The solidproject.org website is linked to the [`master` branch of the GitHub rep | |||
|
|
|||
| Anyone can make suggestions by commenting or submitting pull requests to the [`staging` branch of solid/solidproject.org](https://github.com/solid/solidproject.org/tree/staging) to be reviewed by Editors, and be approved by the Solid Director before they go to `staging`. | |||
|
|
|||
| The Editorial review of website suggestions must happen within 24 hours of submitting the pull request. If the Editorial review of the website suggestion does not happen within 24 hours, then the website suggestion can be published with Creator review as long as the suggestion is technically in line with approved Solid website content. | |||
|
|
|||
| The Editorial review must be green pen, not red pen edits i.e. edits cannot say that text suggestion is inadequate without actively stating what the text should become or what specific text should be removed completely for the suggestion to become adequate. Red pen Editorial reviews can be ignored. | |||
There was a problem hiding this comment.
No need to write this.
|
Once more, I don't think we're solving the right problem here. Note especially:
Editor approvals generally have happened within 24 hours already, so that can't be the solution. |
|
The reasoning behind red pen and green pen edits is that the Editorial review often says what should NOT happen without providing a solution of how to move forward which is the reason suggestions get blocked. Do you have another idea on how to resolve this? |
Do you have instances where this is a problem? Then we can look at those cases and learn from them. |
|
Best chat with @mariadimou from CERN who was the one raising the problem on #217 |
I don't see the problem "Editorial review often says what should NOT happen without providing a solution" mentioned. |
|
Sorry, people, but this is pettiness in a pull request. Let this comment serve as a reminder that we're on a public forum here, where every action we do happens in front of the entire world. Do we really want to add a part to the official Solid process in which we say, between the lines nonetheless, that:
I can't believe that we have come to the point where we actually want to encode this level of malfunctioning into a public document through passive aggressiveness. How far have we strayed if we honestly believe this is a good thing? That is apart from the fact that, so far, zero evidence has been provided for slow or non-constructive volunteers. Yes, improvements are needed, but this is not the way. I repeat my (constructive) suggestion to first analyze what is causing slowdowns (#226) before providing the wrong solution to the wrong problem, and haphazardly insulting every single of our volunteers. |
|
Will close this pull request with a specific proposal as there is clearly an appetite to discuss further about the issue in general. |
No, @Mitzi-Laszlo, this one is being closed because it is the wrong solution to the wrong problem. I'd appreciate if you could apologize for calling our volunteers slow and non-constructive. |
proposal to solve the problem raised in #217