Hi Mingcheng, > I am keeping my -1 (binding)
Thanks for sharing your comment. Please note that only votes from the Incubator PMC members are binding. Votes from everyone are welcome. As of today, I don't find that you're on the IPMC, so the quoted comment may be inaccurate. Of course, your feedback is well received. Best, tison. mingcheng <[email protected]> 于2026年8月10日周一 19:17写道： > Hi Jie, Guangdong, and Twice, > > Thanks for the detailed responses. I am keeping my -1 (binding), and I > would like to explain the reasoning more precisely and respond to the > points raised. > > Twice, one small note first: when referring to concerns already raised > on this thread, it would be more helpful to quote or link the original > message rather than write "some people are concerned". My -1 is on the > record with specific commit links, and summarising it as an anonymous > concern makes it harder for others to check what was actually said. > Not a big deal, just easier for everyone to follow. > > First, On the project history > > Jie's reply clarifies several things: the dense commit sequence > between May 20 and May 23 comes from a single-developer bootstrap > phase; development was heavily AI-assisted; some Git author identities > refer to the same person and the raw author count needs normalisation; > and development and review activity is still concentrated among the > initial contributors. > > I appreciate the transparency here, and it resolves my question about > whether activity had been inflated. It also settles the factual > picture: as of today, Maka has a codebase and a small number of > developers, and the community described in the proposal is still > mostly forward-looking rather than existing. That is the basis for my > vote, not the AI tooling itself. > > Second, On deferring provenance to IP clearance > > Guangdong mentioned that provenance will be reviewed as part of the > code transfer and IP clearance process. I agree that process will run, > but I don't think it covers the specific question here. > > SGA and ICLA establish that a contributor has the right to license > what they submitted. They do not establish whether a large, heavily > AI-assisted initial import contains material that is incompatible with > the Apache License. Under the ASF guidance on generative tooling > (https://www.apache.org/legal/generative-tooling.html), that > responsibility sits with the contributor, and it is easier to address > before the code enters the ASF than after. > > So I would like to ask, ideally during the vote window: > > 1. Roughly what share of the initial import was AI-generated or > AI-assisted, and with which tools? > 2. What review was applied to those outputs with respect to license > compatibility, and is that review recorded anywhere reviewable? > 3. If provenance cannot be established for some parts, is the plan to > remove and rewrite them, or to keep them pending discussion? > > If the answer is that all of this will be handled during incubation, > then the practical effect is that the mentors and the IPMC absorb the > cleanup work for a codebase whose provenance is still open. I would > rather we know the scope of that work before the vote closes than > discover it afterwards. > > Third, On "this is what the Incubator is for" > > Twice, I understand your argument, and I agree the questions you raise > are worth answering. I read the Incubator's role a bit differently: it > exists to help an existing community learn to operate the Apache Way > and to normalise IP and governance, rather than to test whether a > community can be grown from a standing start. When the latter does not > work out, the cost falls mainly on mentor time, IPMC review capacity > and the ASF's name. > > You also noted that the Incubator has little experience with this kind > of project, that it may challenge some existing ASF assumptions, and > that additional graduation metrics might be needed. I think those are > policy questions, and they are better settled on general@ as policy > than settled implicitly by accepting one proposal. My suggestion would > be to discuss what we expect from AI-native projects first, and then > evaluate proposals against that. > > If the IPMC does decide to accept Maka as a first case of this kind, I > would ask that the following be written into the proposal before > acceptance rather than left to later interpretation: > > - A concrete independence target, e.g. active committers from N > mutually independent organisations before graduation. > - A time box and exit condition, e.g. if the target is not met within > 12 months, a retirement discussion is opened. > - A disclosure and review requirement for AI-generated content. > - A requirement that technical decisions are made on the mailing list; > GitHub PR discussion alone does not satisfy this. > > With those in the proposal, I would be much less concerned about the > precedent. > > The last, What I would suggest instead: > > I have no objection to the technical direction, and the problem area > Guangdong describes is real. My concern is timing. > > A safer path would be another 6 to 12 months in the current > repository, turning the following from plans into facts: provenance of > the AI-assisted portions documented, two or three sustained > contributors from different organisations with real review weight, one > or two public releases, and design discussion moved to a public list. > A proposal after that would answer nearly every objection raised in > this thread on its own. > > I understand acceptance votes are decided by majority and that my -1 > does not block anything, and I am not trying to hold up the process. > My aim is to have these points on the record and tracked explicitly in > the mentors' and PPMC's early reports. > > On Mon, Aug 10, 2026 at 4:09 PM Twice <[email protected]> wrote: > > > > I saw that some people are concerned about the project's heavy use of > > AI in development, and whether this model can really build a genuine > > community. > > > > But I think this is exactly why the ASF Incubator is meaningful. We do > > not really know whether this development model can be sustainable in > > the long term, or whether it challenges some of ASF's existing ideas > > and principles. That is precisely why it is worth exploring. > > > > On one hand, ASF seems to have few general-purpose agent projects > > today, so bringing in something new in this area may have value and is > > worth experimenting with. > > > > On the other hand, the Incubator itself also has little experience > > with this kind of project. How should such a project develop during > > incubation? Should there be any additional metrics or requirements for > > graduation? If we can gain more experience with these questions > > through incubation, I believe that would be useful for ASF. > > > > So, +1 from me. > > > > Also, could you add me to the mentor list? I am quite interested in > > this project for the reasons above. > > > > Best, > > Twice > > > > On Mon, Aug 10, 2026 at 2:33 PM Guangdong Liu <[email protected]> > wrote: > > > > > > +1 (binding) > > > > > > I have reviewed the Maka proposal and the discussion. I support > > > accepting Maka into the Apache Incubator. > > > > > > Maka has a coherent technical direction: a local-first and > > > provider-neutral agent runtime and workspace, with Desktop, CLI/TUI, > > > and headless surfaces built around durable execution records, explicit > > > permission boundaries, and recoverable task and session state. This is > > > a meaningful problem area with value beyond any single model provider > > > or hosted control plane. > > > > > > The project also brings an existing public Apache-2.0 codebase and > > > public project materials for contribution, security, architecture, > > > design, changelog, and notices. I believe it has sufficient technical > > > substance and an initial community to begin the Apache incubation > > > process. > > > > > > I recognize the concerns raised about the project's young history, the > > > early contribution and import pattern, code provenance, and the need to > > > demonstrate a broader and more independent contributor community. > > > These are material concerns. I do not view incubation as evidence that > > > they are already resolved; rather, I expect them to be concrete early > > > milestones for the PPMC and mentors: public and verifiable provenance > > > and IP work, mailing-list-based decision making, transparent > governance, > > > and sustained growth of independent contributors and committers. > > > > > > On balance, I believe Maka is suitable to begin incubation and that the > > > Apache Incubator provides the right framework to address these matters > > > in public. > > > > > > Best regards, > > > Guangdong Liu > > > > > > On 2026/08/09 18:20:21 tison wrote: > > > > Hi everyone, > > > > > > > > Following the discussion thread [1], I call > > > > for a formal vote to accept Maka into the Apache Incubator. > > > > > > > > As a reminder, the Maka Proposal can be found at [2]. > > > > > > > > [1] https://lists.apache.org/thread/0n79l7dbz9jm694rpnbrxtn8f6lmnw1j > > > > [2] > > > > > https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/446070971/Maka+Proposal > > > > > > > > Please cast your vote: > > > > > > > > [ ] +1, Accept Maka into the Apache Incubator > > > > [ ] 0, I don't care > > > > [ ] -1, Do not accept Maka into the Apache Incubator, because ... > > > > > > > > The vote will remain open for at least 72 hours, and only votes from > the > > > > Incubator PMC members are binding. Votes from everyone are welcome. > > > > > > > > Thanks! > > > > > > > > Best, > > > > tison. > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > >
