CONTRIBUTING.md•3.84 kB
# Contributing to Feishu Project MCP Service
We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
## Development Process
We use GitHub to host code, to track issues and feature requests, as well as accept pull requests.
1. Fork the repo and create your branch from `main`.
2. If you've added code that should be tested, add tests.
3. If you've changed APIs, update the documentation.
4. Ensure the test suite passes.
5. Make sure your code lints.
6. Issue that pull request!
## Pull Request Process
1. Update the README.md with details of changes to the interface, if applicable.
2. Update the docs/ directory with any new documentation.
3. The PR will be merged once you have the sign-off of at least one other developer.
## Any Contributions You Make Will Be Under the MIT Software License
In short, when you submit code changes, your submissions are understood to be under the same [MIT License](LICENSE) that covers the project. Feel free to contact the maintainers if that's a concern.
## Report Bugs Using GitHub's [Issue Tracker](../../issues)
We use GitHub issues to track public bugs. Report a bug by [opening a new issue](../../issues/new); it's that easy!
## Write Bug Reports with Detail, Background, and Sample Code
**Great Bug Reports** tend to have:
- A quick summary and/or background
- Steps to reproduce
- Be specific!
- Give sample code if you can.
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
## Use a Consistent Coding Style
- Use TypeScript for all code
- Run `npm run lint` to conform to our lint rules
- Run `npm run format` to format code according to our style
- Write tests for new functionality
## Code Review Process
The core team looks at Pull Requests on a regular basis. After feedback has been given we expect responses within two weeks. After two weeks we may close the PR if it isn't showing any activity.
## Community
- Join our [Feishu Group](https://your-feishu-group-link)
- Participate in our [GitHub Discussions](../../discussions)
## Testing
We have a handful of unit tests and integration tests. Please write tests for new code you create.
### Running Tests
```bash
# Run all tests
npm test
# Run tests with coverage
npm run test:coverage
# Run tests in watch mode
npm run test:watch
```
## Documentation
We use TypeDoc for API documentation and Markdown for general documentation.
### Generating Documentation
```bash
# Generate API documentation
npm run docs
# Serve documentation locally
npm run docs:serve
```
## Commit Messages
We follow the [Conventional Commits](https://www.conventionalcommits.org/) specification. This leads to more readable messages that are easy to follow when looking through the project history.
### Commit Message Format
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**:
```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```
### Type
Must be one of the following:
- **feat**: A new feature
- **fix**: A bug fix
- **docs**: Documentation only changes
- **style**: Changes that do not affect the meaning of the code
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **perf**: A code change that improves performance
- **test**: Adding missing tests or correcting existing tests
- **chore**: Changes to the build process or auxiliary tools and libraries
## License
By contributing, you agree that your contributions will be licensed under its MIT License.