docs: add basic starter contributing guide

[dev-hari-prasad]

Add a CONTRIBUTING.md file to document the contribution workflow for pgAdmin.

Covers:

• Getting started instructions
• Issue reporting guidelines
• Development workflow and coding practices
• Pull request requirements
• Development environment setup
• Database migration guidance
• Security reporting process
• Community support resources

It is a single reference for making contributions.

Addresses and closes #10056

Summary by CodeRabbit

Summary by CodeRabbit

• Documentation
  • Added comprehensive contribution documentation, including getting started, reporting issues, making changes, submitting pull requests, setting up the development environment, running and building locally, handling database migrations, reporting security vulnerabilities, and finding community/support resources.
  • Included an explicit policy for AI-assisted contributions and coordination expectations for large autogenerated changes.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: f9e177ef-ad72-4e8a-8112-9e81d1e6c4e2

📥 Commits

Reviewing files that changed from the base of the PR and between e8c3542 and 9d332ca.

📒 Files selected for processing (1)

• CONTRIBUTING.md

---

Walkthrough

A new CONTRIBUTING.md file (341 lines) is added to the pgAdmin 4 repository. It provides comprehensive contribution guidance covering project overview, contribution workflow, issue reporting standards, pull request requirements, complete development environment setup instructions, build procedures, database migration workflow, security vulnerability reporting, community communication channels, and contribution licensing terms.

Changes

Contributing Documentation

