The 2021 "Revising a Recommendation Process" is painful for WGs
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 262
- Forks
- 194
- PR merge metrics
- No merged PRs in 30d
Description
TL;DR: The work and tooling required to execute upon the new "Revising a Recommendation Process" in Process 2021 is most likely far more manual and painful than the Process CG intended. spec-prod is struggling with finding a solution that isn't going to require significant education across every WG maintaining a REC. A proposal to address the situation is outlined below.
@msporny wrote:
As an Editor, I had to manually mark up the revised REC substantive changes over the weekend (we had been merging editorial and candidate changes over the past two years before the 2021 Process existed) and it was not an experience I would wish on anyone. link to thread
@marcoscaceres wrote:
I feel pretty strongly that Editors shouldn't be put in a position where they have to manually include before/after changes. I'm hearing a lot of negative feedback from folks in multiple working groups about how annoying/frustrating this process is going to be, which is really concerning to me as and editor, tool maintainer, staff, and as a chair. link to thread
@msporny wrote:
The simplest fix that I can think of is changing to this mode of operation:
The changelog in the specification lists "editorial changes" and "substantive" changes since the last release, like we do here: https://www.w3.org/TR/vc-data-model/#revision-history
You either link manually to the PRs for substantive changes and/or we upgrade rs-changelog to make that easier for folks.
We get rid of all the proposed correction markup and point AC Reviewers to the Changelog at the bottom of each spec (which has links to the PRs if they really want to dig in).
We provide a diff-marked version as a part of the review content to the AC.
If we do those things, and IIUC, we don't disrupt the regular Github workflow that most WGs are using. We just require "editorial" or "substantive" labels on PRs done when revising a REC (which we already require when generating the new errata.html pages). link to thread
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Process 2021 requirements described in this issue and review how the changelog, errata.html pages, and AC review content are currently produced. Read the referenced rs-changelog workflow and linked discussion threads to determine the accepted direction. Done means a decided, implementable workflow that reduces manual revision markup while preserving the required review information.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, html
- Domain
- documentation, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100