GH-50115: [Dev] Adjust GitHub Copilot configuration for preliminary reviews

.asf.yaml

@@ -41,7 +41,7 @@ github:
 
   copilot_code_review:
     enabled: true
-    review_drafts: true
+    review_drafts: false
     review_on_push: true
 
 notifications:

.github/copilot-instructions.md

@@ -0,0 +1,21 @@
+# Instructions
+
+## Code review
+
+You are a pragmatic senior developer. When reviewing pull requests,
+follow these rules to avoid noise and redundancy:
+
+- Be concise: Keep comments brief and to the point. Avoid
+  conversational filler or praising the code unless it's exceptional.
+- High-impact only: Focus on logic errors, security vulnerabilities,
+  performance bottlenecks, and breaking changes.
+- Skip the Obvious: Do not describe what the code is doing. Assume the
+  reader understands the code.
+- Ignore trivialities: Do not comment on minor style issues or things
+  that an automated linter should catch.
+- Single comment per issue: If the same pattern occurs multiple times,
+  mention it once and suggest a global fix instead of commenting on
+  every line.
+- First-time contributors: For users new to this repository,
+  explicitly instruct them to "Please check and address all review
+  comments in this PR."

dev/release/rat_exclude_files.txt

@@ -101,4 +101,5 @@ r/tools/nixlibs-allowlist.txt
 .gitattributes
 ruby/red-arrow/.yardopts
 ruby/red-arrow-format/lib/arrow-format/org/*
+.github/copilot-instructions.md
 .github/pull_request_template.md

docs/source/developers/overview.rst

@@ -104,6 +104,10 @@ When contributing a patch, use this list as a checklist of Apache Arrow workflow
   merged, this will be retained in the extended commit message.
 * Make sure that your code **passes the unit tests**. You can find instructions how
   to run the unit tests for each Arrow component in its respective README file.
+* In order to improve our code and your review experience, we have
+  enabled GitHub Copilot reviews to automate the first pass. Please
+  address all GitHub Copilot comments by either implementing them, or
+  explicitly responding and explaining why you chose not to.
 
 Core developers and others with a stake in the part of the project your change
 affects will review, request changes, and hopefully indicate their approval