You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Jarek Potiuk <ja...@potiuk.com> on 2026/09/17 11:26:35 UTC
Re: Proposal: let the Incubator and ComDev own the governance values Magpie's onboarding skill needs
Replaced with proper Incubator email.
On Thu, Sep 17, 2026 at 1:24 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> Dear Incubator PMC and Community Development Teams,
>
> I am writing to both groups because this proposal addresses shared
> responsibilities where neither part functions effectively on its own.
>
> We have two main questions regarding Apache Magpie governance and
> release skills:
>
> =====================================================================
> QUESTION 1: Would you own the governance values?
>
> THE PROBLEM
>
> Apache Magpie includes a committer-onboarding skill that guides
> nominators through the committer onboarding process. A single
> procedure serves both incubating podlings and top-level projects
> (TLPs), branching via a stage: podling | tlp configuration key.
>
> Currently, values for Whimsy roster URLs, voting rules, private lists,
> and governing bodies are entered manually per project. This leads to
> duplicate efforts and stale configurations (e.g., our configuration
> template currently defaults to whimsy_roster_url: TODO).
>
> PROPOSED SOLUTION
> We propose establishing central value sets and allowing local overrides:
>
> 1. Centralized Value Sets:
>
> - Incubator PMC owns podling defaults:
> stage: podling
> governing_body: PPMC
> whimsy_roster_url: https://whimsy.apache.org/roster/ppmc/<project>
> private_list: private@<project>.incubator.apache.org
> vote_rule: 3 binding PPMC +1s, no binding veto
> binding_voters: current PPMC members
>
> - ComDev owns TLP defaults:
> stage: tlp
> governing_body: PMC
> whimsy_roster_url: https://whimsy.apache.org/roster/committee/
> <project>
> private_list: private@<project>.apache.org
>
> Magpie will resolve these defaults automatically while allowing
> project-level overrides.
>
> 2. Agentic Overrides:
>
> If specific procedural differences are required (e.g., IPMC
> notifications or additional checks), they can be maintained directly
> in your respective repositories without modifying Magpie and release
> it separately:
>
> https://github.com/apache/magpie/blob/main/docs/setup/agentic-overrides.md
>
> =====================================================================
> QUESTION 2: Would either group prefer to own the release skills
> directly?
>
> Magpie includes ten ASF-scoped release skills (rc-cut, verify-rc,
> vote-draft, vote-tally, promote, announce-draft, keys-sync,
> archive-sweep, audit-report, prepare).
>
> Currently, these skills do not distinguish between podlings and TLPs,
> meaning podlings using them are guided through an incomplete process
> (missing podling/IPMC nuances).
>
> Given that skills can now be published independently (e.g., via claude
> plugin marketplace add apache/incubator), would the Incubator PMC or
> ComDev prefer to own these release skills directly? Magpie can
> maintain registry discovery - while still acting as a pass-through for
> those who install / adopt Magpie.
>
> ===================================================================== NEXT
> STEPS
>
> We are seeking input on:
>
> 1. Whether each group is willing to own its respective governance
> values (Question 1).
> 2. Whether either group wants to own part or all of the release
> skills family (Question 2).
>
> Additional details and design discussions are available here:
>
> - Design PR: https://github.com/apache/magpie/pull/1265
> - ComDev Tracker: https://github.com/apache/comdev/issues/45
>
> Please let us know your thoughts.
>
> Best regards,
>
> Jarek Potiuk
>
> --
> Drafted with AI assistance (Claude Opus 5) and reviewed before sending.
>
Re: Proposal: let the Incubator and ComDev own the governance values Magpie's onboarding skill needs
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi Dave,
I tested it by running it blind over 50 release candidates from 40 podlings, voted between January 2024 and September 2026. For each one, I read only the opening vote email, wrote down the findings, then read the thread and compared. It made 46 correct calls and one partial. It missed a real blocker twice and raised one false blocker. It also found 13 problems no reviewer mentioned, so it could be argued from those numbers that it does better than human review on its own. Compared to the plain skill, which only got 39 of the 50 right.
The method and the list of podlings are in the README, and anyone can repeat it. The Python checker, check_rc.py, is deterministic and needs no LLM, so that is useful on its own.
On the roster point, the onboarding skill doesn't depend on the Whimsy roster tool. If the roster tool is replaced, only the MCP underneath might need to change, not the skill.
For the minimum LLM, only reviewing what the checker flags needs a model, and a human could also review it, so no model would be needed. The SKILL does make a few other checks by calling MCPs, but these are optional. I have not fully tested it without the MCPs to see what difference they make, but it would make a difference; for instance, it wouldn’t look at previous RCs/votes to see what issues they contained. I've run the skill with Claude, Codex, and OpenCode. The results with OpenCode (Zen) were not as good, but still helpful.
Here is what the checker output looks like before it gets parsed by an LLM:
# Release candidate check: 0.43.0-incubating-RC1
Deterministic checks only. `fail` items are facts. `candidate` items need a person;
most will be fine and some will not. Nothing here is a vote.
## Artifacts
- apache-burr-0.43.0-incubating-sdist.tar.gz
- apache-burr-0.43.0-incubating-src.tar.gz
- apache_burr-0.43.0-py3-none-any.whl
## Counts
- files: 1152
- asf_header: 869
- no_header: 17
- spdx: 0
- third_party_header: 1
- asf_plus_foreign: 0
- binary: 0
- nested_archive: 0
- media: 90
- data: 0
- licence_signal: 1
## fail (1)
### naming: archive name does not contain "incubating" (1)
- `apache_burr-0.43.0-py3-none-any.whl`
## candidate (2)
### licence-signal: mentions GPL/LGPL/AGPL (1)
- `apache-burr-0.43.0-incubating-src.tar.gz/website/package-lock.json` | 2pRiaydKJ1G/rHZvnsrHAOcQALIi9sA5co5xenQdTugCvtb1cuf78Vf4g==", "cpu": [ "arm64" ], "license": "LGPL-3.0-or-later", "optional": true, "os": [ "darwin" ], "funding": { "url": "https://o
### header-third-party: third-party header (Apache-licensed or other copyright); check LICENSE and NOTICE cover it (1)
By copyright holder: shadcn (1)
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/button.tsx` | ["* Copyright (c) 2023 shadcn"]
## Images, fonts and documents (90)
Usually fine. Fonts and icon sets are the ones that tend to carry their own licence.
- `apache-burr-0.43.0-incubating-sdist.tar.gz/burr/tracking/server/s3/architecture.png`
- `apache-burr-0.43.0-incubating-sdist.tar.gz/examples/hello-world-counter/statemachine.png`
- `apache-burr-0.43.0-incubating-sdist.tar.gz/examples/deep-researcher/statemachine.png`
- `apache-burr-0.43.0-incubating-sdist.tar.gz/examples/streaming-fastapi/statemachine.png`
- `apache-burr-0.43.0-incubating-sdist.tar.gz/examples/multi-modal-chatbot/statemachine.png`
- `apache-burr-0.43.0-incubating-sdist.tar.gz/examples/email-assistant/statemachine.png`
- `apache-burr-0.43.0-incubating-sdist.tar.gz/telemetry/ui/public/favicon.ico`
- `apache-burr-0.43.0-incubating-sdist.tar.gz/telemetry/ui/public/logo.png`
- `apache-burr-0.43.0-incubating-src.tar.gz/chatbot.gif`
- `apache-burr-0.43.0-incubating-src.tar.gz/burr_logo.svg`
- `apache-burr-0.43.0-incubating-src.tar.gz/burr_logo.png`
- `apache-burr-0.43.0-incubating-src.tar.gz/burr/tracking/server/s3/architecture.png`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/public/burr_logo.svg`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/public/burr_logo.png`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/public/logos/taskhuman.svg`
- ... 75 more in findings.json
## Code or documentation files with no licence header (17)
- `apache-burr-0.43.0-incubating-sdist.tar.gz/examples/deep-researcher/prompts.py`
- `apache-burr-0.43.0-incubating-sdist.tar.gz/examples/deep-researcher/deep_researcher_utils.py`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/safari.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/animated-beam.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/shimmer-button.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/icon-cloud.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/border-beam.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/dot-pattern.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/marquee.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/number-ticker.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/magic-card.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/animated-shiny-text.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/website/src/components/ui/blur-fade.tsx`
- `apache-burr-0.43.0-incubating-src.tar.gz/examples/deep-researcher/prompts.py`
- `apache-burr-0.43.0-incubating-src.tar.gz/examples/deep-researcher/deep_researcher_utils.py`
- ... 2 more in findings.json
Kind regards,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal: let the Incubator and ComDev own the governance values Magpie's onboarding skill needs
Posted by Dave Fisher <wa...@apache.org>.
Hi -
My remarks here are about ownership and not meant to be negative about these efforts. It’s also important to assess the LLM and token use in order to evaluate automation possibilities.
1. Roster / committer on boarding.
I know that many PMCs have their own procedures and variations on the process while many do not. I think that the skill you are offering here is likely to undergo some changes especially since a replacement to Whimsy’s roster tool is a likely next tooling project. (That’s a good thing.)
I really have no opinion about the best PMC to own the Magpie skill.
2. Release checker.
I think that the release checker is a tool that will have foundation wide benefit. It seems like a great idea, but so far as I know we only have Justin’s word about the results. I might be wrong, but I would like to see some example output and do some of my own quality checks. How well the checker does is much more to me a Legal Affairs concern than it is the Incubator. I’ve expressed that it would be a good additional check to add to ATR either after or during the Glasgow conference.
Automation question: I don’t think a frontier LLM is needed for these skills, what is the minimum LLM needed for each?
Best,
Dave
> On Sep 17, 2026, at 4:26 AM, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> Replaced with proper Incubator email.
>
> On Thu, Sep 17, 2026 at 1:24 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> Dear Incubator PMC and Community Development Teams,
>>
>> I am writing to both groups because this proposal addresses shared
>> responsibilities where neither part functions effectively on its own.
>>
>> We have two main questions regarding Apache Magpie governance and
>> release skills:
>>
>> =====================================================================
>> QUESTION 1: Would you own the governance values?
>>
>> THE PROBLEM
>>
>> Apache Magpie includes a committer-onboarding skill that guides
>> nominators through the committer onboarding process. A single
>> procedure serves both incubating podlings and top-level projects
>> (TLPs), branching via a stage: podling | tlp configuration key.
>>
>> Currently, values for Whimsy roster URLs, voting rules, private lists,
>> and governing bodies are entered manually per project. This leads to
>> duplicate efforts and stale configurations (e.g., our configuration
>> template currently defaults to whimsy_roster_url: TODO).
>>
>> PROPOSED SOLUTION
>> We propose establishing central value sets and allowing local overrides:
>>
>> 1. Centralized Value Sets:
>>
>> - Incubator PMC owns podling defaults:
>> stage: podling
>> governing_body: PPMC
>> whimsy_roster_url: https://whimsy.apache.org/roster/ppmc/<project>
>> private_list: private@<project>.incubator.apache.org
>> vote_rule: 3 binding PPMC +1s, no binding veto
>> binding_voters: current PPMC members
>>
>> - ComDev owns TLP defaults:
>> stage: tlp
>> governing_body: PMC
>> whimsy_roster_url: https://whimsy.apache.org/roster/committee/
>> <project>
>> private_list: private@<project>.apache.org
>>
>> Magpie will resolve these defaults automatically while allowing
>> project-level overrides.
>>
>> 2. Agentic Overrides:
>>
>> If specific procedural differences are required (e.g., IPMC
>> notifications or additional checks), they can be maintained directly
>> in your respective repositories without modifying Magpie and release
>> it separately:
>>
>> https://github.com/apache/magpie/blob/main/docs/setup/agentic-overrides.md
>>
>> =====================================================================
>> QUESTION 2: Would either group prefer to own the release skills
>> directly?
>>
>> Magpie includes ten ASF-scoped release skills (rc-cut, verify-rc,
>> vote-draft, vote-tally, promote, announce-draft, keys-sync,
>> archive-sweep, audit-report, prepare).
>>
>> Currently, these skills do not distinguish between podlings and TLPs,
>> meaning podlings using them are guided through an incomplete process
>> (missing podling/IPMC nuances).
>>
>> Given that skills can now be published independently (e.g., via claude
>> plugin marketplace add apache/incubator), would the Incubator PMC or
>> ComDev prefer to own these release skills directly? Magpie can
>> maintain registry discovery - while still acting as a pass-through for
>> those who install / adopt Magpie.
>>
>> ===================================================================== NEXT
>> STEPS
>>
>> We are seeking input on:
>>
>> 1. Whether each group is willing to own its respective governance
>> values (Question 1).
>> 2. Whether either group wants to own part or all of the release
>> skills family (Question 2).
>>
>> Additional details and design discussions are available here:
>>
>> - Design PR: https://github.com/apache/magpie/pull/1265
>> - ComDev Tracker: https://github.com/apache/comdev/issues/45
>>
>> Please let us know your thoughts.
>>
>> Best regards,
>>
>> Jarek Potiuk
>>
>> --
>> Drafted with AI assistance (Claude Opus 5) and reviewed before sending.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Proposal: let the Incubator and ComDev own the governance values Magpie's onboarding skill needs
Posted by Dave Fisher <wa...@apache.org>.
Hi -
My remarks here are about ownership and not meant to be negative about these efforts. It’s also important to assess the LLM and token use in order to evaluate automation possibilities.
1. Roster / committer on boarding.
I know that many PMCs have their own procedures and variations on the process while many do not. I think that the skill you are offering here is likely to undergo some changes especially since a replacement to Whimsy’s roster tool is a likely next tooling project. (That’s a good thing.)
I really have no opinion about the best PMC to own the Magpie skill.
2. Release checker.
I think that the release checker is a tool that will have foundation wide benefit. It seems like a great idea, but so far as I know we only have Justin’s word about the results. I might be wrong, but I would like to see some example output and do some of my own quality checks. How well the checker does is much more to me a Legal Affairs concern than it is the Incubator. I’ve expressed that it would be a good additional check to add to ATR either after or during the Glasgow conference.
Automation question: I don’t think a frontier LLM is needed for these skills, what is the minimum LLM needed for each?
Best,
Dave
> On Sep 17, 2026, at 4:26 AM, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> Replaced with proper Incubator email.
>
> On Thu, Sep 17, 2026 at 1:24 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> Dear Incubator PMC and Community Development Teams,
>>
>> I am writing to both groups because this proposal addresses shared
>> responsibilities where neither part functions effectively on its own.
>>
>> We have two main questions regarding Apache Magpie governance and
>> release skills:
>>
>> =====================================================================
>> QUESTION 1: Would you own the governance values?
>>
>> THE PROBLEM
>>
>> Apache Magpie includes a committer-onboarding skill that guides
>> nominators through the committer onboarding process. A single
>> procedure serves both incubating podlings and top-level projects
>> (TLPs), branching via a stage: podling | tlp configuration key.
>>
>> Currently, values for Whimsy roster URLs, voting rules, private lists,
>> and governing bodies are entered manually per project. This leads to
>> duplicate efforts and stale configurations (e.g., our configuration
>> template currently defaults to whimsy_roster_url: TODO).
>>
>> PROPOSED SOLUTION
>> We propose establishing central value sets and allowing local overrides:
>>
>> 1. Centralized Value Sets:
>>
>> - Incubator PMC owns podling defaults:
>> stage: podling
>> governing_body: PPMC
>> whimsy_roster_url: https://whimsy.apache.org/roster/ppmc/<project>
>> private_list: private@<project>.incubator.apache.org
>> vote_rule: 3 binding PPMC +1s, no binding veto
>> binding_voters: current PPMC members
>>
>> - ComDev owns TLP defaults:
>> stage: tlp
>> governing_body: PMC
>> whimsy_roster_url: https://whimsy.apache.org/roster/committee/
>> <project>
>> private_list: private@<project>.apache.org
>>
>> Magpie will resolve these defaults automatically while allowing
>> project-level overrides.
>>
>> 2. Agentic Overrides:
>>
>> If specific procedural differences are required (e.g., IPMC
>> notifications or additional checks), they can be maintained directly
>> in your respective repositories without modifying Magpie and release
>> it separately:
>>
>> https://github.com/apache/magpie/blob/main/docs/setup/agentic-overrides.md
>>
>> =====================================================================
>> QUESTION 2: Would either group prefer to own the release skills
>> directly?
>>
>> Magpie includes ten ASF-scoped release skills (rc-cut, verify-rc,
>> vote-draft, vote-tally, promote, announce-draft, keys-sync,
>> archive-sweep, audit-report, prepare).
>>
>> Currently, these skills do not distinguish between podlings and TLPs,
>> meaning podlings using them are guided through an incomplete process
>> (missing podling/IPMC nuances).
>>
>> Given that skills can now be published independently (e.g., via claude
>> plugin marketplace add apache/incubator), would the Incubator PMC or
>> ComDev prefer to own these release skills directly? Magpie can
>> maintain registry discovery - while still acting as a pass-through for
>> those who install / adopt Magpie.
>>
>> ===================================================================== NEXT
>> STEPS
>>
>> We are seeking input on:
>>
>> 1. Whether each group is willing to own its respective governance
>> values (Question 1).
>> 2. Whether either group wants to own part or all of the release
>> skills family (Question 2).
>>
>> Additional details and design discussions are available here:
>>
>> - Design PR: https://github.com/apache/magpie/pull/1265
>> - ComDev Tracker: https://github.com/apache/comdev/issues/45
>>
>> Please let us know your thoughts.
>>
>> Best regards,
>>
>> Jarek Potiuk
>>
>> --
>> Drafted with AI assistance (Claude Opus 5) and reviewed before sending.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Proposal: let the Incubator and ComDev own the governance values Magpie's onboarding skill needs
Posted by Dave Fisher <wa...@apache.org>.
Hi -
My remarks here are about ownership and not meant to be negative about these efforts. It’s also important to assess the LLM and token use in order to evaluate automation possibilities.
1. Roster / committer on boarding.
I know that many PMCs have their own procedures and variations on the process while many do not. I think that the skill you are offering here is likely to undergo some changes especially since a replacement to Whimsy’s roster tool is a likely next tooling project. (That’s a good thing.)
I really have no opinion about the best PMC to own the Magpie skill.
2. Release checker.
I think that the release checker is a tool that will have foundation wide benefit. It seems like a great idea, but so far as I know we only have Justin’s word about the results. I might be wrong, but I would like to see some example output and do some of my own quality checks. How well the checker does is much more to me a Legal Affairs concern than it is the Incubator. I’ve expressed that it would be a good additional check to add to ATR either after or during the Glasgow conference.
Automation question: I don’t think a frontier LLM is needed for these skills, what is the minimum LLM needed for each?
Best,
Dave
> On Sep 17, 2026, at 4:26 AM, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> Replaced with proper Incubator email.
>
> On Thu, Sep 17, 2026 at 1:24 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> Dear Incubator PMC and Community Development Teams,
>>
>> I am writing to both groups because this proposal addresses shared
>> responsibilities where neither part functions effectively on its own.
>>
>> We have two main questions regarding Apache Magpie governance and
>> release skills:
>>
>> =====================================================================
>> QUESTION 1: Would you own the governance values?
>>
>> THE PROBLEM
>>
>> Apache Magpie includes a committer-onboarding skill that guides
>> nominators through the committer onboarding process. A single
>> procedure serves both incubating podlings and top-level projects
>> (TLPs), branching via a stage: podling | tlp configuration key.
>>
>> Currently, values for Whimsy roster URLs, voting rules, private lists,
>> and governing bodies are entered manually per project. This leads to
>> duplicate efforts and stale configurations (e.g., our configuration
>> template currently defaults to whimsy_roster_url: TODO).
>>
>> PROPOSED SOLUTION
>> We propose establishing central value sets and allowing local overrides:
>>
>> 1. Centralized Value Sets:
>>
>> - Incubator PMC owns podling defaults:
>> stage: podling
>> governing_body: PPMC
>> whimsy_roster_url: https://whimsy.apache.org/roster/ppmc/<project>
>> private_list: private@<project>.incubator.apache.org
>> vote_rule: 3 binding PPMC +1s, no binding veto
>> binding_voters: current PPMC members
>>
>> - ComDev owns TLP defaults:
>> stage: tlp
>> governing_body: PMC
>> whimsy_roster_url: https://whimsy.apache.org/roster/committee/
>> <project>
>> private_list: private@<project>.apache.org
>>
>> Magpie will resolve these defaults automatically while allowing
>> project-level overrides.
>>
>> 2. Agentic Overrides:
>>
>> If specific procedural differences are required (e.g., IPMC
>> notifications or additional checks), they can be maintained directly
>> in your respective repositories without modifying Magpie and release
>> it separately:
>>
>> https://github.com/apache/magpie/blob/main/docs/setup/agentic-overrides.md
>>
>> =====================================================================
>> QUESTION 2: Would either group prefer to own the release skills
>> directly?
>>
>> Magpie includes ten ASF-scoped release skills (rc-cut, verify-rc,
>> vote-draft, vote-tally, promote, announce-draft, keys-sync,
>> archive-sweep, audit-report, prepare).
>>
>> Currently, these skills do not distinguish between podlings and TLPs,
>> meaning podlings using them are guided through an incomplete process
>> (missing podling/IPMC nuances).
>>
>> Given that skills can now be published independently (e.g., via claude
>> plugin marketplace add apache/incubator), would the Incubator PMC or
>> ComDev prefer to own these release skills directly? Magpie can
>> maintain registry discovery - while still acting as a pass-through for
>> those who install / adopt Magpie.
>>
>> ===================================================================== NEXT
>> STEPS
>>
>> We are seeking input on:
>>
>> 1. Whether each group is willing to own its respective governance
>> values (Question 1).
>> 2. Whether either group wants to own part or all of the release
>> skills family (Question 2).
>>
>> Additional details and design discussions are available here:
>>
>> - Design PR: https://github.com/apache/magpie/pull/1265
>> - ComDev Tracker: https://github.com/apache/comdev/issues/45
>>
>> Please let us know your thoughts.
>>
>> Best regards,
>>
>> Jarek Potiuk
>>
>> --
>> Drafted with AI assistance (Claude Opus 5) and reviewed before sending.
>>