Most wanted contributions

Known bugs and wanted features.

TEMPLATE: clear items and add items for your project.

Required

  1. base: Add an Open Collective badge.

  2. (js|ts|etc.): Restore general and module Sphinx indexes in the branches for appropriate project types.

  3. ci: Built docs formats as artifacts and release files.

  4. ci: Publish Sphinx docs to all available documentation hosts.

High priority

  1. Any documentation improvements:

    Docs benefit most from fresh eyes. If you find anything confusing, ask for help. When you understand better, contribute changes to the docs to help others.

Nice to have

  1. base: Better final release notes when nothing changed after the last pre-release.

  2. base: Homebrew formula and badge

  3. base: Try out other Sphinx themes

  4. base: Try some of the linters and formatters supported by UniBeautify:

  5. base: Try out the rinohtype Sphinx renderer.

  6. base: Build operating system packages, such as *.deb, *.rpm, *.msi, including documentation.

  7. base: Add a badge for projects that publish packages to more than one repository.

  8. docker: Docker image build-time labels:

    org.opencontainers.image.revision
org.opencontainers.image.ref.name
org.opencontainers.image.base.digest

  9. docker: Container image variants, for example *:slim or *:alpine:

    The might save less disk space than by using the most widely used base image, given that different images share common image layers. This might also have security benefits but it also increases risk of incompatibility bugs, whether in the libraries or in distribution differences. As such, this probably isn’t worth the effort until users report convincing use cases.

  10. docker: CI/CD for other image platforms:

    This would cause one issue with CI resources. The pipelines already exhaust too much of the GitLab free CI/CD minutes for each run. Running the tests in ARM images would either consume even more free CI/CD minutes to run on cloud ARM runners. Or would take forever by using emulation in the dedicated project runners.

    Docker also lacks important support, creating another issue. Docker provides both the capability to build images for non-native platforms and run images for non-native platforms, both under QEMU emulation, albeit with a significant performance penalty. It seems support exists to build a non-native image, run the tests in it, and then publish it after passing. But Docker doesn’t support local access to built multi-platform images, it only supports pushing them to a registry or exporting them to some form of filesystem archive. This means following runs of the image tag might use a different image than the one built locally. Someone else could have pushed another build to the registry between the push and following pull. Even worse, changing the platform: ... in ./docker-compose*.yml requires a $ docker compose pull ... to switch the image. This means pulling again and again some time after the push increasingly the likelihood of pulling an image other than the one built locally. This leaves a couple options. Parse the build output to extract the manifest digest and then use that to retrieve the digests for each platform’s image and then use those digests in ./docker-compose*.yml. Or output the multi-platform image to one of the local filesystem formats, figure how to import from there and do a similar dance to retrieve and use the digests. This would be fragile and would take a lot of work that is likely wasted effort when Docker or someone else provides a better way. IOW, these options would mean wastefully fighting tools and frameworks.

    As such, this probably isn’t worth the effort until users report significant platform-specific bugs.

  11. ci: Add self-hosted Matrix Hookshot to the ./docker-compose.override.yml, add the GitLab integration and document any steps for template adopters.