107 lines
3.1 KiB
Markdown
107 lines
3.1 KiB
Markdown
|
# Contributing to FreeSched
|
||
|
|
||
|
Thank you for your interest in contributing to FreeSched! This document provides guidelines and instructions for contributing to this open-source scheduling tool.
|
||
|
|
||
|
## Code of Conduct
|
||
|
|
||
|
Please be respectful and considerate of others when contributing to this project. We aim to foster an inclusive and welcoming community.
|
||
|
|
||
|
## How to Contribute
|
||
|
|
||
|
### Reporting Bugs
|
||
|
|
||
|
If you find a bug in the application:
|
||
|
|
||
|
1. Check if the bug has already been reported in the Issues section
|
||
|
2. If not, create a new issue with a clear title and description
|
||
|
3. Include steps to reproduce the bug
|
||
|
4. Add information about your environment (OS, Node.js version, etc.)
|
||
|
5. If possible, include screenshots or error logs
|
||
|
|
||
|
### Suggesting Features
|
||
|
|
||
|
Have an idea for a new feature?
|
||
|
|
||
|
1. Check if the feature has already been suggested in the Issues section
|
||
|
2. If not, create a new issue with the tag "enhancement"
|
||
|
3. Provide a clear description of the feature and how it would benefit the project
|
||
|
4. If possible, include mockups or examples
|
||
|
|
||
|
### Pull Requests
|
||
|
|
||
|
We welcome contributions via pull requests:
|
||
|
|
||
|
1. Fork the repository
|
||
|
2. Create a new branch for your feature or bugfix (`git checkout -b feature/your-feature-name`)
|
||
|
3. Make your changes
|
||
|
4. Test your changes thoroughly
|
||
|
5. Commit your changes (`git commit -am 'Add some feature'`)
|
||
|
6. Push to the branch (`git push origin feature/your-feature-name`)
|
||
|
7. Create a new Pull Request
|
||
|
|
||
|
### Pull Request Guidelines
|
||
|
|
||
|
- Keep your changes focused on a single issue or feature
|
||
|
- Follow the existing code style and formatting
|
||
|
- Include tests if applicable
|
||
|
- Update documentation as needed
|
||
|
- Make sure all tests pass before submitting
|
||
|
- Provide a clear description of the changes in your PR
|
||
|
|
||
|
## Development Setup
|
||
|
|
||
|
Follow these steps to set up the project for development:
|
||
|
|
||
|
1. Clone the repository
|
||
|
```bash
|
||
|
git clone https://github.com/moeny/freesched.git
|
||
|
cd freesched
|
||
|
```
|
||
|
|
||
|
2. Install dependencies
|
||
|
```bash
|
||
|
npm install
|
||
|
```
|
||
|
|
||
|
3. Start the server
|
||
|
```bash
|
||
|
npm start
|
||
|
```
|
||
|
|
||
|
## Project Structure
|
||
|
|
||
|
- `server.js` - Express server and API endpoints
|
||
|
- `db/` - SQLite database and initialization
|
||
|
- `views/` - HTML templates for admin and public interfaces
|
||
|
- `public/` - JavaScript, CSS, and static assets
|
||
|
- `timepicker-modal/` - Custom timepicker component
|
||
|
|
||
|
## Coding Standards
|
||
|
|
||
|
- Use consistent indentation (2 spaces)
|
||
|
- Follow JavaScript best practices
|
||
|
- Comment your code when necessary
|
||
|
- Keep functions small and focused
|
||
|
- Use meaningful variable and function names
|
||
|
|
||
|
## Testing
|
||
|
|
||
|
Currently, the project does not have automated tests. Manual testing is required before submitting PRs:
|
||
|
|
||
|
1. Test both admin and user interfaces
|
||
|
2. Verify that time slots can be created and booked correctly
|
||
|
3. Test edge cases (invalid inputs, concurrent bookings, etc.)
|
||
|
|
||
|
## Documentation
|
||
|
|
||
|
If you make changes that affect how users interact with the application, please update the README.md accordingly.
|
||
|
|
||
|
## License
|
||
|
|
||
|
By contributing to FreeSched, you agree that your contributions will be licensed under the project's ISC license.
|
||
|
|
||
|
## Questions?
|
||
|
|
||
|
If you have any questions about contributing, feel free to open an issue for discussion.
|
||
|
|
||
|
Thank you for helping improve FreeSched!
|