Skip to content

Latest commit

 

History

History
59 lines (45 loc) · 2.27 KB

File metadata and controls

59 lines (45 loc) · 2.27 KB

Contributing to WorkFlow

Thanks for taking a look at WorkFlow. This is a self-hosted PHP MVC app with no framework and no build step, so contributing is intentionally low-ceremony.

Getting set up

git clone <your fork>
cd ProjIn
cp .env.example .env
# edit .env: set WORKFLOW_DB_ROOT_PASSWORD / WORKFLOW_DB_PASSWORD to any local values
docker compose up -d --build

Open http://localhost:8080 and follow the installer — see the root README.md for the full quick start. For a deeper understanding of how the codebase is put together before you start changing things, read readme/ARCHITECTURE.md and readme/MODULES.md.

Reporting a bug

Open an issue with:

  • What you did, what you expected, what happened instead
  • PHP version, and whether you're running via Docker or manually
  • Anything in error.log or your browser console relevant to the problem

Suggesting a feature

Open an issue describing the problem you're trying to solve, not just the feature — it's easier to evaluate "I need X because Y" than a specific implementation request. Check existing issues first to avoid duplicates.

Submitting a change

  1. Fork the repo and create a branch off main
  2. Keep the PR scoped to one change — smaller PRs get reviewed faster
  3. There's no automated test suite yet, so manually verify your change works (the app has no build step: edit a .phtml/.php file, refresh the browser, done)
  4. Describe what you changed and why in the PR description
  5. If your change touches the database schema, add a migration file under setup/ following the existing migration_YYYY-MM-DD_description.sql naming pattern — don't edit setup/workflow_database.sql directly for schema changes that need to apply to existing installs

Code style

  • Match the existing style in the file you're editing — this codebase doesn't use an автоformatter or linter
  • No framework, no package manager, no autoformatter for the PHP side — keep it that way unless discussed in an issue first
  • Prefer clarity over cleverness; comments should explain why, not what

Security

If you find a security issue, please don't open a public issue — see SECURITY.md for how to report it privately instead.