I spoke with Gris and Agnieszka about this on Friday. I should probably fill in the background a bit.
The strategy we've adopted ro review the new designs so far is pretty similar to what Robert proposed, except rather than having a separate directory and merging PRs to the master branch, they've been sending PRs to merge into a separate `website-revamp` branch [1]. I've been keeping `website-revamp` synced to master, and I've been careful about only merging PRs that edit the website style (e.g. css and html templates) and not changes to the content (markdown files), to avoid merge conflicts when we finally bring the website-revamp branch into master. (Conflicts in style changes can be easily resolved, conflicts in content are much more difficult to tease apart) Unfortunately some of the recent PRs make changes to the markdown files as well. I spoke with Gris and Agnieszka about this and they indicated there will likely be more content changes as they edit copy and split up pages. On Friday we discussed a couple different options: 1) Make content changes on the master branch, completely separate from the style changes, or 2) Have a *planned* freeze in website changes to finalize the new design Honestly my preference is for (1), but I'm hesitant to push for it as it puts more burden on the website developers, who'd need to make sure content changes work in two website layouts. (2) on the other hand puts time pressure on the reviewers (myself and Pablo so far). Brian [1] https://github.com/apache/beam/tree/website-revamp On Mon, Jan 11, 2021 at 10:03 AM Robert Bradshaw <[email protected]> wrote: > A site-wide freeze during which there was a huge, rushed code dump was not > the most effective way to manage or review the large website changes last > time, and I don't think it would be a good idea to attempt that again. > > Instead, can we create a parallel directory/site in our repo, > incrementally build/commit/review it in there, and once everyone is happy > with it do a single switch with a small redirection commit (followed by > deleting the old content). As for incorporating changes that happen during > development, this is what every developer is already doing (on the code > side) and we should take advantage of the revision control systems we use > to make sure nothing is lost. > > - Robert > > > > On Sun, Jan 10, 2021 at 4:07 PM Griselda Cuevas <[email protected]> wrote: > >> Hi folks, >> >> As you know we've been working on a revamp for the website, and we're >> getting ready to commit the work we've done. In order to minimize the risk >> of losing changes other contributors make during this period, we'd like to >> plan a freeze so we can work on making the revamp commits. A freeze in this >> context would mean that we give notice to our dev community to do not make >> any PRs or change to the site during this period. >> >> I'd like to propose we have a one-week freeze during the last week of >> January or the first week in February. >> >> What do you think? >> >> G >> >
