Want to contribute to the project but don't know where to start? You can help contribute in the following ways:

1. Create a PR
2. Use the project
3. Share the project
4. Raise an issue
5. Start a discussion
6. Get in touch

Please follow common-sense in terms of conduct. A good example of common-sense conduct we follow is the contributor covenant. Issues with conduct will be handled by core maintainers.

In order of impact on the project, you can contribute in the following ways

This project is welcome to code contributions. If you'd like to make such a contribution you can fork the repository, create a new branch from main, and submit a pull-request with your changes.

The most useful ways you can contribute code for the first time is in order of the following

1. Pick up a good first issue. These issue will usually have a straightforward approach and help you get hands-on with the basics of the project.
2. Pick up a bug. These issues may not be straightforward, but can likely be completed without relying on a core maintainer's direction
3. Pick up an issue. If the issue doesn't match one of the above listed, please reach out for guidance from a core maintainer as there may be some nuance in the approach that should be taken.
4. Update documentation. If you believe some docs or markdown needs updating, you're welcome to contribute updates

Please reconsider how useful the following may be to the project, as they may require a maintainer to review and may not be appropriate for the direction of the project.

1. Refactoring
2. Benign typo fixes
3. Self-promotion

Using the project is a great way to help the project. You may discover issues or spark discussions based on your usage, which will help the project gain a shape that's useful to more and more people!

If you like the project and want to see it grow then share it with your friends and coworkers. This will help the project gain more users and therefore more feedback which helps continue to improve the project!

If you think a feature of OXVG is broken or missing, you're welcome to raise an issue. Please keep in mind that whether an issue is picked up or closed is up the the discretion of maintainers.

If you have an idea, question, or something to show off then you can create a discussion.

If you want to get in touch with a maintainer, the best way to do so is to join the discord. You can also reach out to a maintainer by email if you prefer to keep a conversation private.

If you want to get in touch regarding an issue or discussion the best way to do so is through GitHub, so that users can easily search and discover them if they also have the same questions.

All build steps can be completed using either cargo or pnpm.

To build crates, you can run cargo build; and to build packages, you can run pnpm run build.

• Keep non-essential dependencies behind feature flags
• Use log for debugging messages that will be omitted in release compilations
• Use cargo bloat for finding large functions
• Use cargo tree for finding unexpected dependencies
• Use -Zprint-type-sizes or top-type-sizes for finding large types (which I assume affect the size of match <enum>)
  • Large types can be Box-ed to the heap, if it has little/no effect on runtime performance

Resources

• Zeforschen: Optimising Rust binary size
• Johnthagen: Minimizing Rust Binary Size

Behavior should be a best effort to follow the SVG 1.1 and SVG 2 spec. Any deviations should be pointed out in documentation and comments. Where the two specs conflict, SVG 2 should be preferred.

These resources are informative specs and can be used to guide development

• SVG 1.1 Element Index
• SVG 1.1 Attribute Index
• SVG 1.1 Property Index
• SVG 2 Element Index
• SVG 2 Attribute Index
• SVG 2 Property Index

Automated releases have a strict set of criteria to ensure only authorised releases are allowed

• push must be on main; and
• push commit message must be a version (e.g. 0.0.1-1); and
• push tag must be a version (e.g. v0.0.1-1)

Automated releases will do the following

• Publish npm packages from workflow artifacts
• Publish binary artifacts from workflow to release page

Cargo releases are done manually using cargo login followed by cargo release <level|version> --no-tag --no-push --workspace

These resources can be used for codegen

• SVG 1.1 Definitions
• SVG 2 Definitions
• VNU Definitions