The Contributor's Quick Start isn't quick enough and needs some TLC

[RNHTTR]

What do you see as an issue?

The Contributor's Quick Start is super long and arguably confusing

There are also a handful of issues with the guide now. Here's an example, :

Solving the problem

The guide references several different ways to run an Airflow dev environment:

• Containers with different flavors
  • Docker
  • Colima
  • Docker compose
• Hatch, pyenv, pyenv-virtualenv, or virtualenvwrapper
• Postgres (not necessary for a lot of contributions, especially for someone new to contributing here)
• Breeze

I think we should align on the truly simplest way for users to make their first contribution and move everything else to separate guides.

Anything else

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[amoghrajesh]

Good catch, I think breeze would be the most ideal dev env setup and also the easiest I'd say

[RNHTTR]

The downside to breeze is it requires Docker which requires quite a bit of RAM that might make contributing prohibitive to some users. Alternatively there could be a separate quickstart for using a virtual env instead of breeze?

[amoghrajesh]

That's smart. We basically can have 2 quickstarts for two of the most common (and used) developer setups:

1. Virtual Env Quickstart
2. Breeze Quickstart

[potiuk]

Yes. I think quick start tried to combine both Breeze and venv setup as quick start, but splitting it to ven e and breeze quick start is a good idea. Both serve different purpose - there is even a table in contributing docs when you should use local venv and when Breeze

[potiuk]

We discussed very similar thing about generic Python experience and it would be great to have a page in our contribute docs 'if you want to do this - choose local',of you want to do that - setup Breeze.