[admin] adds AI policy - #321
Conversation
Signed-off-by: Anton Dukhovnikov <antond@wetafx.co.nz>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #321 +/- ##
=======================================
Coverage 91.94% 91.94%
=======================================
Files 17 17
Lines 3800 3800
Branches 560 560
=======================================
Hits 3494 3494
Misses 306 306 Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
| Ideally, to the extent practical, the PR description should also have a brief | ||
| description of how the tool was used, including the gist of key prompts or | ||
| summarizing the direction of the dialog. A full log is not necessary; a short | ||
| summary will do. | ||
|
|
||
| There are several reasons for this disclosure/documentation, even though it | ||
| will sometimes be inconvenient: | ||
| - Reproducibility: We want even automated work to be reproducible by others in | ||
| principle, just like a scientific paper. | ||
| - Education: We want to actively teach each other what tools, prompts, or | ||
| methods are successful at making high quality results for the project. | ||
| - Metrics: We would like the ability to look back and compare assisted vs | ||
| non-assisted code for things like defect rate (how often were new bugs | ||
| introduced or commits needed to be reverted), whether people are more likely | ||
| to write comprehensive tests when using assistants, etc. | ||
| - Compliance: Many key users and developers are in companies where they need | ||
| to disclose how AI tools were used in their work, and in other software that | ||
| they use. Let's make it easy for them. | ||
| - Insurance: Should future legal decisions radically change the IP status of | ||
| AI-generated code, or if particular models are implicated in copyright | ||
| violations, we want a way to find out which contributions might need to be | ||
| revisited in order to bring the project back into compliance. |
There was a problem hiding this comment.
Hey, just as an FYI, I'm thinking about trimming this "summarize the dialog" aspirational section down quite a bit on the OIIO side, though I haven't decided quite what wording I want yet. I think this was me at the beginning of the process wanting to exert more control but without enough knowledge of the tools to do it right.
Several months into using them extensively and coming to understand the process in practice, I feel that it's almost impossible to give the detailed information this seems to request. The way I use it, it's often a very long mix of conversations, specs, undo and redo, and a lot of work still by hand, and there is no adequate way to summarize it, let alone give breadcrumbs for others to reproduce a particular change (other than, for the big ones, leaving the specs behind).
3 participants
Description
Tests
Checklist:
need to update the documentation, for example if this is a bug fix that
doesn't change the API.)
(adding new test cases if necessary).
already run clang-format before submitting, I definitely will look at the CI
test that runs clang-format and fix anything that it highlights as being
nonconforming.