* Set Common Understanding - We need to set the common words to be used and note there are two basic extremes. In essence, a spectrum from autocomplete to entirely machine generated output. We also have consensus that we expect code contributions to be made by humans, which may change as time moves on, outside of robotic process driven changes, for example requirements management or translation batch updates which occur today as well understood automated processes.

* Build a common Identification system for changes - Where and How it was used. Reach consensus with some sort of labeling for commit messages, for consistency across projects. There seems to be agreement that this needs to involve identification of the tool and most likely some level of quantity or percentage. The overall goal being to get this into general practice sooner rather than later, and to likely adopt the ASF suggested Generated-By tag, in addition to some other Generated-Percentage or Generated-Level tag. Naturally we would expect the latter to likely change through the process of code review.

* Establish bounds/guidelines for projects in what we expect, and what they can and cannot do. This likely includes alignment with the four opens so reviewers can attempt to determine how a tool might line up and if the contribution is able to be accepted, or not, based upon the tagging. This is the area we likely expect to explicitly name an example of what is not permissible, and possibly include a list of known tag values to aid consistency when it comes time to generate reporting.

The second area of consensus is in the form of two specific paths forward above and beyond an initial guidance document. Allison made a really good point that we should not block on either of these areas.

* We likely want to see some form of Attestation by the submitter of the change along the lines of DCO, that suggests "I've carefully reviewed this, I fully understand what it does, I have legal right to submit this along with a copyright assignment". In a sense, the DCO already sort of serves this purpose for some projects, but the variable of AI is an interesting one, and the consensus is that we expect there is a need for some cross-foundation collaboration on appropriate guidance since it is more than just our OpenInfra ecosystem.

* We want to see a centralized review guide to both provide guidance of things to look at/for, and also help serve the pipeline of reviewers in general. It might have principles such as "does style conform?", "Does CI pass?", but this is nowhere near an exhaustive list and we expect some iteration may be necessary with our communities and projects to have the right level/form of guidance.

Which leaves the next step. We'll provide a brief update during the upcoming board meeting[0], and have a call for participants to work together on drafting the guidance document. Once we have written words in a reviewable form, we'll reach out to our legal counsel for their input, and move forward from there.

Thanks,