Skip to main content

Contributing to FASP QAT Project

Welcome to our GitHub repository! We encourage contributions through issues and pull requests (PRs). However, to maintain the quality and manageability of contributions, we have set up the following acceptance criteria. Adhering to these guidelines helps us process your contributions efficiently and effectively.

Table of Contents​

Introduction​

Contributions are made to this repository via Issues and Pull Requests (PRs). Each form of contribution is welcomed but must adhere to the criteria listed below to maintain the quality and efficacy of the development process.

Issues​

Submitting Issues​

  • Search Existing Issues: Before submitting a new issue, please search the repository to avoid duplicates. Duplicate issues will be closed.
  • Use the Issue Template: Follow the issue template provided. Clearly describe the problem, including steps to reproduce, expected outcome, and actual outcome.
  • Include Relevant Details: Add any relevant information such as screenshots, error messages, and environment details (OS, browser, application version).
  • Label Appropriately: If possible, assign appropriate labels to help categorize the issue (e.g., "bug", "enhancement").

Issue Template​

# Issue Template

## Description
<!-- Provide a clear and concise description of what the issue is. -->

## Steps to Reproduce
<!--
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
-->

## Expected Behavior
<!-- Describe what you expected to happen. -->

## Actual Behavior
<!-- Describe what actually happened. Include screenshots, if applicable. -->

## Environment
- OS: [e.g., iOS]
- Browser: [e.g., Chrome, Safari]
- Version: [e.g., 22]

## Additional Context
<!-- Add any other context about the problem here. -->

Issue Acceptance Criteria​

  • Relevance: The issue should be relevant to the project's current scope and objectives.
  • Clarity: Issues must be clearly defined with sufficient detail for contributors to understand and act on.
  • Reproducibility: If applicable, the issue should be reproducible based on the information provided.
  • Non-Duplicate: The issue should not duplicate an existing issue unless it provides additional information about the same problem.

Pull Requests​

Submitting Pull Requests​

  • Branch Strategy: Create a branch from the main repository for your work. Name your branch in a way that reflects the issue (e.g., fix/issue-number, feature/feature-name).
  • Follow the Coding Standards: Code submitted should adhere to the coding standards set by the project. Format your code properly and include comments where necessary.
  • Include Tests: Where applicable, include unit tests or integration tests to validate your changes.
  • Update Documentation: Update the README.md and other documentation as necessary to reflect your changes.
  • Complete the PR Template: Fill out the pull request template provided by the repository with all required details.
# Pull Request Template

## Description
<!-- Provide a detailed description of what this PR does. -->

## Related Issue
<!-- Mention the issue that this PR addresses. -->

## Motivation and Context
<!-- Why is this change required? What problem does it solve? -->

## How Has This Been Tested?
<!-- Describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran. -->

## Screenshots (if applicable)
<!-- Insert screenshots here. -->

## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)

## Checklist:
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.

Pull Request Acceptance Criteria​

  • Code Review: All submissions must pass code review by at least one maintainer.
  • Continuous Integration: Submissions must pass all CI checks if applicable.
  • Alignment with Project Goals: Changes should align with the overarching goals of the project.
  • No Conflicts: PRs must be free of merge conflicts.
  • Documentation: All changes must be appropriately documented.

Conclusion​

By following these guidelines, you help us maintain the quality and coherence of the project. We appreciate your contributions and look forward to collaborating effectively!