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