Thank you for your interest in contributing! This document covers how to get the project running locally, the conventions we follow, and how to submit changes.
- Getting Started
- Development Workflow
- Code Conventions
- Localization
- Submitting a Pull Request
- Reporting Bugs
- Feature Requests
- Flutter ≥ 3.3.3
- An Appwrite project (cloud or self-hosted) — see README.md for the required schema
- Optional: a PostHog project for analytics
git clone https://github.com/oluwasniper/Stagen.git
cd Stagen
flutter pub get
cp .env.example .env # fill in your Appwrite / PostHog values
cp .vscode/launch.json.example .vscode/launch.json # optional, for VS CodeRun the app:
make run
# or
flutter run --dart-define-from-file=.env-
Fork the repository and clone your fork.
-
Create a branch from
mainwith a descriptive name:git checkout -b fix/scanner-crash git checkout -b feat/export-csv
-
Make your changes (see conventions below).
-
Run the analyzer and tests before pushing:
flutter analyze flutter test -
Open a pull request against
main.
| Area | Convention |
|---|---|
| State management | flutter_riverpod — StateNotifier for mutable state, Provider for services |
| Inside notifiers | _ref.read(provider) — never watch |
| Routing | go_router; path constants in lib/utils/route/app_path.dart, name constants in lib/utils/route/app_name.dart |
| Secrets | Never commit secrets. All credentials are passed via --dart-define-from-file=.env at build time |
| Constant namespaces | abstract final class (e.g. TelemetryEvents) |
| Secure storage keys | Define as constants in a private _Keys class inside the relevant file |
| Telemetry calls | Always fire-and-forget with .catchError — never let analytics crash the app |
| PR scope | One feature or bug fix per PR |
Follow the existing style in the file you are editing. Run flutter analyze and fix any warnings before opening a PR.
The app supports English, Spanish, French, and Portuguese via Flutter's gen-l10n tooling.
-
ARB files live in lib/l10n/.
-
app_en.arbis the source of truth — add new strings there first. -
Add the corresponding translations to the other ARB files in the same PR.
-
After editing ARB files, regenerate the localization classes:
flutter gen-l10n
-
Do not edit
lib/l10n/app_localizations*.dartdirectly — these are generated.
If you are not able to provide a translation, add the English string as a placeholder and note it in your PR description.
- Base your branch on
main. - Keep the PR focused — one feature or fix per PR.
- Write a clear PR description:
- What changed
- Why it was needed
- Any testing you did (device / OS, steps to reproduce the original problem)
- Link any related issue (e.g.
Closes #42). - PRs that break
flutter analyzeor existing tests will not be merged until fixed.
Open a GitHub issue and include:
- Device model and OS version
- App version (shown in Settings)
- Steps to reproduce
- What you expected vs. what happened
- Relevant logs or screenshots if available
Open a GitHub issue with the enhancement label. Describe the use case and the problem it solves. Discussion is welcome before implementation begins.
All contributors are expected to follow the Code of Conduct. Please read it before participating.
By contributing you agree that your changes will be licensed under the project's MIT License.