'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 <[email protected]> wrote: > > > On Wed, Jan 13, 2021 at 9:09 AM Jakub Sadowski <[email protected]> > 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 <[email protected]> >> wrote: >> >>> >>> >>> On Mon, Jan 11, 2021 at 11:00 AM Robert Bradshaw <[email protected]> >>> wrote: >>> >>>> 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. >>>> >>> >>> 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 <[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 >>>>>>> >>>>>>
