[meta] Old issues/comments sedimentation

[karlcow]

This issue is a space for discussing a possible evolution of the project for both its resilience and its performance.

@miketaylr shared with me this blog post, discussing the use of a bot for closing issues automatically after a certain time or status. This has interesting potentials in terms of maintenance.

One benefit of using this would be to create a static archive of old issues. Once an issue has been locked it would be possible to download all its assets and generate a static copy (be static html or static json).

Drifting 🛶 I have a tendency to prefer the static html because it preserves the old design and there's something interesting about this related to the fabric of time and history in a project. But this is more philosophical and a separate discussion.

Back on track 🛤 That could be the opportunity of a nice hacking week (ala milestones).

Some related discussions:

• https://github.com/webcompat/webcompat.com/issues/2393#issuecomment-381441555
• #611
• #165

[miketaylr]

I think once an issue has been closed, we could lock it 1 or 2 weeks later. It would be cool to have a message for locked issues as well, like "this issue is locked, please file a new bug if you're experiencing something similar", etc.

[marimeireles]

It would be cool to have a message for locked issues as well, like "this issue is locked, please file a new bug if you're experiencing something similar", etc.

Yes, for new closed issues. Maybe we could use some relevant labels, like outdated, as they're suggesting on the text.

One benefit of using this would be to create a static archive of old issues. Once an issue has been locked it would be possible to download all its assets and generate a static copy (be static html or static json).

Just out of curiosity, why would we want to build an archive of old issues?

[karlcow]

Just out of curiosity, why would we want to build an archive of old issues?

Once we have an archive of old issues. We just get a simple HTML rendered version of the page. No request to GitHub necessary, no JSON parsing for rebuilding the page. Everything is here once and for all. We gain speed, less requests latencies, etc. , and we make it more resilient to time.

[marimeireles]

@miketaylr we forgot to talk about this issue. What do you think? Is this issue more relevant than https://github.com/webcompat/webcompat.com/issues/2743?

We just get a simple HTML rendered version of the page.

Hmm.. @karlcow you mean we would download only the HTML file? Wouldn't that cause compatibility issues if we have like a really old template and try to render it in a new completely different code from the future?

[karlcow]

Personally I don't think there will be time for this. It's a very interesting project, but tough to resolve.

if we have like a really old template and try to render it in a new completely different code from the future?

That's a good question. Probably you need to think about it as a solidified version of an issue. Something which becomes enshrined in the ground like a mommy in a pyramid. They do not change clothes anymore. So basically, a very simple template with all the textual information and minimum links back to the main areas. There would be nothing actionable for changing status, adding comments.

(as for new templates, my blog is exactly like that, I kept all the pages with their old templates for the last 18 years. New design iterations apply only to the new pages.)

[marimeireles]

mommy in a pyramid

ahahaha

(as for new templates, my blog is exactly like that, I kept all the pages with their old templates for the last 18 years. New design iterations apply only to the new pages.)

Cool! I also wanna do that. I don't like my current design, but I want to keep it, because I loved it some day in the past.

So basically, a very simple template with all the textual information and minimum links back to the main areas.

Okay... It'd be better to do that using a json, then... Wouldn't it? I don't know how we'd do that using the HTML.

[miketaylr]

Okay... It'd be better to do that using a json, then... Wouldn't it? I don't know how we'd do that using the HTML.

The idea is that these would be static snapshots of only HTML (perhaps with inline CSS, or linking to a historical CSS file, either would have pros and cons). So we wouldn't need any JS (or JSON) on such a page. It's a read-only archive.

[miketaylr]

One benefit of using this would be to create a static archive of old issues. Once an issue has been locked it would be possible to download all its assets and generate a static copy (be static html or static json).

I did some thinking about @karlcow's suggestion here and would like to try it out (in my spare time / hours) over the next few weeks. Not high priority stuff, but I think it could be a nice improvement.

Here's what I think needs to happen, I'll spin them out into issues when I start working on it:

• [x] convert issue page to be server (python) rendered. we can keep new comments in JS, but rendering of all issue data should come as HTML from the server. #3281
• [x] render issue comments from server side
• [ ] write some methods to manually render issue template outside of flask context
• [ ] create a webhook (or github app) to listen for lock events on issues to call into previous methods
• [ ] write HTML to disk, somewhere
• [ ] figure out how to determine if we serve the page from our static HTML cache, or fetch the data from github + render. possibly each issue request checks a db table which records is_archived or something.