Quick one: I will disable commits for now (move them back to commit@) .. They are ALREADY noisy::)
On Mon, May 25, 2026 at 1:32 PM Yeonguk Choo <[email protected]> wrote: > Hi, Jarek, > Thanks for starting this discussion. > > I’d also like to share a few thoughts from my side. > > 1. Committer / PMC criteria: > Like Justin mentioned, I also think it makes sense to focus more on > demonstrated merit rather than purely technical contributions. > However, given the architectural nature of the project, I believe it is > also important for contributors to understand how the overall system and > workflows fit together. > > Additionally, considering the likelihood that AI-assisted contributions > will increase significantly in this project over time, I think it makes > sense to maintain some level of standard around trust and understanding. > > 2. Valuing all contributions: > I also agree with recognizing different forms of contribution under the > same umbrella. > However, in terms of impact, I believe there are contributions that can > significantly influence usability, project direction, and the overall user > experience, even if the line between code and non-code becomes blurry. > > 3. CTR vs RTC: > Regarding CTR vs RTC, I’m also fairly flexible on this point. Personally, > I think it could be both interesting and valuable to adopt Magpie itself to > help manage Magpie. > > I also believe that dogfooding can genuinely help improve the project, and > I like the idea of the project itself becoming a real-world use case for > the project. > > At that point, maybe it becomes MTC(Magpie Then Commit) or MTR(Magpie Then > Review) instead :) > > 4. Voting rights: > For this point, I think following the standard Apache-recommended model > would be the most natural approach. > > 5. Mailing lists: > I also agree with Justin’s opinion here. Separating dev@ and commits@ > seems like a clean and practical approach. > > Thanks, > Yeonguk > > On 2026/05/25 07:49:51 Jarek Potiuk wrote: > > Hello everyone, > > > > It’s great to be working with such an experienced group of ASF members, > and > > a warm welcome to those who are newer to our community! While we all know > > the general ropes, every project has its own unique rhythm. I’ve included > > some helpful links regarding ASF governance, but I would love for us to > > chat about how we want to shape our own path forward. > > > > As I transition from my initial "Benevolent Dictator" role to PMC chair, > > I’m really looking forward to hearing your perspectives. I have some > > thoughts, but I’m much more interested in the collective vibe of the > group! > > > > Here are a few friendly topics for us to explore: > > > > 1) Criteria for new Committers/PMC members: Should we lean toward a more > > relaxed approach for newcomers, or maintain stricter bars due to our > > architecture? I'd love to hear your thoughts on what qualities we should > > value most. > > > > 2) Valuing all contributions: Since so much of our work involves logic > and > > language, the line between "code" and "non-code" is beautifully blurred. > Do > > you think we should have distinct criteria for different types of help, > or > > should we celebrate all contributions under one umbrella? > > > > 3) Review processes (CTR vs. RTC): We’ve been moving fast lately to get > > Magpie ready, primarily using Commit-Then-Review. As we settle into a > more > > sustainable pace, would you prefer to stick with that or try > > Review-Then-Commit? Given how much AI open ways to have more PRs, it can > > assist our reviews (and dogfooding the process of making it efficient > > should be really helpful to make this part of Magpie right), I’m curious > > what feels right to you. > > > > 4) Voting Rights: How would you like to structure voting for the PMC and > > committers? Some projects prefer to keep these roles separate, while > others > > combine them—I'm open to whatever feels most inclusive for us. > > > > 5) Mailing List Volume: I’ve redirected PR notifications to the dev-list > > for archiving purposes. If this feels like too much noise, please let me > > know what is and is not useful! We can easily adjust to keep our > > communication clear and helpful. > > > > I’m so appreciative of everyone’s time and dedication. Please share your > > thoughts on these points or any other governance ideas you might have! > > > > Best, > > Jarek > > > > Some links for those who are not yet familiar with Apache Way: > > > > [1] Apache Voting Process https://www.apache.org/foundation/voting.html > > [2] Apache Community development https://community.apache.org/ > > [3] Apche Developer Information https://www.apache.org/dev/ > > [4] ASF Governance primer https://www.apache.org/foundation/governance/ > > >
