You are right, and thanks for the correction. My vote is -1 (non-binding), and my earlier message should be read that way. Apologies for the confusion: my mistake, not intentional.
The substance of my feedback stands as written, and I leave it to the IPMC members to weigh it as they see fit. On Mon, Aug 10, 2026 at 8:47 PM tison <[email protected]> wrote: > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
