[tor-bugs] #33115 [Webpages/Blog]: Migrating the blog to a static web site with Lektor

[Tor Bug Tracker & Wiki]

#33115: Migrating the blog to a static web site with Lektor
---------------------------+----------------------
 Reporter:  hiro           |          Owner:  hiro
     Type:  defect         |         Status:  new
 Priority:  Medium         |      Milestone:
Component:  Webpages/Blog  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:                 |  Actual Points:
Parent ID:                 |         Points:  10
 Reviewer:                 |        Sponsor:
---------------------------+----------------------

Comment (by anarcat):

 Replying to [comment:5 teor]:
 > What's our plan for converting links in old posts?
 > Can links between old blog posts point to the new blog, once the old
 posts have been converted?

 That's always the tricky part in a conversion. I've done Drupal
 "fossilizations" before, which consists of turning a dynamic website into
 a static one. It's an involved process, but it can be done, with enough
 time and tweaking. The result is a static archive of the Drupal site, in
 raw HTML.

 The tricky part is where to put that archive. If we want to keep the
 `blog.torproject.org` domain active with the new lektor site, we'll have
 to do some dance like we did with the main website (move the old website
 to 2019.www.tpo, specifically). I'm not sure that worked very well,
 because it broke a *lot* of links and we didn't have good mechanisms to
 redirect to the older site on the new one.

 Could we consider creating the new site on a new domain, say
 `news.torproject.org`?

 > Is there a proof of concept somewhere, that we could look at?
 > Or are we not at that stage yet?

 ... but yeah, maybe we're getting ahead of ourselves a little here. As far
 as I know, we haven't resolved those questions yet and there's no proof of
 concept. But those are excellent questions!

 Replying to [comment:6 arma]:
 > Do we have anybody on our side with real in-depth experience in managing
 discourse communities? [... notes about the limitations of stack exchange
 and reddit ...]
 > do we have a plan for how this time will be different? Delegating our
 community moderation to a third party platform means giving the control to
 steer topics to...whom exactly?

 The key difference between Reddit/Stackexchange and "our own discourse
 instance" (whether it's self-hosted or hosted at discoursehosting.net, as
 we plan to do) is that we would be admins of the instance, which is not
 the case of the other communities. We would have the final say in what's
 in and what's out, the same way we do right now with the blog comments.
 Although...

 >  At least with the current blog case, it fails closed when we spend a
 while not giving it attention, rather than failing open by going off in
 some surprising and unhelpful direction.

 ... I am not familiar with how blog moderation works now. If it's "a
 priori moderation" (ie. that a comment does not show up before it's
 approved), that might be difficult to replicate in Discourse. But I'm not
 too worried about this: Discourse is specifically built to help manage a
 more healthy forum community, and I'm hopefully we can build one with
 existing staff resources (who currently moderate the blog) and possibly
 even community people (who would be promoted within the normal Discourse
 process)....

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33115#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online