remove misleading "suggest changes" link

[mauke]

At the bottom of https://pvp.haskell.org/#related it says:

If you'd like suggest changes, please open an issue on GitHub.

But that doesn't do anything in practice because changes suggested on github are only made on Github; they don't make it to the website. For example, PR #20 from 2018 contained a bugfix that corrects a nonsensical suggestion in the flowchart diagram, but the website still hasn't been updated.

In practical terms, there is no way to get changes into the published PVP, so the Github issue suggestion should be removed.

[tomjaguarpaw]

Isn't this proposal self-defeating? If your suggested change ever makes it to the website then that can only be because we've found a way of making changes to the GitHub repo make it to the website!

I suggest we just work out how to deploy changes to the website.

[gbaz]

The clc has day-to-day responsibility over the PVP. Whenever it wants to publish a new version, it should request the admin team help. Also we'd be happy to set up a more consistent sync if preferred.

[Bodigrim]

@gbaz I think the easiest way to sync would be to set up GitHub Pages for this repository and point pvp.haskell.org to them. Does it sit well with you?

[gbaz]

i'm fine with that i suppose. i keep saying that uploading files is not hard and its how we always used to do things back in the day, but... whatever. if you setup github pages i can handle the dns redirect for it.

[hasufell]

Given that we deploy once every other decade, I'm not sure what this automation gives us. Instead, it'll likely make it a little harder to do "releases“ properly, no? We don't want to upload everything that's merged immediately, or do we?

[tomjaguarpaw]

I think we ought to have at least some branch (or tag) which indicates "latest version of PVP approved for release by CLC". I also think we ought to have very clear specified steps about what steps are required for a "release", ending up with https://pvp.haskell.org displaying the contents of that release.

Based on my experience¹ of using GitHub Actions to https://www.haskell.org deploy automatically on merge to master, and to deploy my personal site https://h2.jaguarpaw.co.uk/ on GitHub Pages via push to a specific repo, I can recommend using GitHub Actions and GitHub pages to be the way we specify the steps involved in "release" (with the bonus that the specification is executable).

Footnotes

1. jointly with @TikhonJelvis ↩

[Bodigrim]

Given that we deploy once every other decade, I'm not sure what this automation gives us. Instead, it'll likely make it a little harder to do "releases“ properly, no? We don't want to upload everything that's merged immediately, or do we?

• There are technical changes which we'd rather release immediately such as Fix #39 (Link to logo is dead) #61.

• I'd like to have a page with PVP 1.1 work-in-progress available for public reference, and this one can benefit from reflecting changes immediately as well.

• We indeed do not plan to change PVP 1.0 ever, so syncronizing it with Git can do no harm.