- From: Eric Eggert <ee@w3.org>
- Date: Wed, 07 Aug 2019 14:01:49 +0200
- To: "Shadi Abou-Zahra" <shadi@w3.org>
- Cc: "Shawn Henry" <shawn@w3.org>, public-eo-plan@w3.org
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 - http://www.w3.org/People/shadi/ > 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)
Received on Wednesday, 7 August 2019 12:01:54 UTC