Re: content under review - freeze or update?

I am all for what the main editors feel is the best approach. They are
doing the "heavy lifting" and understand the temperament of the
participants doing reviews. What the editors (Shadi, Eric, Shawn, Daniel,
Hidde) feel is best is what I am happy to back as a co-chair.


Brent A. Bakken
Director, Accessibility Strategy & Education Services
Psychometrics & Testing Services
Co-Chair Pearson Able (global)
*Pearson*

512 202 1087
brent.bakken@pearson.com
US Central Time Zone






On Wed, Aug 7, 2019 at 7:01 AM Eric Eggert <ee@w3.org> wrote:

>
>
> On 7 Aug 2019, at 13:43, Shadi Abou-Zahra wrote:
>
> > I agree with Eric, I prefer when there is a frozen version that does
> > not keep changing while I'm reviewing it. I believe in the past this
> > was the request of several participants too. The proposed solution of
> > having two links -- one to a frozen snapshot and one to a live draft
> > seems to meet the best of both worlds. If EOWG (or EOWG leadership)
> > decides to take up this approach, then reviewers of the frozen version
> > *must* make sure to also review the closed issues to avoid
> > re-opening/repeating issues.
>
> I think those issues should stay open. The commit into the “live
> draft” branch can have a “fixes #123” (with #123 being the issue
> number). Every open issue then gets a note that says “will be closed
> when PR #567 is merged” note. Maybe we can add a label “fixed in
> draft” to give people a way to filter.
>
> >
> > Best,
> >   Shadi
> >
> >
> > On 07/08/2019 09:12, Eric Eggert wrote:
> >> 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)
> >>
> >
> > --
> > Shadi Abou-Zahra -
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_People_shadi_&d=DwIDaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=v-L6X-ScaY5UKb-F-_zcuXdbPw2UYK_gaTG8R5d9h7U&m=878l-494kizI_kS85bi2er_ssmdO4sWLacts40hnyDY&s=WRqQhz6fLxuKHx6C0YljZyvZi5ys0cesL9kttv5Kmgs&e=
> > Accessibility Strategy and Technology Specialist
> > Web Accessibility Initiative (WAI)
> > World Wide Web Consortium (W3C)
>
>
>
> --
>
> Eric Eggert
> Web Accessibility Specialist
> Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)
>
>