Thank you for your interest in contributing to Uniword. This page covers the contribution workflow, code of conduct, and pull request process.

1. Code of Conduct

By participating in this project, you agree to maintain a respectful and inclusive environment for all contributors.

2. Development Workflow

The typical contribution workflow is:

  1. Create an issue or comment on an existing issue

  2. Fork and clone the repository

  3. Create a feature branch (feature/my-new-feature)

  4. Implement the feature with tests

  5. Run tests and RuboCop

  6. Update documentation

  7. Commit with a semantic message

  8. Push and create a pull request

  9. Address review feedback

  10. Merge when approved

3. Commit Messages

Use semantic commit messages:

<type>(<scope>): <subject>

<body>

<footer>

3.1. Types

Type Usage

feat

New feature

fix

Bug fix

docs

Documentation changes

style

Code style changes (formatting)

refactor

Code refactoring

test

Adding or updating tests

chore

Build process or auxiliary tool changes

3.2. Examples 

feat(tables): add cell merging support

Implement horizontal and vertical cell merging for tables.
Includes new TableCell#merge_horizontal and #merge_vertical methods.

Closes #123
fix(docx): correct paragraph spacing serialization

Fix issue where spacing_before was not properly serialized
to OOXML format.

Fixes #456

4. Pull Request Process

4.1. Before Submitting

  1. Ensure all tests pass: bundle exec rspec

  2. Ensure RuboCop compliance: bundle exec rubocop

  3. Update documentation (YARD docs, README.adoc, examples)

  4. Update CHANGELOG.md under the "Unreleased" section

4.2. PR Guidelines

  • One feature per PR — Keep PRs focused and manageable

  • Clear description — Explain what and why

  • Tests included — All new code must have tests

  • Documentation updated — Keep docs in sync with code

  • Clean commit history — Squash commits if needed

  • Responsive to feedback — Address review comments promptly

5. Reporting Bugs

Before reporting, check if the issue already exists and verify it with the latest version. Include:

  • Clear description of the bug

  • Steps to reproduce

  • Expected vs. actual behavior

  • Environment details (Ruby version, gem version, OS)

6. Feature Requests

Before requesting, check if the feature already exists and search for similar requests. Include:

  • What problem the feature solves

  • Proposed solution

  • Alternatives considered

7. License

By contributing, you agree that your contributions will be licensed under the same license as the project (BSD 2-Clause License).