Clarify how the providers vote result lists voters (#73883)

* Clarify how the providers vote result lists voters

The providers [RESULT][VOTE] template did not say how to report votes
cast for only some providers of a wave, or the -1 votes behind a
provider's exclusion, and it repeated "(binding)" under a heading that
already says the votes are binding. Release managers and agents drafting
the result had to work these rules out per wave.

The vote-tally override applies the same rules for agents running the
magpie release-management skill, and adapts the skill to waves, which
have no planning issue or RC labels.

Generated-by: Claude Code (Opus 5.5)

* Drop the whole-set qualifier from the non-binding vote heading

Generated-by: Claude Code (Opus 5.5)

.apache-magpie-overrides/release-vote-tally.md

@@ -0,0 +1,63 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements.  See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership.  The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied.  See the License for the
+ specific language governing permissions and limitations
+ under the License.
+ -->
+
+# Override: release-vote-tally — Airflow providers waves
+
+## What this overrides
+
+Adapts the `release-vote-tally` skill to Airflow provider waves, which are voted on as a set
+and can drop single providers during the vote. Everything else in the skill, including its
+golden rules and hard rules, still applies.
+
+## Identifying the wave
+
+- A wave is identified by its preparation date (`YYYY-MM-DD`), not by `<version>-rcN`. Find the
+  thread by the `vote_subject_template` in
+  [`release-management-config.md`](release-management-config.md).
+- Providers waves have no planning issue and no `vote-open`, `vote-passed` or `rc-rolled` labels.
+  Skip the planning-issue checks and the label proposal. The "Status of testing Providers" issue
+  is not a planning issue.
+
+## Classifying votes
+
+- A vote line that names providers, for example `+1 (non-binding) for amazon and google` or
+  `-1 for edge3`, counts for those providers only. Record the providers with the vote. It is a
+  scoped vote, not an `AMBIGUOUS` one.
+- A plain `+1` counts for the whole set, even when the voter adds that they only tested their own
+  changes.
+- A single reply can hold several scoped votes, such as `+1` for some providers and `-1` for
+  another. Record each one.
+- The pass rule applies to the whole set. A scoped `-1` does not count against the set. It counts
+  against its provider, and the release manager decides on the thread whether to exclude that
+  provider.
+
+## Drafting the `[RESULT][VOTE]` email
+
+Use the email template and listing rules in
+[`dev/README_RELEASE_PROVIDERS.md` § Summarize the voting](../dev/README_RELEASE_PROVIDERS.md#summarize-the-voting-for-the-apache-airflow-release)
+instead of the skill's default body. In short:
+
+- List binding `+1` voters by name only, without `(binding)` after each name.
+- List non-binding `+1` voters for specific providers separately from the main non-binding
+  list, with the providers in brackets after each name.
+- For every excluded provider, give its binding and non-binding `-1` counts with the voters'
+  names, and leave out a part whose count is zero.
+- Keep the exclusion reason and the plan for the next RC, and let the release manager choose
+  between the next wave and an ad-hoc release.
+- Link the vote thread as `https://lists.apache.org/thread/<id of the [VOTE] email>`.

dev/README_RELEASE_PROVIDERS.md

@@ -1716,9 +1716,20 @@ Once the vote has been passed, you will need to send a result vote to dev@airflo
 > binding `+1` votes from PMC members are already present in the vote thread — the email reports a
 > decision the PMC has already made, it does not make that decision.
 
-In both subject and message update DATE OF RELEASE, FIRST/LAST NAMES and numbers). In case
-some providers were  excluded, explain why they were excluded and what is the plan for them
-(otherwise remove the optional part of the message). There are two options for releasing
+In both subject and message update DATE OF RELEASE, FIRST/LAST NAMES and numbers. List the
+voters as follows:
+
+* Binding `+1` votes are listed by name only. The heading already says they are binding, so do not
+  add `(binding)` after each name.
+* Non-binding `+1` votes for specific providers go in a separate list, with the providers in
+  brackets after the voter's name. A vote counts for specific providers only when its vote line
+  names them, for example `+1 (non-binding) for amazon and google`. A plain `+1` goes in the main
+  non-binding list, even when the voter adds that they only tested their own changes.
+* For every excluded provider, tally its `-1` votes, both binding and non-binding, with the voters'
+  names. Leave out a part whose count is zero.
+
+Remove each optional part of the message that does not apply. In case some providers were excluded,
+explain why they were excluded and what is the plan for them. There are two options for releasing
 the next RC candidates:
 
 * They will be released as an ad-hoc release with accelerated vote
@@ -1746,14 +1757,21 @@ Hello,
 Apache Airflow Providers prepared on ${RELEASE_DATE} have been accepted.
 
 3 "+1" binding votes received:
-- FIRST LAST NAME (binding)
-- FIRST LAST NAME (binding)
-- FIRST LAST NAME (binding)
+- FIRST LAST NAME
+- FIRST LAST NAME
+- FIRST LAST NAME
 
 2 "+1" non-binding votes received:
 - FIRST LAST NAME
 - FIRST LAST NAME
 
+[optional] 1 "+1" non-binding vote received for specific providers:
+- FIRST LAST NAME (PROVIDER, PROVIDER)
+
+[optional] "-1" votes received for specific providers:
+- PROVIDER: 1 binding (FIRST LAST NAME), 1 non-binding (FIRST LAST NAME)
+- PROVIDER: 1 binding (FIRST LAST NAME)
+
 [optional] The providers PROVIDER, PROVIDER have been excluded from the release.
 This is due to REASON HERE.
 The next RC candidates for those providers will be released [in the next wave