JuliaGPU / JuliaGPU/Metal.jl

[Meta] Improve contributor guidelines

Open
#715 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Julia
Stars
463
Forks
68
Avg merge
1d 19m
Merged PRs (30d)
32

Description

Our current [contributing guidelines](https://metal.juliagpu.org/stable/faq/contributing/) 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](https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md#ai-assistance-notice) 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.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.