Docs: Update PR workflow documentation (#10532)

* Minor: Update PR workflow documentation

* prettier

* Clarify leaving PRs open

* Update docs/source/contributor-guide/index.md

Co-authored-by: Oleks V <[email protected]>

* Update docs/source/contributor-guide/index.md

Co-authored-by: Oleks V <[email protected]>

* prettier

* pretty

---------

Co-authored-by: Oleks V <[email protected]>

docs/source/contributor-guide/index.md

@@ -66,26 +66,48 @@ ideas with the community to get feedback on implementation.
 
 ## Pull Request Overview
 
-We welcome pull requests (PRs) from anyone from the community.
+We welcome pull requests (PRs) from anyone in the community.
 
-DataFusion is a very active fast-moving project and we try to review and merge PRs quickly to keep the review backlog down and the pace up. After review and approval, one of the [committers] will merge your PR.
+DataFusion is a rapidly evolving project and we try to review and merge PRs quickly.
 
 Review bandwidth is currently our most limited resource, and we highly encourage reviews by the broader community. If you are waiting for your PR to be reviewed, consider helping review other PRs that are waiting. Such review both helps the reviewer to learn the codebase and become more expert, as well as helps identify issues in the PR (such as lack of test coverage), that can be addressed and make future reviews faster and more efficient.
 
+The lifecycle of a PR is:
+
+1. Create a PR targeting the `main` branch.
+2. For new contributors a committer must first trigger the CI tasks. Please mention the members from committers list in the PR to help trigger the CI
+3. Your PR will be reviewed. Please respond to all feedback on the PR: you don't have to change the code, but you should acknowledge the feedback. PRs waiting for the feedback for more than a few days will be marked as draft.
+4. Once the PR is approved, one of the [committers] will merge your PR, typically within 24 hours. We leave approved "major" changes (see below) open for 24 hours prior to merging, and sometimes leave "minor" PRs open for the same time to permit additional feedback.
+
+Note that the above time frames are estimates. Due to limited committer
+bandwidth, it may take longer to merge your PR. Please wait
+patiently. If it has been several days you can friendly ping the
+committer who approved your PR to help remind them to merge it.
+
 [committers]: https://people.apache.org/phonebook.html?unix=datafusion
 
 ## Creating Pull Requests
 
-We recommend splitting your contributions into smaller PRs rather than large PRs (500+ lines) because:
+We recommend splitting your contributions into multiple smaller focused PRs rather than large PRs (500+ lines) because:
 
 1. The PR is more likely to be reviewed quickly -- our reviewers struggle to find the contiguous time needed to review large PRs.
 2. The PR discussions tend to be more focused and less likely to get lost among several different threads.
 3. It is often easier to accept and act on feedback when it comes early on in a small change, before a particular approach has been polished too much.
 
 If you are concerned that a larger design will be lost in a string of small PRs, creating a large draft PR that shows how they all work together can help.
 
+Note all commits in a PR are squashed when merged to the `main` branch so there is one commit per PR.
+
 # Reviewing Pull Requests
 
+Some helpful links:
+
+- [PRs Waiting for Review]
+- [Approved PRs Waiting for Merge]
+
+[prs waiting for review]: https://github.com/apache/datafusion/pulls?q=is%3Apr+is%3Aopen+-review%3Aapproved+-is%3Adraft+
+[approved prs waiting for merge]: https://github.com/apache/datafusion/pulls?q=is%3Apr+is%3Aopen+review%3Aapproved+-is%3Adraft
+
 When reviewing PRs, please remember our primary goal is to improve DataFusion and its community together. PR feedback should be constructive with the aim to help improve the code as well as the understanding of the contributor.
 
 Please ensure any issues you raise contains a rationale and suggested alternative -- it is frustrating to be told "don't do it this way" without any clear reason or alternate provided.