Our current contributing guidelines have not been updated in a while, and while they provide good information for improving the low-level Julia -> Metal interface, there isn't really any information on what's expected/helpful when submitting and issue/PR.
I suggest adding this, as well as LLM guidelines, and moving that from the documentation into the repo so that it's easier to find.
Until I take the time to actually write them, here are some bullet points of things I think should be included. The guiding principle for all of these are to reduce back-and-forth between contributor and reviewer, and to speed up the process of getting a PR merged:
- LLM assistance policy: See below
- Formatting. These would also be added to the bot comment:
- No formatting of untouched existing code
- No formatting of modified code until it has been reviewed. (Ex. spacing between expressions. This makes it hard to differentiate between code changes and aesthetic changes)
- Recommend not using Runic for formatting the
@objc calls.
- MTL, MPS, MPSGraphs wrappers: Add some guidance around the general organization/structure of the low-level wrappers/high-level wrappers.
- Staying mindful of our limited CI resources (only 5 apple-silicon runners in buildkite shared between the julia community)
LLM use
Ghostty's policy aligns with how I feel about it (minus the part about personally using them a lot).
The main points of the policy would be:
- Disclose any use of AI assistance and the extent to which it was used (with an exception for short tab-autocomplete snippets)
- The submitter is still expected to fully understand their submission as if they had written it themselves.
- This includes having gone over the Pull Request/Issue description for hallucinations/inconsistencies.
- It's better to say you don't understand something than to include LLM hallucinations. This makes it easier to figure out what's wrong in issues, and helps reviewer to guide the contributor.
Our current contributing guidelines have not been updated in a while, and while they provide good information for improving the low-level Julia -> Metal interface, there isn't really any information on what's expected/helpful when submitting and issue/PR.
I suggest adding this, as well as LLM guidelines, and moving that from the documentation into the repo so that it's easier to find.
Until I take the time to actually write them, here are some bullet points of things I think should be included. The guiding principle for all of these are to reduce back-and-forth between contributor and reviewer, and to speed up the process of getting a PR merged:
@objccalls.LLM use
Ghostty's policy aligns with how I feel about it (minus the part about personally using them a lot).
The main points of the policy would be: