Contribute

Contribution to Postgresus is welcome! I would appreciate any help with the project.

There are two ways to contribute:

  1. Via promotion, docs and social sharing
  2. Via code and development

How to start contributing

Contribution via promotion, docs and social sharing

The most of users of Postgresus are developers, DevOps engineers or DBAs. Meaning we are technical people. As well as I - developer of Postgresus.

I know how to develop and build IT projects. But I'm not a marketing expert. It's really hard for me to promote the project and get more users. That is vital for Postgresus.

So I would appreciate any help with:

  • writing tutorials and guides to Medium, Dev.to, Hackernoon and other platforms
  • writing articles and blog posts about Postgresus
  • creating videos and tutorials
  • posting social media posts on LinkedIn, X, Telegram, etc.
  • even just sharing the project with your friends and colleagues - it's already a big help!
  • share answers to questions about Postgresus on Stack Overflow, Reddit, etc.

Feel free to share your publications with our community in Telegram channel.

Contribution via code and development

If you are developer, you can mainly contribute to:

⚠️ Important: All the major changes for more than 10-20 lines of code it is better to discuss with me first. At least, inform me that you take something into work. Message me in Telegram (@rostislav_dugin).

🚫 Note about large PRs: If you submit a large PR, most likely it will be refused. Because now there are a lot of AI PRs which take a huge amount of time to review and merge. I will not be able to review them.

Prerequisites

  1. Read docs in /docs folder, README.md in /backend and /frontend folders
  2. Run both backend and frontend following the instructions in their respective README.md files (for development)
  3. Read this file till the end

How to create a pull request?

We use gitflow approach.

  1. Create a new branch from main
  2. Make changes
  3. Create a pull request to main
  4. Wait for review
  5. Merge pull request

Commit naming convention

Commits should be named in the following format depending on the type of change:

  • FEATURE (area): What was done
  • FIX (area): What was fixed
  • REFACTOR (area): What was refactored

To see examples, look at commit history in main branch.

Branch naming convention

Branches should be named in the following format:

  • feature/what_was_done
  • fix/what_was_fixed
  • refactor/what_was_refactored

Example:

  • feature/add_support_of_kubernetes_helm
  • fix/make_healthcheck_optional
  • refactor/refactor_navbar

Before any PR, make sure:

  1. You created critical tests for your changes
  2. make lint is passing (for backend) and npm run lint is passing (for frontend)
  3. All tests are passing
  4. Project is building successfully
  5. All your commits should be squashed into one commit with proper message (or to meaningful parts)
  6. Code do really refactored and production ready
  7. You have one single PR per one feature (at least, if features not connected) with explanation what was done and why with comparison of alternatives
  8. If there are UI changes, please record a demo screencast with short manual how it works

Features available for contribution

You can take any of tasks below into work

Storages

  • Allow to specify prefix for S3 storage
  • Change backups naming from {uuid}.dump to {db_name}_{date}_{uuid}.dump with back compatibility
  • Verify AWS S3 support
  • Verify Google Cloud S3 support
  • Verify Tencent Cloud S3 support
  • Verify Supabase support
  • Add FTP
  • Add Dropbox
  • Add OneDrive
  • Add Yandex Drive

Notifications tasks

  • Add Mattermost
  • Add Gotify

Project plans (not for contribution)

  • Add customization of webhook
  • Add SSH tunneling
  • Add encryption for backups and read-only access to DBs
  • Add HTTPS for Postgresus
  • Add dark theme to UI
  • Add mobile version of UI
  • Add support of other languages
  • Add hint about "don't forget to whitelist Postgresus IP address in your DB config"