Thank you for your interest in contributing to the Global Type System (GTS) Viewer! This document provides guidelines and information for contributors.
- Git for version control
- VS Code (optional, for testing the VS Code plugins)
# Clone the repository
git clone <repository-url>
cd gts-viewergit checkout -b feature/your-feature-nameUse descriptive branch names:
feature/add-event-examplesfix/schema-validation-errordocs/clarify-chaining-rulesspec/minor-version-compatibility
Follow the specification standards and patterns described below.
- Run and test the web version
- Run and test the Electron version
- Build the VS Code plugin, load and test it
Follow a structured commit message format:
<type>(<module>): <description>
<type>: change category (see table below)<module>(optional): the area touched (e.g., spec, examples, schemas)<description>: concise, imperative summary
Accepted commit types:
| Type | Meaning |
|---|---|
| spec | Specification changes or clarifications |
| fix | Bug fixes in schemas or examples |
| feat | New feature |
| tech | Technical change or refactoring |
| docs | Documentation updates |
| examples | Adding or updating example schemas/instances |
| test | Adding or modifying validation tests |
| style | Formatting changes (whitespace, JSON formatting, etc.) |
| chore | Misc tasks (tooling, scripts) |
| breaking | Backward incompatible specification changes |
Examples:
feat(vscode): implement diagram reload on VS Code file save event
fix(schemas): fix the schame parsing
Best practices:
- Keep the title concise (ideally < 50 chars)
- Use imperative mood (e.g., "Fix schema", not "Fixed schema")
- Make commits atomic (one logical change per commit)
- Add details in the body when necessary (what/why, not how)