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 <jakub.sadow...@polidea.com> 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 <bhule...@google.com> > 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 <bhule...@google.com> >>> wrote: >>> >>>> >>>> >>>> On Mon, Jan 11, 2021 at 11:00 AM Robert Bradshaw <rober...@google.com> >>>> wrote: >>>> >>>>> On Mon, Jan 11, 2021 at 10:38 AM Brian Hulette <bhule...@google.com> >>>>> 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 <rober...@google.com> >>>>>> 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 <g...@apache.org> >>>>>>> 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 >>>>>>>> >>>>>>> -- Agnieszka Sell Polidea <https://www.polidea.com/> | Project Manager M: *+48 504 901 334* <+48504901334> E: agnieszka.s...@polidea.com [image: Polidea] <https://www.polidea.com/> Check out our projects! <https://www.polidea.com/our-work> [image: Github] <https://github.com/Polidea> [image: Facebook] <https://www.facebook.com/Polidea.Software> [image: Twitter] <https://twitter.com/polidea> [image: Linkedin] <https://www.linkedin.com/company/polidea> [image: Instagram] <https://instagram.com/polidea> Unique Tech Check out our projects! <https://www.polidea.com/our-work>
