- From: Daniel Montalvo Charameli <dmontalvo@w3.org>
- Date: Wed, 7 Aug 2019 13:54:51 +0200
- To: Shadi Abou-Zahra <shadi@w3.org>, Eric Eggert <ee@w3.org>, Shawn Henry <shawn@w3.org>
- Cc: public-eo-plan@w3.org
I think a frozen version is needed. From my previous life, evaluating a website that was constantly changing was one of the most annoying things for me and the team. That does not mean the editor is no longer working behind the scenes, :-) I would go for the approach of having the frozen version in the master branch (or main branch of the repository, whichever that is) and then using another branch to include changes as they come. We could make an early pull request for that branch and Netlify will create the deploy-preview--xx URL type for us. GitHub & Netlify allow this flexibility to combine them both. This is what I have been doing lately. Best. On 8/7/2019 1:43 PM, 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. > > 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) >> >
Received on Wednesday, 7 August 2019 11:55:23 UTC