Layer / File(s)	Summary
Contribution workflow and expectations CONTRIBUTING.md (lines 1–80)	Adds introduction, table of contents, and contributor guidance including project architecture, issue reporting expectations, change submission requirements, AI-assisted contribution expectations, and pull request standards.
Development environment setup and operations CONTRIBUTING.md (lines 81–293)	Provides end-to-end development setup covering prerequisites, enabling Corepack, building web assets, Python environment configuration, local pgAdmin configuration, running the application, building documentation, Electron runtime development, and packaging for distribution.
Advanced workflows and project policies CONTRIBUTING.md (lines 294–341)	Documents SQLite database migration workflow, security vulnerability reporting procedures (with email contact and prohibition on GitHub issues), community and support communication channels, and contribution licensing terms.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding a basic contributor guide in CONTRIBUTING.md to help new contributors.
Linked Issues check	✅ Passed	The PR addresses all core requirements from issue #10056: adds CONTRIBUTING.md with coding standards, testing, commit/PR standards, development setup, build instructions, and contributor guidelines.
Out of Scope Changes check	✅ Passed	All changes in CONTRIBUTING.md are directly scoped to the linked issue's requirements for a contributor guide; no out-of-scope modifications are present.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@CONTRIBUTING.md`:
- Around line 91-95: Add a language tag to the Windows command code block in
CONTRIBUTING.md. The fenced code block containing the Windows commands (cd, yarn
install, yarn run bundle) currently lacks a language identifier on the opening
triple-backtick fence. Add `bat` or `powershell` as the language tag immediately
after the opening fence (e.g., ```bat) to satisfy markdownlint requirements and
enable proper syntax highlighting.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8e4fc867-506e-42cf-a2c8-401d3cb66187

📥 Commits

Reviewing files that changed from the base of the PR and between 4beb7e4 and fd87042.

📒 Files selected for processing (1)

• CONTRIBUTING.md

[dev-hari-prasad]

I have tried to keep the document as unopinionated as possible and avoided adding my own preferences. That said, a few things may be worth considering:

PR naming

Some examples of PR naming styles can help maintain cleanliness and clarity in PR naming.

Examples:

• fix/connection-bug
• feat/add-query-history
• docs/update-contributing-guide
• refactor/improve-connection-speed
• chore/update-dependencies

AI usage

With AI tools becoming common, a short policy may be useful:

• Do not use automated systems (such as OpenClaw) to mass-create issues or pull requests unless explicitly approved by the maintainers.
• Issues and PRs should be clear and useful, but they do not need to be unnecessarily long or overly detailed.
• If you use AI coding tools, make sure you understand the changes being submitted, review the code, test it properly, and take responsibility for the final result, or whatever policy we have towards AI coding tools goes here.
• If you are not familiar with the technologies used in pgAdmin, please take some time to learn and understand the relevant parts of the codebase before opening a pull request, instead of relying heavily on AI.

These are some of my opinionated suggestions, so let me know if we can include any of this in the new document, and if you guys have any more suggestions, happy to make changes, @asheshv and @dpage.

[dpage]

Thanks for putting this together, @dev-hari-prasad, and for the thoughtful questions. Having reviewed it alongside the existing docs, I'd like to suggest a change of direction before we take it further.

The overlap with the README

Most of the development-setup content here (Architecture, Prerequisites, Building the Web Assets, Python Environment, Building docs/packages, Database Migrations, Security Issues) is reproduced almost verbatim from the top-level README.md, which is really a developer/build guide rather than a conventional readme. There's also a separate, maintained set of contributor docs in the Sphinx tree under docs/en_US/ (contributions.rst, code_overview.rst, coding_standards.rst, submitting_pull_requests.rst, code_review.rst, translations.rst). Merging this as-is would leave the same instructions in three places, which will inevitably drift apart.

Suggested structure

Rather than add a third copy, I think the better shape, and one that genuinely improves things, is:

• Move the development build and environment setup into CONTRIBUTING.md, so it becomes the canonical home for "how do I get set up to contribute". This is the right place for it: it is contributor-facing and tracks master, whereas the Sphinx docs are versioned to releases, so build-from-source steps belong in a master-tracked file.
• Thin README.md down to an introduction (what pgAdmin is, how to install and run as a user, and links onward), pointing developers at CONTRIBUTING.md.
• Keep a short Architecture blurb in CONTRIBUTING.md, but link to code_overview for the full write-up, and link to coding_standards, submitting_pull_requests and code_review rather than restating them.

That keeps each piece of information in exactly one place, with everything else linking to it. It does mean this change grows to include trimming the README, so do shout if you'd like a hand with that part.

Two fixes worth noting regardless of structure

• The runtime/ link in the Architecture section currently points at file:///d:/t3 code/pgadmin4/runtime, which looks like a local path that slipped in; it will need to become a repo-relative or GitHub link.
• The Windows code-fence lint nit looks addressed already, thanks.

On your two questions

• PR/branch naming: branch names are contributor-local, and we squash each PR to a single commit with a ... (#NNNN) subject on merge, so enforcing branch naming buys us little. What is worth documenting instead is the commit/PR title convention we already use in practice (feat:, fix:, docs: and so on).
• AI usage: a short, sensible note along the lines you suggested is reasonable, namely that contributors remain responsible for understanding, testing and standing behind anything they submit, AI-assisted or not, and that mass auto-generated issues or PRs shouldn't be opened without maintainer agreement. I'd keep it brief and non-preachy.

Thanks again; this is a useful addition and worth getting the structure right.

[dev-hari-prasad]

Thanks for the detailed feedback.

Just to make sure we're on the same page before I start making changes:

• I will first move over any remaining development/setup content so that CONTRIBUTING.md becomes the main place for contributor setup.
• My suggestion is that we finalize this structure first, and then open a separate draft PR to trim the duplicated content from README.md. That should make the review a bit easier to follow.
• Is there anything else you would like to see removed from README.md as part of that cleanup?
• I will keep the Architecture section short and link out to code_overview, coding_standards, submitting_pull_requests, and code_review instead of repeating their content.
• I will fix the local path typo as well and update the PR/commit guidance and trim down the AI usage section a bit so it sounds less preachy.

If there's anything else you think we can adjust while I'm in there, feel free to shoot it my way. Also, it would be a good idea to tag other core contributors along the way for their input, since these changes affect important documents.

@dpage