Contribution Guidelines

Thank you for contributing to Power Ampache 2! To ensure high-quality contributions, please follow these guidelines, including adhering to Clean Architecture and SOLID principles, and specific instructions about branching and merging.

Branching and Merging Process

1. Branching:
   • Branch from dev: Always branch out from the dev branch. This helps keep the main branch stable and ensures that new features and fixes are integrated smoothly.

   git checkout dev
   git pull origin dev
   git checkout -b feature/your-feature-name
               

2. Making Changes:
   • Follow Clean Architecture and SOLID principles as described below.
3. Commit Changes:
   • Use descriptive commit messages that reflect adherence to Clean Architecture and SOLID principles:

   feat: add user authentication functionality with SRP and OCP
   
   Implemented user authentication logic following SRP and OCP principles.
               

4. Push Changes:
   • Push your changes to your fork:

   git push origin feature/your-feature-name
               

5. Create a Pull Request (PR):
   • Open a pull request against the dev branch. Clearly describe how your changes follow Clean Architecture and SOLID principles, and provide any relevant details about your implementation.
   • Issue Tracker Requirement: Do not create PRs for changes that do not have a corresponding issue in the issue tracker. If you wish to work on something that is not listed, please create an issue first and wait for a response before starting your work. This ensures that the project scope is managed effectively and avoids unnecessary work.
6. Review Process:
   • Review: All PRs will be reviewed to ensure compliance with Clean Architecture, SOLID principles, and project standards.
   • Approval: Once reviewed, your PR will be approved and merged into dev by the maintainers.
7. Merging into main:
   • Merge into main: Only the project maintainer (you) has the authority to merge changes from dev into the main branch. This ensures that the main branch remains stable and release-ready. After thorough testing and review in the dev branch, you will handle the final merge into main.

Adhering to Clean Architecture and SOLID Principles

1. Clean Architecture:
   • Domain Layer:
     • Purpose: The Domain Layer is the core of the application, encapsulating business logic and domain rules.
     • Components:
       • Entities: Fundamental objects representing core business logic and rules. These should be independent of external systems.
       • Aggregates: Collections of related entities treated as a single unit for data changes, helping to enforce business rules and maintain consistency.
       • Domain Services: Provide business logic that doesn’t fit naturally within a single entity or aggregate. They often involve multiple entities and encapsulate domain-specific operations.
       • Repository Interfaces: Define methods for accessing and persisting aggregates and entities. Implementations of these interfaces should be in the Data Layer.
     • Data Classes: Define data structures specific to the Domain Layer, such as Entities and Aggregates, that encapsulate the core business logic and rules.
   • Data Layer:
     • Purpose: Handles data persistence and interacts with the database.
     • Components:
       • Repository Implementations: Provide concrete implementations of the repository interfaces defined in the Domain Layer.
       • Database Entities: Map database structures to application models.
     • Data Classes: Define data structures specific to the Data Layer, such as database entities and data transfer objects (DTOs), to facilitate communication with the database and external data sources.
   • Interface Adapters:
     • Purpose: Adapt data between the Domain Layer and external systems (e.g., web frameworks, APIs).
     • Data Classes: Define data structures for communication between the Domain Layer and external interfaces, such as API request/response models.
   • Frameworks and Drivers:
     • Purpose: Include external tools and frameworks interacting with the Interface Adapters.
     • Data Classes: Define data structures specific to external tools and frameworks, which should be isolated from the core business logic.
   • Player Package:
     • Purpose: All functionality specific to the music player should reside in the player package.
     • Components: This includes any classes, interfaces, and data structures directly related to music playback, such as media controls, audio management, and player state handling.
2. SOLID Principles:
   • Single Responsibility Principle (SRP): Each class/module should have only one responsibility.
   • Open/Closed Principle (OCP): Classes/modules should be open for extension but closed for modification.
   • Liskov Substitution Principle (LSP): Derived classes should be substitutable for their base classes without altering the correctness of the program.
   • Interface Segregation Principle (ISP): Use specific interfaces rather than general-purpose ones.
   • Dependency Inversion Principle (DIP): Depend on abstractions rather than concrete implementations.

Library Management

1. Adding New Libraries:
   • Discussion Required: Before adding any new libraries, discuss it with the project leader. This ensures that new dependencies align with the project's goals and do not introduce unnecessary complexity or compatibility issues.
2. Updating Existing Libraries:
   • Approval Needed: Any updates to existing libraries must be communicated with the project leader. This helps maintain stability and compatibility across the project and ensures that updates do not introduce unforeseen issues.

Coding Standards

• Style: Follow the coding style specified in our STYLE_GUIDE document.
• Documentation: Update documentation to reflect changes, ensuring consistency with Clean Architecture and SOLID principles.
• Testing: Write comprehensive tests and ensure your changes do not break existing functionality.

Reporting Issues

For bugs or feature requests, please open an issue with detailed information, including steps to reproduce and relevant context.

Code of Conduct

Adhere to our Code of Conduct to maintain a positive and respectful environment.

License

By contributing, you agree that your contributions will be licensed under the GPLv3 license.

Additional Resources

• Project Documentation
• Contribution Documentation
• Community Guidelines

Thank you for your contribution!