Skip to content

Latest commit

 

History

History
70 lines (49 loc) · 3.62 KB

CONTRIBUTING.md

File metadata and controls

70 lines (49 loc) · 3.62 KB

Contributing to the Sentiment Analysis API

We welcome contributions to this project! To help you get started, here are some guidelines to follow when contributing to this repository.

How the Project is Structured

This project follows a layered architecture for better maintainability and readability. When contributing, please follow the conventions for each layer.

1. Data Layer

What to Modify:

  • Code related to fetching and storing data (e.g., external API calls, database interactions).
  • If you're adding a new data source or modifying an existing one, this is the layer to focus on.

Things to Keep in Mind:

  • Ensure data validation and error handling is implemented correctly.
  • Keep data access logic isolated from other layers to promote separation of concerns.

2. Model Layer

What to Modify:

  • The logic for processing or transforming data.
  • If you're adding new business logic, algorithms, or data models, they should go here.

Things to Keep in Mind:

  • Follow existing naming conventions for model classes.
  • Ensure that business logic is encapsulated in the model layer and kept separate from data access logic.

3. Service Layer

What to Modify:

  • Code that orchestrates the interaction between the model and the routes layer.
  • If you're adding new services like sentiment analysis, text preprocessing, or any other domain-specific functionality, this is the place to do it.

Things to Keep in Mind:

  • Ensure that services are reusable and abstracted from the route layer.
  • Keep service methods focused on specific tasks (e.g., text analysis, API calls, etc.).

4. Routes Layer

What to Modify:

  • The routes that define the API endpoints.
  • If you’re adding a new API route or modifying an existing one, this is the layer where you’ll define the new or updated route.

Things to Keep in Mind:

  • Routes should handle HTTP requests, pass data to services, and return appropriate responses.
  • Ensure all routes are documented clearly, and handle errors gracefully.

How to Contribute

  1. Fork the repository: Fork the project to your own GitHub account and clone it to your local machine.
  2. Create a branch: Always create a new branch for your feature or bug fix. Use descriptive names for branches (e.g., feature/add-sentiment-service or bugfix/fix-model-validation).
  3. Make changes: Implement your changes to the appropriate layer following the guidelines above.
  4. Write Tests:
    • Ensure that you write unit and integration tests for the new functionality or bug fixes.
    • Unit tests should be placed in the corresponding test directories under /tests/unit/.
    • Integration tests should be placed in /tests/integration/.
  5. Commit your changes: Commit your changes with a meaningful commit message explaining what was changed and why.
  6. Push your changes: Push your changes to your forked repository and create a pull request (PR) to the main repository.
  7. Review and Feedback: The project maintainers will review your pull request and provide feedback. Please be open to changes and follow the feedback.

Code Style Guidelines

  • Follow Python's PEP 8 style guide.
  • Write clear, descriptive docstrings for functions and classes.
  • Ensure that your code is well-tested and passes all tests before submitting a pull request.

Why This Structure Helps

By following the structure outlined above, contributors will ensure the project maintains a clear separation of concerns, making it easier to maintain and extend in the future. Each layer is responsible for a specific aspect of the application's functionality, and changes should be made to the appropriate layer.