Re: content under review - freeze or update?

Just as an idea: If the changes that come in during a review are done in 
a branch, reviewers have a “frozen” version _and_ editors can update 
along the way. One could even think about having daily snapshots so that 
people can just use the most recent version which is then fixed 
(probably overkill).

For a thorough review, I think having a frozen version is essential. I 
kinda expect that those are so far along that the editor is making 
relatively minor changes anyway.

As a participant, I find targeting a moving resource exhausting and 
really hard to motivate myself to make time for it early. When I know an 
editor is implementing changes as we go, I wait until the last minute to 
make sure I can review the latest version before it gets back to the 
group.

As an editor, I prefer the review of a “frozen” version as it feels 
more time efficient as I can weigh different comments against each other 
before making a change or get to the group to get comments. If I already 
implement a change and then have a different view it means I have to 
explain to the group what the status was that leads to the change and 
then what the new change is. If there is a baseline version I can say 
“these have been the two comments, how shall I tackle this” which 
feels more productive. I usually prefer to not work on the particular 
resource at all during review. It helps me to gain perspective for 
implementing the changes.

I don’t feel that there is an easy answer to this and it depends on 
the work mode of the editor.

👋 Eric

On 6 Aug 2019, at 18:34, Shawn Henry wrote:

> Hi all,
>
> When a draft resource is under review it, should we freeze it or 
> update it appropriately during the review period? I think it would be 
> good to establish a default approach, and can do differently in 
> specific cases as warranted.
>
> Two recent use cases (I might not have the scenarios exactly right):
>
> 1. Authoring Tools List Requirements Analysis was put on the agenda 
> that was announced on Wednesday for Friday meeting discussion. On 
> Wednesday afternoon, Vicki sent 2 suggestions for additions.
>
> My perspective is that it was best to go ahead and add those (as 
> editor agreed) so they were in the document that we discussed on 
> Friday. If the doc was considered frozen until after Friday, then we'd 
> have to go back after or during the meeting and tell participants 
> those things were/would be added. And then do another review.
>
> 2. Curriculum Units 1 & 2 Survey was opened on 31 July with a close 
> date of 13 August. Some comments came in right away that lead to edits 
> (that have not been merged yet, pending this issue :-).
>
> I know some people (e.g., Brent) will not be able to review this until 
> near the end of the review period. It would be more efficient if those 
> people reviewed the changes -- so they don't have to re-review them 
> later.
>
> ---
>
> One thing to keep in mind is that I think some people get worn out 
> with multiple reviews (and maybe not give good reviews at the end). 
> Therefore, it's probably good to avoid too many complete and thorough 
> reviews.
>
> About making changes as they come in (as feasible):
> * Pros: It seems clear that making changes right away leads to better, 
> sooner, fewer reviews.
> * Con: The potential negative of not freezing content is that some 
> participants print out the pages and start a review, but don't finish 
> it and submit comments. Then they go back later and finish their 
> review on the old printed pages -- and end up commenting on wording 
> that has changed (thus wasting their time).
>
> ---
>
> My perspective is that the pro outweighs the con significantly.
>
> I think if we let participants know of changes, then that mitigates 
> the con. I think the situation in the con is not super common -- and 
> we don't have to do a detailed diff as we go along, just a high-level 
> bullet list of which sections changed.
>
> Let's check in on this in EO-Plan meeting Wednesday, and maybe bring 
> to EOWG on Friday if we think useful.
>
> Best,
> ~Shawn



--

Eric Eggert
Web Accessibility Specialist
Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)

Received on Wednesday, 7 August 2019 07:13:03 UTC