Skip to content

Latest commit

 

History

History
142 lines (101 loc) · 8.71 KB

File metadata and controls

142 lines (101 loc) · 8.71 KB

Contribution Guidelines

We value your participation in this open source project. This page will give you a quick overview of how to get involved.

You can contribute to the project in any or all of the following ways:

Resources for New Contributors

  • API Dash Code Walkthrough - Video
  • Getting Started with Flutter - Video
  • API Dash Developer Guide - Read

Code Contribution Guidelines

Why we do not assign issues to anyone?

  • By not assigning issues upfront, anyone can feel welcome to contribute without feeling like the issue is already "taken."
  • This also prevents discouraging new contributors who might feel locked out if issues are pre-assigned.
  • Contributors are encouraged to pick issues that align with their skills and interests. To take initiative rather than waiting for permission or being "assigned" work.
  • Sometimes contributors express interest but never follow through. If issues are assigned prematurely, others might avoid working on them, delaying progress.
  • Leaving issues unassigned ensures that work can proceed without bottlenecks if someone goes inactive.
  • Open issues encourage community discussion and brainstorming. Prematurely assigning an issue can stifle input from others who might have better ideas or solutions.
  • As open-source work is often voluntary, and contributors' availability can change. Keeping issues unassigned allows anyone to step in if the original contributor becomes unavailable. This also supports multiple contributors collaborating on larger or complex issues.

I have not contributed to any open source project before. Will I get any guidance?

In case you are new to the open source ecosystem, we would be more than happy to guide you through the entire process. Just join our Discord server and drop a message in the #foss channel.

Some things to keep in mind before opening a PR

PRs with precise changes (like adding a new test, resolving a bug/issue, adding a new feature) are always preferred over a single PR with a ton of file changes as they are easier to review and merge.

We currently do not accept PRs that involve:

  • Code refactoring without any new feature addition/existing issue resolution.
  • Bumping of dependency versions (SDKs, Packages).

Resolving an existing issue / Adding a requested feature

You can find all existing issues here. A good place to start is to take a look at "good first issues".

Step 1 - Identify the issue you want to work on.
Step 2 - Comment on the issue so that we can discuss how to approach and solve the problem.
Step 3 - Fork the foss42/apidash repo to your account.
Step 4 - Create a new branch in your fork and name it add-feature-xyz or resolve-issue-xyz.
Step 5 - Run API Dash locally (More details here).
Step 6 - Make code changes in the branch.
Step 7 - Once code changes have been made. Make sure you add the relevant tests in the test folder and run tests (More details here).
Step 8 - Open a Pull Request with a clear title and description and add a reference to the issue (#issue-number).
Step 9 - Wait for feedback and review. We will closely work with you on the Pull Request.

Adding a new feature

Step 1 - Open an issue so that we can discuss on the new feature.
Step 2 - Fork the foss42/apidash repo to your account.
Step 3 - Create a new branch in your fork and name it add-feature-xyz.
Step 4 - Run API Dash locally (More details here).
Step 5 - Make the necessary code changes required to implement the feature in the branch.
Step 6 - Once the feature is implemented. Make sure you add the relevant tests in the test folder and run tests (More details here).
Step 7 - Open a Pull Request with a clear title and description and add a reference to the issue (#issue-number).
Step 8 - Wait for feedback and review. We will closely work with you on the Pull Request.

Adding a new test

You can contribute by adding missing/new tests for:

  • Widgets (lib/widgets/)
  • Models (lib/models/)
  • Utilities (lib/utils/)
  • Riverpod providers (lib/providers/)
  • Code generation (lib/codegen/)
  • Services (lib/services/).

Step 1 - Identify the test you want to add or improve.
Step 2 - Fork the foss42/apidash repo to your account.
Step 3 - Create a new branch in your fork and name it add-test-xyz.
Step 4 - Add the test to an existing test file or create a new test file in the test folder.
Step 5 - Run the tests locally (More details here).
Step 6 - Open a Pull Request with a clear title and description of the tests you are adding.
Step 7 - Wait for feedback and review. We will closely work with you on the Pull Request.

General Instructions

What is the supported Flutter/Dart version?

This project supports the latest Dart 3 & Flutter version. If you are using older Flutter version that does not support Dart 3, you might get errors.

In case you are setting up Flutter for the first time, just go ahead and download the latest (Stable) SDK from the Flutter SDK Archive. Then proceed with the Flutter installation.

In case you have already setup Flutter, make sure to switch to stable branch and upgrade it.

How to run API Dash locally?

Check out here

How to run tests?

Check out here

How to add a new package to pubspec.yaml?

Instead of copy pasting from pub.dev, it is recommended that you use flutter pub add package_name to add a new package to pubspec.yaml. You can read more here.

AI Usage Policy

We welcome the responsible use of AI tools (e.g., code assistants, LLMs, copilots) to improve productivity, learning, and developer experience. However, contributors are fully accountable for all submitted work.

Acceptable Use

  • AI tools may be used for ideation, refactoring, debugging, new feature code generation, documentation, and test generation.
  • AI can assist in exploring, but must not replace understanding.

Contributor Responsibility

  • You must understand the code you submit. Do not contribute AI-generated code you cannot explain, maintain, or debug.
  • All contributions must meet the same review bar as human-written code.
  • You are responsible for correctness, security, performance, and maintainability, regardless of how the code was produced.
  • Ensure your contributions comply with our project's license.
  • Do not submit AI-generated content that may:
    • Reproduce copyrighted or proprietary code
    • Violate third-party licenses
    • Include text or code with unclear provenance
  • When in doubt, rewrite the code in your own words or consult maintainers.
  • Review AI-assisted code for:
    • Hidden bugs or incorrect assumptions
    • Security vulnerabilities
    • Inconsistent style or architectural violations
  • If a contribution is AI-assisted, mentioning it in the PR description is encouraged, especially for large or complex changes.
  • You are prohibited from:
    • Blindly copying AI output without review
    • Using AI to bypass project guidelines, reviews, or contributor responsibilities

AI is a tool, not an author. Use it to move faster—but think, verify, and take ownership of what you ship.