+1 binding. I’m happy to support this proposal and look forward to seeing the project move forward in the ASF.
Best, Huajie Wang Xuanwo <[email protected]> 于2026年8月11日周二 00:24写道： > +1 binding. > > I would be happy to mentor this project, and I'm glad to see that ASF can > help > incubate an AI agent project. > > On Mon, Aug 10, 2026, at 23:47, mingcheng wrote: > > Hi tison, > > > > That works for me, and it is the better option: repo docs get read by > > new contributors, but a proposal section does not. > > > > Nothing further from me. My vote stays at 0 (non-binding). Thanks > > for picking this up directly. :D > > > > Best regards, > > mingcheng > > > > On Mon, Aug 10, 2026 at 11:16 PM tison <[email protected]> wrote: > >> > >> > One small ask: the commitments in your message — AI-tooling > >> > disclosure, the provenance review of the initial codebase, removing or > >> > reimplementing anything whose licensing cannot be established, and > >> > moving project-level decisions to the dev list — currently live only > >> > in this thread. Could they be written into the proposal or the > >> > podling's initial documentation, so that mentors and future reviewers > >> > work from a single reference? I would also suggest the status of the > >> > provenance review appear in the first podling report, since that is > >> > the one item still outstanding as a plan rather than a completed > >> > check. > >> > >> I'd prefer to directly update the repo's README or other docs to include > >> that. Get it done without extra paperwork. > >> > >> Or if the initial committers need some time to figure it out, file an > issue > >> to track it down. > >> > >> Best, > >> tison. > >> > >> > >> mingcheng <[email protected]> 于2026年8月10日周一 23:00写道： > >> > >> > Hi Kun, > >> > > >> > Thank you, this is a substantive reply and it addresses most of what > >> > I raised. I accept your reasoning for not providing a percentage: if > >> > the repository does not preserve a reliable boundary between machine > >> > suggestions and human edits, a number would imply unsubstantiated > >> > precision. Documenting the tools, their use, the review practices and > >> > the verification evidence is more useful, and I withdraw that request. > >> > > >> > One small ask: the commitments in your message — AI-tooling > >> > disclosure, the provenance review of the initial codebase, removing or > >> > reimplementing anything whose licensing cannot be established, and > >> > moving project-level decisions to the dev list — currently live only > >> > in this thread. Could they be written into the proposal or the > >> > podling's initial documentation, so that mentors and future reviewers > >> > work from a single reference? I would also suggest the status of the > >> > provenance review appear in the first podling report, since that is > >> > the one item still outstanding as a plan rather than a completed > >> > check. > >> > > >> > Given the above, I am changing my vote to 0 (non-binding). My concerns > >> > about the project's age and the concentration of development have not > >> > disappeared, and I still think the project is early. But they are now > >> > recorded, acknowledged by the project, and scheduled to be tracked, > >> > which was what I wanted from raising them. I believe a continued -1 > >> > does not add value at this point, and I would prefer to see the effort > >> > focused on the first two podling reports. > >> > > >> > Thanks for engaging with this properly. Good luck with the incubation. > >> > > >> > Best regards, mingcheng > >> > > >> > On Mon, Aug 10, 2026 at 9:22 PM 李 坤 <[email protected]> wrote: > >> > > > >> > > Hi Mingcheng, > >> > > > >> > > Thank you for clarifying your concerns. We agree that the risks you > >> > identified are worth discussing and tracking. To avoid talking past > each > >> > other, I would like to explain how we currently view the four points > you > >> > proposed. > >> > > > >> > > First, regarding community independence: Maka is young, and we do > not > >> > claim that the community is already mature. The proposal currently > lists > >> > seven initial committers with seven different affiliations: four > companies, > >> > two universities, and one individual contributor. It also > acknowledges that > >> > some initial contributors have overlapping social and professional > >> > relationships. > >> > > > >> > > We agree that meaningful independence must ultimately be > demonstrated > >> > through sustained participation, review authority, release ownership, > and > >> > public decision-making—not merely through a list of affiliations. We > >> > therefore see this as an important graduation criterion and something > to > >> > track in podling reports, rather than something we should claim as > already > >> > proven at entry. > >> > > > >> > > Second, regarding a time box and exit condition: the proposal > already > >> > acknowledges the risks associated with the project’s young age. It > >> > estimates that incubation may take approximately two years, while > making > >> > graduation dependent on sustainable community growth, public > governance, > >> > shared release ownership, and compliant releases. > >> > > > >> > > If the project fails to develop a sustainable community, the > Incubator’s > >> > normal reporting and retirement processes already apply. We do not > >> > currently believe that a Maka-specific automatic retirement trigger > after > >> > 12 months is necessary, but we are willing to make community > diversity and > >> > shared ownership explicit items in the podling’s early reports. > >> > > > >> > > Third, regarding AI-assisted development: we agree that this > deserves > >> > clearer explanation. > >> > > > >> > > AI-assisted programming is already a common engineering practice > across > >> > the industry and the open-source community. In Maka, it is not > limited to > >> > Jie or to the initial bootstrap period. Multiple developers use > LLM-based > >> > tools independently while working on different parts of the project. > The > >> > resulting code is still proposed, reviewed, tested, integrated, and > owned > >> > by human contributors. > >> > > > >> > > For current collaborative development, Maka places particular > emphasis > >> > on review quality. In addition to human peer review, we use LLMs > >> > adversarially: a separate review pass, often using a separate model or > >> > context, is instructed to challenge the proposed implementation > rather than > >> > continue it. It looks for correctness problems, security risks, > missing > >> > tests, maintainability issues, unsupported assumptions, and > inconsistencies > >> > with the existing architecture. > >> > > > >> > > This adversarial LLM review is an additional review layer, not a > >> > replacement for human judgment. Human contributors remain responsible > for > >> > deciding whether a change is correct and acceptable. Automated tests, > type > >> > checking, builds, CI checks, and, where relevant, runtime or visual > >> > verification provide evidence independent of either the generating > model or > >> > the reviewing model. > >> > > > >> > > For that reason, we believe the meaningful question is whether a > >> > contribution has accountable human ownership and sufficient review and > >> > verification—not what percentage of its text can be attributed to an > LLM. > >> > The May 20–23 bootstrap period was heavily AI-assisted, but the > repository > >> > does not preserve a reliable token-level boundary between machine > >> > suggestions, human edits, review-driven revisions, and subsequent > >> > integration. Providing a percentage would therefore imply a precision > that > >> > we cannot substantiate. > >> > > > >> > > We can instead document, to the extent that it can be reconstructed > >> > reliably: > >> > > > >> > > - the primary tools used during the initial development; > >> > > - the areas and purposes for which they were used; > >> > > - the human and adversarial review practices applied; > >> > > - and the tests or other verification evidence supporting the > resulting > >> > code. > >> > > > >> > > Going forward, we are also willing to make AI-tool disclosure and > review > >> > expectations explicit for contributions, consistent with ASF > guidance. The > >> > contributor submitting a change will remain accountable for its > >> > correctness, licensing, and quality regardless of the tools used. > >> > > > >> > > LLM-based review is not treated as license clearance. The proposal > >> > separately commits the project to reviewing the provenance of the > initial > >> > codebase, checking source and dependency licensing, and removing, > >> > replacing, or reimplementing anything whose provenance or licensing > cannot > >> > be established. Such code will not be included in an Apache release. > >> > > > >> > > Finally, regarding public decision-making: we agree. The proposal > >> > already states that project-level decisions and voting will move to > the > >> > public development mailing list after entering incubation. GitHub > issues > >> > and pull requests may continue to support implementation-level > >> > collaboration, but they will not replace the mailing list for project > and > >> > community decisions. > >> > > > >> > > We are willing to improve the proposal by documenting the project’s > >> > AI-assisted development and review practices more clearly. At the same > >> > time, we believe that sustained community independence should be > >> > demonstrated during incubation, and that the normal Incubator > oversight and > >> > retirement mechanisms are sufficient without introducing a > project-specific > >> > 12-month exit rule. > >> > > > >> > > Thank you again for making these concerns explicit. > >> > > > >> > > Best regards, > >> > > Kun > >> > > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: [email protected] > >> > > For additional commands, e-mail: [email protected] > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > -- > Xuanwo > > https://xuanwo.io/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
