+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]
