Re: Planning a freeze on website changes to merge new designs
Hey Brian and Robert, Will you be available tomorrow at 8 am PT to join Beam website review? After the usual update we could discuss how we should approach the merges. I sent you an invitation to the meeting. In case it doesn't work for you, Jakub and I are available for a call on Thursday at 9 am PT. Let me know if you'll be able to join us on one of these dates. Kind regards, Agnieszka On Thu, Jan 14, 2021 at 4:42 PM Jakub Sadowski wrote: > > 'You could add the shortcode files on master (modified so they work with > the current website) in addition to the content changes.' > If I understand correctly you mean modifying shortcodes so they work no > with new styles, icons and javascript files but the ones from master branch? > > On Thu, Jan 14, 2021 at 12:39 AM Brian Hulette > wrote: > >> >> >> On Wed, Jan 13, 2021 at 9:09 AM Jakub Sadowski < >> jakub.sadow...@polidea.com> wrote: >> >>> Hi guys, >>> unfortunately option 1 is not really possible, because most of the new >>> content files are importing shortcodes files so if we merge only content >>> without layouts, these pages won't compile. >>> >> >> You could add the shortcode files on master (modified so they work with >> the current website) in addition to the content changes. Then the website >> revamp would just need to change the shortcode files. This is more work, >> but it's possible. >> >> The only reasonable option is to freeze the website and merge it then. >>> My proposition is to merge it as follows: >>> - firstly just swap the existing scss,js and html files and add the new >>> ones, because most of the changes made by users are in content files and we >>> want the continuity of design. >>> - next are content files and here we just need to focus on couple of >>> pages which were changed, most of these pages are main pages of each >>> section and their purpose is to look legibly and nice, so we shouldn't add >>> there more text, we can only check if the short description was changed >>> recently and swap it for the newer version. >>> The rest of the content pages where the most information is, weren't >>> changed so we want to take them from the master branch. >>> >>> This whole work was dedicated to change the design of the whole website, >>> content which is changed is just displayed nicer for the user and is only >>> on main pages, some of them have specially arranged texts to match new >>> design, even if there are some new texts in these files on master branch >>> they don't really have to match the new sites. >>> >>> - Jakub >>> >>> On Wed, Jan 13, 2021 at 3:59 AM Brian Hulette >>> wrote: >>> On Mon, Jan 11, 2021 at 11:00 AM Robert Bradshaw wrote: > On Mon, Jan 11, 2021 at 10:38 AM Brian Hulette > 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
Re: Planning a freeze on website changes to merge new designs
'You could add the shortcode files on master (modified so they work with the current website) in addition to the content changes.' If I understand correctly you mean modifying shortcodes so they work no with new styles, icons and javascript files but the ones from master branch? On Thu, Jan 14, 2021 at 12:39 AM Brian Hulette wrote: > > > On Wed, Jan 13, 2021 at 9:09 AM Jakub Sadowski > wrote: > >> Hi guys, >> unfortunately option 1 is not really possible, because most of the new >> content files are importing shortcodes files so if we merge only content >> without layouts, these pages won't compile. >> > > You could add the shortcode files on master (modified so they work with > the current website) in addition to the content changes. Then the website > revamp would just need to change the shortcode files. This is more work, > but it's possible. > > The only reasonable option is to freeze the website and merge it then. >> My proposition is to merge it as follows: >> - firstly just swap the existing scss,js and html files and add the new >> ones, because most of the changes made by users are in content files and we >> want the continuity of design. >> - next are content files and here we just need to focus on couple of >> pages which were changed, most of these pages are main pages of each >> section and their purpose is to look legibly and nice, so we shouldn't add >> there more text, we can only check if the short description was changed >> recently and swap it for the newer version. >> The rest of the content pages where the most information is, weren't >> changed so we want to take them from the master branch. >> >> This whole work was dedicated to change the design of the whole website, >> content which is changed is just displayed nicer for the user and is only >> on main pages, some of them have specially arranged texts to match new >> design, even if there are some new texts in these files on master branch >> they don't really have to match the new sites. >> >> - Jakub >> >> On Wed, Jan 13, 2021 at 3:59 AM Brian Hulette >> wrote: >> >>> >>> >>> On Mon, Jan 11, 2021 at 11:00 AM Robert Bradshaw >>> wrote: >>> On Mon, Jan 11, 2021 at 10:38 AM Brian Hulette 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. >>> >>> I see myself (and all Beam committers) as the owner of the >>> website-revamp branch, It's in the apache/beam repo. >>> >>> It might be worth highlighting an example of a content change that makes any of these workflows difficult. >>> >>> The most compelling example is the extensive changes to the contribution >>> guide here: >>> https://github.com/apache/beam/pull/13565/files#diff-3f46c575ca6547b8deef533eb8e191507edcf806529f7faecb4a56a246063af6 >>> The PR was already missing the changes made to the
Re: Planning a freeze on website changes to merge new designs
OK, so the current status is that changes are being reviewed and merged into a separate website-revamp branch. There are several reasons we could want to do this (e.g. could the changes not be made incrementally, or was there a strong desire to launch the new site "all at once"), but at some point we will want to merge this back into master. My take is that it is on those who created this branch and are trying to push the changes in to be responsible for resolving any conflicts with master, just as it is with every other change anyone else takes on to make to the codebase. This can be done in whatever way is easiest for those making the change, either pushing changes upstream to master (to reduce the delta), resolving conflicts by merging master into website-revamp, or (probably the easiest for that which cannot be upstreamed) regularly merging master into website-revamp and resolving conflicts as PRs are merged into website-revamp. This is assuming that website-revamp is being managed in such a way that incompatible changes are flagged as merge conflicts, rather than silently getting dropped. This doesn't require arbitrary deadlines or freezes--all conflict resolution happens in website-revamp on its own time and it is (cleanly) merged back into master when it is ready (and of course there's no need to do this all at once--any ready parts can be merged before others to reduce the burden of maintaining a fork). The community can help out by refraining from large-scale refactorings that would be difficult to reconcile, but run-of-the-mill content improvements need not be put off. It should be noted that getting the changes merged back into master is a critical piece of completing the task--the job is not "done" just because the changes have been made with the expectation of handing them off to someone else to get it merged. In my experience with open source projects (dating well before Apache Beam), taking the easy route of snapshotting the project at some point, making all your changes there, and then hoping to merge things in is easier at first but at the end of the day more often than not ends up being more work (and frustration) than working on a copy that stays close to head (whether that be the actual master branch, or one that is regularly merged in). These look like good improvements and I'm just wanting to get them in as smoothly as possible. - Robert On Wed, Jan 13, 2021 at 9:09 AM Jakub Sadowski wrote: > Hi guys, > unfortunately option 1 is not really possible, because most of the new > content files are importing shortcodes files so if we merge only content > without layouts, these pages won't compile. > The only reasonable option is to freeze the website and merge it then. > My proposition is to merge it as follows: > - firstly just swap the existing scss,js and html files and add the new > ones, because most of the changes made by users are in content files and we > want the continuity of design. > - next are content files and here we just need to focus on couple of pages > which were changed, most of these pages are main pages of each section and > their purpose is to look legibly and nice, so we shouldn't add there more > text, we can only check if the short description was changed recently and > swap it for the newer version. > The rest of the content pages where the most information is, weren't > changed so we want to take them from the master branch. > > This whole work was dedicated to change the design of the whole website, > content which is changed is just displayed nicer for the user and is only > on main pages, some of them have specially arranged texts to match new > design, even if there are some new texts in these files on master branch > they don't really have to match the new sites. > > - Jakub > > On Wed, Jan 13, 2021 at 3:59 AM Brian Hulette wrote: > >> >> >> On Mon, Jan 11, 2021 at 11:00 AM Robert Bradshaw >> wrote: >> >>> On Mon, Jan 11, 2021 at 10:38 AM Brian Hulette >>> 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
Re: Planning a freeze on website changes to merge new designs
On Wed, Jan 13, 2021 at 9:09 AM Jakub Sadowski wrote: > Hi guys, > unfortunately option 1 is not really possible, because most of the new > content files are importing shortcodes files so if we merge only content > without layouts, these pages won't compile. > You could add the shortcode files on master (modified so they work with the current website) in addition to the content changes. Then the website revamp would just need to change the shortcode files. This is more work, but it's possible. The only reasonable option is to freeze the website and merge it then. > My proposition is to merge it as follows: > - firstly just swap the existing scss,js and html files and add the new > ones, because most of the changes made by users are in content files and we > want the continuity of design. > - next are content files and here we just need to focus on couple of pages > which were changed, most of these pages are main pages of each section and > their purpose is to look legibly and nice, so we shouldn't add there more > text, we can only check if the short description was changed recently and > swap it for the newer version. > The rest of the content pages where the most information is, weren't > changed so we want to take them from the master branch. > > This whole work was dedicated to change the design of the whole website, > content which is changed is just displayed nicer for the user and is only > on main pages, some of them have specially arranged texts to match new > design, even if there are some new texts in these files on master branch > they don't really have to match the new sites. > > - Jakub > > On Wed, Jan 13, 2021 at 3:59 AM Brian Hulette wrote: > >> >> >> On Mon, Jan 11, 2021 at 11:00 AM Robert Bradshaw >> wrote: >> >>> On Mon, Jan 11, 2021 at 10:38 AM Brian Hulette >>> 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. >>> >> >> I see myself (and all Beam committers) as the owner of the website-revamp >> branch, It's in the apache/beam repo. >> >> >>> >>> It might be worth highlighting an example of a content change that makes >>> any of these workflows difficult. >>> >> >> The most compelling example is the extensive changes to the contribution >> guide here: >> https://github.com/apache/beam/pull/13565/files#diff-3f46c575ca6547b8deef533eb8e191507edcf806529f7faecb4a56a246063af6 >> The PR was already missing the changes made to the contribution guide in >> https://github.com/apache/beam/pull/13308. I also just merged master >> into website-revamp, and the PR now has a merge conflict with the changes >> from https://github.com/apache/beam/pull/13420. >> >> >>> >>> [1] https://github.com/apache/beam/tree/website-revamp On Mon, Jan 11, 2021 at 10:03 AM Robert Bradshaw wrote: > A site-wide freeze during which there was a huge, rushed code dump was > not the most effective
Re: Planning a freeze on website changes to merge new designs
Hi guys, unfortunately option 1 is not really possible, because most of the new content files are importing shortcodes files so if we merge only content without layouts, these pages won't compile. The only reasonable option is to freeze the website and merge it then. My proposition is to merge it as follows: - firstly just swap the existing scss,js and html files and add the new ones, because most of the changes made by users are in content files and we want the continuity of design. - next are content files and here we just need to focus on couple of pages which were changed, most of these pages are main pages of each section and their purpose is to look legibly and nice, so we shouldn't add there more text, we can only check if the short description was changed recently and swap it for the newer version. The rest of the content pages where the most information is, weren't changed so we want to take them from the master branch. This whole work was dedicated to change the design of the whole website, content which is changed is just displayed nicer for the user and is only on main pages, some of them have specially arranged texts to match new design, even if there are some new texts in these files on master branch they don't really have to match the new sites. - Jakub On Wed, Jan 13, 2021 at 3:59 AM Brian Hulette wrote: > > > On Mon, Jan 11, 2021 at 11:00 AM Robert Bradshaw > wrote: > >> On Mon, Jan 11, 2021 at 10:38 AM Brian Hulette >> 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. >> > > I see myself (and all Beam committers) as the owner of the website-revamp > branch, It's in the apache/beam repo. > > >> >> It might be worth highlighting an example of a content change that makes >> any of these workflows difficult. >> > > The most compelling example is the extensive changes to the contribution > guide here: > https://github.com/apache/beam/pull/13565/files#diff-3f46c575ca6547b8deef533eb8e191507edcf806529f7faecb4a56a246063af6 > The PR was already missing the changes made to the contribution guide in > https://github.com/apache/beam/pull/13308. I also just merged master into > website-revamp, and the PR now has a merge conflict with the changes from > https://github.com/apache/beam/pull/13420. > > >> >> >>> [1] https://github.com/apache/beam/tree/website-revamp >>> >>> On Mon, Jan 11, 2021 at 10:03 AM Robert Bradshaw >>> 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
Re: Planning a freeze on website changes to merge new designs
On Mon, Jan 11, 2021 at 11:00 AM Robert Bradshaw wrote: > On Mon, Jan 11, 2021 at 10:38 AM Brian Hulette > 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. > I see myself (and all Beam committers) as the owner of the website-revamp branch, It's in the apache/beam repo. > > It might be worth highlighting an example of a content change that makes > any of these workflows difficult. > The most compelling example is the extensive changes to the contribution guide here: https://github.com/apache/beam/pull/13565/files#diff-3f46c575ca6547b8deef533eb8e191507edcf806529f7faecb4a56a246063af6 The PR was already missing the changes made to the contribution guide in https://github.com/apache/beam/pull/13308. I also just merged master into website-revamp, and the PR now has a merge conflict with the changes from https://github.com/apache/beam/pull/13420. > > >> [1] https://github.com/apache/beam/tree/website-revamp >> >> On Mon, Jan 11, 2021 at 10:03 AM Robert Bradshaw >> 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 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 >>>
Re: Planning a freeze on website changes to merge new designs
On Mon, Jan 11, 2021 at 10:38 AM Brian Hulette 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 > 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 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 >>> >>
Re: Planning a freeze on website changes to merge new designs
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 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 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 >> >
Re: Planning a freeze on website changes to merge new designs
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 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 >
Planning a freeze on website changes to merge new designs
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
