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]
