Roadmap page

[laymonage]

How to run

• Checkout the branch
• Might need to run make setup to ensure your local build (if any) is up to date with the latest dependencies
• Follow the instructions on the README
  • make start, make runserver, make migrate, make pull-production-data, make pull-production-media, make superuser
• Create a new GitHub personal access token
  • https://github.com/settings/tokens/new https://github.com/settings/personal-access-tokens/new
  • No access is necessary at all, leave all options unchecked
  • Note that the "Fine-grained personal access tokens" does not work with the GraphQL API (see docs), so use "Personal access tokens (classic)" instead
  • EDIT: This just in! https://github.blog/changelog/2023-04-27-graphql-improvements-for-fine-grained-pats-and-github-apps/
• Edit settings/local.py and set GITHUB_ACCESS_TOKEN = "ghp_foobar"
• Open the website's Wagtail admin, go to Settings > GitHub Roadmap > Import all milestones
• Open the v5.1 milestone
• Uncheck the Publish field on the "Provisional version number" item
• Add this link to the Treeless item
• Go to Settings > Redirects and delete/update the /roadmap redirect
• Create a new Roadmap page under the Home page
• Fill out the form
  • Sponsorship page: choose the "Sponsor Wagtail" page
  • Fine print:

    Future version numbers are provisional - these may receive a major version number increment, depending on the extent of backwards-incompatible changes and significant UI differences.

  • Body: add a standalone CTA block
  • CTA text: Sponsor Wagtail
  • CTA page: choose the "Sponsor Wagtail" page
  • Short description:

    Help build Wagtail enhancements and support the long-term health of the project

Notes

We should think about how the access token should be created for production.

The most proper way to do this would be to create a GitHub App under the Wagtail organisation, and then authenticate as the app. However, this is much more complicated as we'll need to:

• Create a GitHub App
• Generate a JWT
• Use the JWT to generate an access token as a GitHub App installation.
• Use the token in our GraphQL requests.
  • This access token expires in 1 hour, so this would need to be generated on-the-fly. This means that instead of storing the token in the environment variable, we would need to store the App ID and the App's private key instead, so that we can generate the JWT at runtime.

Alternatively, the much easier way would be to use someone's account (or an empty account) to generate a personal access token without any access, which I've done here.

EDIT: Now that fine-grained access tokens can be used on the GraphQL API, we can create an access token with the Wagtail organisation as the owner, and with read-only access to public repositories (without any permissions configured).

[laymonage]

@thibaudcolas I've made adjustments per your review:

• Removed the publish fields. We don't need this after all, as the solution to the "Provisional version number" thing is easy: just don't add it to the Milestone. It can still be added to the Project if we want to.
• Added the intro field and use the hero.html template
• Added the semibold weight only, without the variable font file.
• Made the whole milestone item heading area clickable.
• Added the option to input a GitHub access token during import.
• Removed the option to import all milestones. Only 20 latest open milestones are imported, plus the "Future" milestone fetched in a separate query (still in the same request) to avoid sorting by due date issues.
• Fixed accessibility issues and made other refactoring/improvements as mentioned.

[laymonage]

All looking great! Only thing I’d have suggested doing differently is to combine the migrations so it looks neater, but doesn’t really matter for a project of this size.

Thanks! I considered doing that but I thought it would make it harder for you to do another review as you’d need to make sure it could be run locally after the initial migration 😅