Timing for site migration

[peterdesmet]

@stanblum @@gkampmeier when would be a good time window to migrate the website? I.e. a moment when there are likely few edits to the website, but either of you can still respond to comments? Anyone else we need to keep in the loop?

@MattBlissett I'll create a separate issue regarding the hosting of the site.

[stanblum]

Right now I'm working on TDWG's legally required financial filings (US federal and State). Deadline is tomorrow. After that, I can devote more attention to the website.

On Mon, Nov 14, 2022 at 9:08 AM Peter Desmet @.***> wrote:

@stanblum https://github.com/stanblum @@gkampmeier https://github.com/gkampmeier when would be a good time window to migrate the website? I.e. a moment when there are likely few edits to the website, but either of you can still respond to comments? Anyone else we need to keep in the loop?

@MattBlissett https://github.com/MattBlissett I'll create a separate issue regarding the hosting of the site.

— Reply to this email directly, view it on GitHub https://github.com/tdwg/website-jekyll/issues/10, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACKZUDMCVXMNODBB5VLYZPDWIJW2HANCNFSM6AAAAAASABKBRU . You are receiving this because you were mentioned.Message ID: @.***>

[gkampmeier]

@peterdesmet if you're looking for the least traffic, I would guess over the winter (Dec) break, but likely any time in December or weekends anytime. I should be around.

[peterdesmet]

Ok, for the actual migration I would actually redo the work I have done here (which could then be considered a test) but on a branch in the website repo. That way we keep a full history.

@timrobertson100 @MattBlissett @ben-norton @stanblum @gkampmeier do you agree with that approach or do you find it unnecessary?

[gkampmeier]

@peterdesmet history is good, but I don't know that my knowledge allows me to know the implications for your development of doing it this way--are there down sides? If not, then safety and ability to see history are generally helpful. :)

[timrobertson100]

@peterdesmet - it would be good to keep a historical copy somehow.

Either by 1) releasing then replacing all content with a new commit or 2) by simply archiving the existing repo so it's available to explore but not edit and swapping over. Both seem reasonable approaches, and perhaps 2 would be simpler for everyone (including looking back in time) due to the disruptive nature of replacing the entire structure.

[peterdesmet]

@timrobertson100 I think for the content (pages and articles), it is at least possible to work in different commits (move, commit, change, commit), so that the history is kept and doesn't look too disruptive.

I can do this on a separate branch in the website repo. I would just have to do it at a time when there aren't many changes to the content of the site. @gkampmeier @stanblum are there many upcoming changes expected?

[gkampmeier]

@peterdesmet not from my end, but it would be helpful if you could declare/define a no-change period. We could then announce this in our next Exec meeting (or take a poll to find out if there are others such as @baskaufs who have intended changes to negotiate). The new year will certainly heat up activity.

[peterdesmet]

I have to do this in spurts in between other things. I'm guessing I can do it in a week, but 3 weeks would be more relaxed. In that time period, changes should ideally be kept to a minimum and communicated with me.

I can likely work on this:

• Nov 21-25
• Dec 5-9
• Jan 3-6

[gkampmeier]

@peterdesmet given that you are "likely" to work on this during three non-consecutive weeks, we can announce the first week, see how far you get and if there are bounds on what we don't want people to do, and just announce this on the website (alert box?) as a no change period, to the Exec (catching 99% of potential website changers). If there were an easy way to suppress the Edit button on pages during this period, this would catch anyone else.

[peterdesmet]

Thanks! All changes come in as pull requests anyway, so there is likely no need to suppress the edit button (but it is possible). I’ll see what I can do next week.

[stanblum]

I think the only thing I will need to do in the near future (next week) will be to upload David Bloom's background and vision statement when he gets back. But even that isn't really critical, since every candidate we have this year is unopposed (or have agreed to co-occupy a role).

On Fri, Nov 18, 2022 at 12:56 PM Peter Desmet @.***> wrote:

Thanks! All changes come in as pull requests anyway, so there is likely no need to suppress the edit button (but it is possible). I’ll see what I can do next week.

— Reply to this email directly, view it on GitHub https://github.com/tdwg/website-jekyll/issues/10#issuecomment-1320513607, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACKZUDKNSKR5HJ3EMK34H6LWI7UORANCNFSM6AAAAAASABKBRU . You are receiving this because you were mentioned.Message ID: @.***>

[peterdesmet]

David Bloom's background and vision statement

This has been uploaded at https://www.tdwg.org/about/executive/nominations/#deputy-chair, but should eventually move to https://www.tdwg.org/about/executive/backgrounds/#deputy-chair

In any case, this issue is about migration timing. The new site has now been launched and all changes that happened in the meantime were incorporated.