Contributing to Antelopejs

Contributing Guide

This guide will help you contribute to Antelopejs, whether you're a developer, writer, or community member.

Ecosystem Overview

The Antelopejs ecosystem consists of two main repository groups:

Ways to Contribute

Community Support

• Answer questions in GitHub Discussions
• Help with issue triage by reproducing reported bugs
• Share your solutions to common problems
• Provide feedback on new features and proposals

Reporting Issues

Before creating a new issue:

1. For bugs, follow our bug reporting guide
2. For feature requests, check existing issues and discussions
3. Submit module-specific ideas to the relevant repository
4. For broader ideas, start a discussion in the Ideas section

Documentation Improvements

Documentation is critical for user success:

• Fix typos or clarify existing content
• Add missing examples or code samples
• Improve organization or navigation
• Translate documentation to other languages

Pull Request Process

Before Starting

1. Bug fixes: Check if there's an existing issue
2. Features: Open a discussion first to align with project goals
3. Documentation: For typo fixes, consider combining multiple corrections

Development Workflow

1. Fork the repository to your GitHub account
2. Clone your fork to your local machine
3. Create a feature branch with a descriptive name
4. Make changes following the code standards
5. Write tests for new features or bug fixes
6. Ensure all tests pass locally
7. Submit your pull request

Commit Guidelines

We follow the Conventional Commits standard:

<type>(<scope>): <description>

[optional body]

[optional footer]

Common types include:

• feat: (new feature for the user, not a new feature for build script)
• fix: (bug fix for the user, not a fix to a build script)
• docs: (changes to the documentation)
• style: (formatting, missing semi colons, etc; no production code change)
• refactor: (refactoring production code, no behavior changes, eg. renaming a variable)
• test: (adding missing tests, refactoring tests; no production code change)
• chore: (updating grunt tasks etc; no production code change)
• vcs: (version control system related, eg. git)
• ci: (continuous integration related, eg. github actions)
• build: (build system or external dependencies changes, eg. npm, yarn, build related bash scripts)
• utils: (scripts or tools around the project, eg. scripts to generate changelogs)

Examples:

feat(api): add support for custom headers
fix(auth): correct token validation logic
docs(readme): update installation instructions

Pull Request Guidelines

• Use a clear, descriptive title following commit conventions
• Reference related issues in the description (e.g., "Fixes #123")
• Keep each PR focused on a single task or feature
• Respond promptly to reviewer feedback

Decision Making Process

This flowchart guides our PR review process:

Creating Generic Interfaces

If you've built something useful with Antelopejs, consider turning it into a generic interface that others can implement:

Why Create Generic Interfaces?

• Ecosystem Growth: Generic interfaces allow multiple implementations to flourish
• Flexibility: Users can switch between implementations based on their needs
• Collaboration: Different developers can focus on specific implementations
• Standardization: Establishes common patterns across the ecosystem

From Feature to Interface

1. Identify functionality that could benefit from multiple implementations
2. Abstract the core behavior into a clear interface definition
3. Document the interface requirements thoroughly
4. Create a reference implementation as a module

Interface Best Practices

• Keep interfaces focused on a single responsibility
• Design with future extensibility in mind
• Provide detailed type definitions
• Include example usage in documentation
• Reference related interfaces when appropriate

For detailed guidance, refer to our Module documentation and Exporting Interfaces guide.

Proposing RFCs

For significant framework changes:

1. Start by implementing your idea as a module when possible
2. Open a discussion with code examples and rationale
3. If appropriate, your proposal will be marked as an RFC

RFC stages:

• rfc: active - Open for community feedback
• rfc: approved - Accepted by the core team
• rfc: ready to implement - Issue created for implementation
• rfc: shipped - Implemented in a release
• rfc: archived - Not approved but preserved for reference