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]
