Conversation
tallen42
left a comment
There was a problem hiding this comment.
This should go in front of house for a discussion before it is merged in.
|
In general, I think this might be a little bit too far. Personally, I really like the approach the Kubernetes project (and various other LF/CNCF projects) have adopted: https://groups.google.com/a/kubernetes.io/g/dev/c/7Y9016gdFZw/m/nUUmxFPzAQAJ tl;dr: If it is AI, say so. Make sure it works and make sure you understand it. Be ready for questions or be ready for rejection. Learning to wield generative AI effectively is just as important as learning the concepts it is generating. I agree engineers should walk (code) before they run (vibe), in order to ensure they are designing the best systems. But this policy feels a little too black and white to support both ends of that spectrum. |
|
We should add stuff about the expectation to document your software and update any documentation that you make outdated |
Thank you @shaeespring @BigSpaceships @pikachu0542 for the contributions in the meeting! This is equally made by all of them.
|
|
||
| When you start working with any repository, your first step should always be reading that repository's [README.md](README.md) for specific instructions on how to setup and run a service locally so that you can make your super cool awesome changes! | ||
|
|
||
| All contributions must follow the contributions policies and CSH [Code of Conduct](https://coc.csh.rit.edu). Please use commit messages that align with both policies. We also recommend (but do not mandate) the use of [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) for commit message syntax. |
There was a problem hiding this comment.
Is there any standard around PR merge strategy for CSH repos? e.g. squash + merge vs merge commits?
IME the former has become much more popular over the years, but the latter is still used in larger projects like Kubernetes.
There was a problem hiding this comment.
We don't have a standard, mainly due to the nature of how PRs work in CSH (see another comment I left). I think we should probably write what we see though, which is squash + merge for smaller PRs and merge for larger PRs. We also tend to rebase from develop -> main (although this will soon be a force push with @BigSpaceships' bot).
There was a problem hiding this comment.
force push is scary but i dont have any context there
|
|
||
| ##Generative AI Policy | ||
|
|
||
| Using AI tools to help write your PR is acceptable, but as the author, you are responsible for understanding every change. If you used AI tools in preparing your PR, you must disclose this in the description of your PR. Listing AI tooling as a co-author, co-signing commits using an AI tool, or using the `assisted-by`, `co-developed` or similar commit trailer is not allowed. |
There was a problem hiding this comment.
If you used AI tools in preparing your PR, you must disclose this in the description of your PR.
Why is this important, and where is the line?
e.g. if I have copilot auto-complete a couple of lines or brackets, and nothing else, do I need to disclose that I used copilot?
There was a problem hiding this comment.
IMO, the line should be if you had any Gen AI tools enabled, and it provided any content in a chat or wrote to the files, then it was a contribution.
|
|
||
| ##Generative AI Policy | ||
|
|
||
| Using AI tools to help write your PR is acceptable, but as the author, you are responsible for understanding every change. If you used AI tools in preparing your PR, you must disclose this in the description of your PR. Listing AI tooling as a co-author, co-signing commits using an AI tool, or using the `assisted-by`, `co-developed` or similar commit trailer is not allowed. |
There was a problem hiding this comment.
co-signing commits using an AI tool, or using the
assisted-by,co-developedor similar commit trailer is not allowed.
This feels like it would be irrelevant in a world where we always use squash + merge?
There was a problem hiding this comment.
And also, why isnt this allowed? Its just metadata, yea?
There was a problem hiding this comment.
If we use squash+merge, this is true. However, we do different commits depending on the nature of the commit. We don't perfectly follow the one-feature or one-fix per PR, there's often major features plus a bunch of little fixes in a PR. While that is not good practice for a company, given the nature of CSH being a bunch of nerds doing things for fun in their free time, waiting for fixes to be merged while trying to work on a feature is inefficient and can lead people to drop the project. For larger PRs like that, it's easier to merge without squashing so we can revert single commits if needed.
There was a problem hiding this comment.
sure, thats fine, just might be worth being explicit that merge strategy is at the digression of the PR author (or whomever), since merge strategy has implications for commit quality on a given branch.
|
|
||
| Using AI tools to help write your PR is acceptable, but as the author, you are responsible for understanding every change. If you used AI tools in preparing your PR, you must disclose this in the description of your PR. Listing AI tooling as a co-author, co-signing commits using an AI tool, or using the `assisted-by`, `co-developed` or similar commit trailer is not allowed. | ||
|
|
||
| Large AI-generated PRs and AI-generated commit messages are not allowed. |
There was a problem hiding this comment.
I think there should be a general preference for smaller, stacked PRs, independent of AI usage. But thats just my $0.02.
There was a problem hiding this comment.
I agree and this should definitely be expanded upon. Part of this was written with the mindset of there being huge monolithic PRs with a ton of features and bug fixes all in one.
There was a problem hiding this comment.
Definitely. Can evolve over time as well.
| ##Documentation | ||
|
|
||
| All contributors are expected to document their software so that future contributors can easily understand what the code does and how to contribute to it. | ||
| If you make changes to any services, and those changes make existing documentation outdated, you are expected to update the relevant documentation as part of your changes. This includes setup of the environment for testing and production, e.g. Compose files, environment variables, database configuration, and more. |
There was a problem hiding this comment.
IMO, LLM steering, guidance, and context files should be treated like IDE files and left out of the repository since they're tools specific to the developer, and should probably be explicitly stated to be removed.
What
Adds a contributing.md with initial guidelines
Checklist