On Mon, Jan 11, 2021 at 10:38 AM Brian Hulette <[email protected]> wrote:
> 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. > Ah, that sounds good. For some reason I completely missed that there was a separate branch being used here. > (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). > My preference would be for (1) as well; and in addition presumably the content changes would improve the current website as well as the new. There is also option (3) which is allowing development to continue on the dev branch (rather than a freeze) and placing the responsibility of correctly recognizing and resolving conflicts on the owners of the website-revamp branch. It might be worth highlighting an example of a content change that makes any of these workflows difficult. > [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 >>> >>
