Add the new AI contribution policy

Author: Keavon

.github/pull_request_template.md

@@ -1,3 +1,13 @@
-<!-- Please reference any relevant issue number below, optionally with a "Closes"/"Resolves"/"Fixes" prefix -->
+<!--
+Graphite has ZERO-TOLERANCE for contributing undisclosed AI-generated content.
+If your PR involves AI, you must read our AI contribution policy (it's short):
+https://graphite.art/volunteer/guide/guide/starting-a-task/ai-contribution-policy
 
-Closes #
+REMEMBER:
+- You are responsible for thoroughly testing the successful implementation of your changes and ensuring no obvious regressions occur.
+- Egregiously dysfunctional PRs may be assumed to be undisclosed AI slop. If in doubt, ask on Discord before attempting a PR.
+- You are highly recommended to include a video showing the before-and-after behavior of your changes and screenshots of any new or modified UI.
+- Remember that Graphite maintains high standards for quality and the project is not a classroom for inexperienced developers to gain industry experience.
+- In this PR description, reference any relevant tasks by writing "Closes", "Resolves", or "Fixes" with the issue # or the URL of a Discord message documenting the task.
+- To acknowledge that you've read this, you must delete these rules and fill in the (strictly human-written) PR description in its place.
+-->

frontend/src/components/floating-menus/EyedropperPreview.svelte

@@ -66,6 +66,11 @@
 	.eyedropper-preview {
 		pointer-events: none;
 
+		.floating-menu-content.floating-menu-content {
+			border: none;
+			margin-left: 0;
+		}
+
 		.ring {
 			transform: translate(0, -50%) rotate(45deg);
 			position: relative;

website/content/volunteer/guide/_index.md

@@ -8,10 +8,22 @@ aliases = ["/contribute"]
 book = true
 +++
 
-Welcome, potential contributor! We're excited to have you join the Graphite project and it's our goal to make the process as smooth as possible. This guide will serve as your library of knowledge to help you get started contributing to the project. If you find any information missing or unclear, please let us know through Discord or submit a pull request to help document the process for future contributors.
+Welcome, potential contributor! We're excited to have you join the Graphite project. It is our goal to make the process as smooth as possible. This guide will serve as your library of knowledge to help you get started contributing to the project. If you find any information missing or unclear, please let us know through Discord or submit a pull request to help document the process for future contributors.
 
-The next page will cover how to compile the Graphite source code. But first, make sure you've joined our [Discord server](https://discord.graphite.art) and assigned yourself the *"🤖 Interested in contributing code"* role from the `#🙂welcome` channel. Done that? Alright, proceed!
+## Required experience level
 
-<p>
-<img src="https://static.graphite.art/content/volunteer/code-contributions.avif" onerror="this.onerror = null; this.src = this.src.replace('.avif', '.jpg')" alt="Flavor graphic depicting a library of knowledge in a digital realm" />
-</p>
+Our aim is to make the process as accessible as possible for first-time Graphite contributors with solid computer science foundations to get started, even without prior open source experience. Many contributors have remarked that they found our process notably more welcoming and straightforward than open source projects they've previously tried contributing to.
+
+However, please bear in mind that developing Graphite is **not for beginner programmers**. It is a complex, cutting-edge software engineering endeavor that requires at least a strong grasp of programming principles (although not necessarily Rust; you can learn that as you go).
+
+If you are at least a junior-level developer or a self-motivated student who has built a number of self-directed, non-trivial personal projects (especially if they involve graphics), then you should be well-prepared to contribute to Graphite. If you are only a couple years into your programming journey, be warned that you will find Graphite frustratingly above your current skill level and we will be unable to support you adequately. The Graphite project is **not a learning platform or a classroom for inexperienced developers**, but with the requisite skills, it is a great way to develop real-world engineering experience and get involved in something meaningful.
+
+Do not make the mistake of assuming AI tools and agents can be a substitute for your own skills and experience. If you use AI tools in your workflow, read our [AI contribution policy](./starting-a-task/ai-contribution-policy).
+
+## Discord communication
+
+The next page will cover how to compile the Graphite source code. But first, make sure you've joined our [Discord server](https://discord.graphite.art) and assigned yourself the *"🤖 Interested in contributing code"* role from the `#🙂welcome` channel. (And after your first PR is accepted and merged, you should post a request in `#📄development` to be assigned the *"Code Contributor"* role.)
+
+This is semi-mandatory, particularly if you intend to become a regular contributor on the team, because it is how our team communicates and is just as central to our process as GitHub.
+
+Done that? Alright, proceed to the next page!

website/content/volunteer/guide/codebase-overview/debugging-tips.md

@@ -9,7 +9,7 @@ The Wasm-based editor has some unique limitations about how you are able to debu
 
 ## Comparing with deployed builds
 
-When tracking down a bug, first check if the issue you are noticing also exists in `master` or just your branch. Open up [dev.graphite.art](https://dev.graphite.art) which always deploys the lastest commit, compared to [editor.graphite.art](https://editor.graphite.art) which is manually deployed from time to time for the sake of stability.
+When tracking down a bug, first check if the issue you are noticing also exists in `master` or just in your branch. Open up [dev.graphite.art](https://dev.graphite.art) which always deploys the lastest commit, as opposed to [editor.graphite.art](https://editor.graphite.art) which deploys the latest stable release. Build links for any commit may be found by clicking the "comment" icon on the right side of any commit in the [GitHub repo commits list](https://github.com/GraphiteEditor/Graphite/commits/master/).
 
 Use *Help* > *About Graphite* in the editor to view any build's Git commit hash.
 
@@ -19,13 +19,11 @@ Beware of one potential pitfall: all deploys and build links are built with rele
 
 Use the browser console (<kbd>F12</kbd>) to check for warnings and errors. Use the Rust macro `debug!("The number is {}", some_number);` to print to the browser console. These statements should be for temporary debugging. Remove them before your code is reviewed. Print-based debugging is necessary because breakpoints are not supported in WebAssembly.
 
-Additional print statements are available that *should* be committed.
+Additional print statements are available that *should* be committed:
 
 - `error!()` is for descriptive user-facing error messages arising from a bug
 - `warn!()` is for non-critical problems that likely indicate a bug somewhere
-- `trace!()` is for verbose logs of ordinary internal activity, hidden by default
-
-To show `trace!()` logs, activate *Help* > *Debug: Print Trace Logs*.
+- `trace!()` is for verbose logs of ordinary internal activity, hidden by default but viewable by activating *Help* > *Debug: Print Trace Logs*
 
 ## Message system logs
 

website/content/volunteer/guide/codebase-overview/editor-structure.md

@@ -7,7 +7,7 @@ css = ["/page/developer-guide-editor-structure.css"]
 js = ["/js/developer-guide-editor-structure.js"]
 +++
 
-The Graphite editor is the application users interact with to create documents. Its code is one Rust crate sandwiched between the frontend and Graphene, the node-based graphics engine. The main business logic of all visual editing is handled by the editor backend. When running in the browser, it is compiled to WebAssembly and passes messages to the frontend.
+The Graphite editor is the application users interact with to create documents. Its code is a single Rust crate that lives below the frontend (web code) and above [Graphene](../../graphene) (the node-based graphics engine). The main business logic of all visual editing is handled by the editor backend. When running in the browser, it is compiled to WebAssembly and passes messages to the frontend.
 
 ## Message system
 
@@ -43,11 +43,11 @@ Click to explore the outline of the editor subsystem hierarchy which forms the s
 
 ## How messages work
 
-Messages are enum variants that are dispatched to perform some intended activity within their respective message handlers. Here are two <span class="subsystem">DocumentMessage</span> definitions:
+Messages are enum variants that are dispatched to perform some intended activity within their respective message handlers. Here are two message definitions from <span class="subsystem">DocumentMessage</span>:
 ```rs
 pub enum DocumentMessage {
 	...
-	// A message that carries one named data field
+	// A message that carries one data field
 	DeleteLayer {
 		id: NodeId,
 	}
@@ -57,7 +57,7 @@ pub enum DocumentMessage {
 }
 ```
 
-As shown above, additional data fields can be included with each message. But as a special case denoted by the <span class="submessage">#[child]</span> attribute, that data can also be a sub-message enum, which enables hierarchical nesting of message handler subsystems.
+As shown above, additional data fields can be included with each message. But as a special case denoted by a <span class="submessage">#[child]</span> attribute, that data can also be a sub-message enum, which enables hierarchical nesting of message handler subsystems.
 
 By convention, regular data must be written as struct-style named fields (shown above), while a sub-message enum must be written as a tuple/newtype-style field (shown below). The <span class="subsystem">DocumentMessage</span> enum of the previous example is defined as a child of <span class="subsystem">PortfolioMessage</span> which wraps it like this:
 

website/content/volunteer/guide/starting-a-task/_index.md

@@ -7,9 +7,9 @@ page_template = "book.html"
 order = 3 # Chapter number
 +++
 
-There are two places to look for beginner-friendly development tasks. Usually, the best option is to select one of the many bite-sized task descriptions marked with a ‼️ reaction in the `#✅code-todo-list` channel of the [Discord server](https://discord.graphite.art). You may also browse the [task board](https://github.com/orgs/GraphiteEditor/projects/1/views/1), which lists [beginner issues](https://github.com/orgs/GraphiteEditor/projects/1/views/6) to pick from. The Discord option usually has the more approachable tasks compared to the GitHub issues, which tend to have more variability in complexity.
+There are two places to look for beginner-friendly development tasks. Usually, the best option is to select one of the many bite-sized task descriptions marked with a ‼️ reaction in the `#✅code-todo-list` channel of the [Discord server](https://discord.graphite.art). You may also browse the task board for a list of [beginner issues](https://github.com/orgs/GraphiteEditor/projects/1/views/6) to pick from. The Discord option usually has the more approachable tasks, compared to the GitHub issues that often have more variability in complexity.
 
-If you're unsure about which task to pick, feel free to ask in the `#📄development` channel.
+If you're unsure about which task to pick, feel free to ask in the `#📄development` channel. You can also use that channel to ask for coding help if you anticipate it will be a quick discussion rather than a longer-running conversation that deserves its own thread.
 
 You may right click a `#✅code-todo-list` task and select "Create Thread" to ask questions and discuss your development progress. If your work doesn't correspond to a specific listed task in that channel, you can also create a thread in `#🧵task-help` with a short, descriptive title ending with your issue or PR number.
 

website/content/volunteer/guide/starting-a-task/ai-contribution-policy.md

@@ -0,0 +1,23 @@
++++
+title = "AI contribution policy"
+
+[extra]
+order = 4 # Page number after chapter intro
++++
+
+Many open source projects including Graphite have begun to be spammed with an ever-increasing flood of low-quality PRs written partly or wholly by AI. These harm the project by wasting the time of maintainers and preventing PRs by genuine contributors from receiving timely review. We aim to be reasonable and understanding to contributors who put in the effort, but it has become necessary to set some strict rules against low-effort PRs.
+
+## Acceptable usage
+
+- Non-agent AI tools may **assist** with debugging and tab-completion of single lines of code you would have otherwise written yourself. This does not require disclosure.
+- AI chat tools (not agents) may help you **generate** small (sub-40 line) snippets of code that you manually copy and paste, provided that you carefully review every line to ensure it is consistent with how you would have written it yourself. This requires disclosure.
+
+## Unacceptable usage
+
+- AI slop, "vibe-coded", or agent-written PRs are strictly forbidden and may be treated as malicious spam attacks against the project, resulting in a ban.
+- PR description text and replies to reviewers must be written by you, not AI. If your English is imperfect, just try your best; it is better than AI babble.
+
+## Required disclosure
+
+- Graphite has **zero-tolerance** for contributing undisclosed AI-generated content.
+- A detailed, human-written description must accompany every line of material that you did not personally write using your own brain. It should justify why each line is correct and appropriate. This should be prepared ahead of time and written as self-review comments on the GitHub PR's diff immediately after the PR is opened or new code is pushed.

website/content/volunteer/guide/starting-a-task/code-quality-guidelines.md

@@ -9,7 +9,7 @@ The Graphite project prizes code quality and accessibility to new contributors.
 
 ## Linting
 
-Please ensure Clippy is enabled. This should be set up automatically in VS Code. Try to avoid committing code with lint warnings. You may execute `cargo clippy` anytime to confirm.
+Please ensure Clippy is enabled. This should be set up automatically in VS Code. Avoid committing code with lint warnings so the code review process goes smoothly. You may execute `cargo clippy` anytime to confirm.
 
 ## Naming
 
@@ -29,15 +29,15 @@ Always use the style `42.` instead of `42.0` for whole-number floats to maintain
 
 For consistency, please try to write comments (`//`) in *Sentence case* (with a capital first letter) and don't end with a period unless multiple sentences are used in the same comment. For doc comments (`///`), always end your sentences with a period. There should always be one space after the `//` or `///` comment markers, and `/* */` style comments should be avoided.
 
-Avoid including commented-out code, unless you have a compelling reason to keep it around for future adaption, in your PRs that are open for code review.
+Avoid including commented-out code in PRs that are open for code review unless you have a compelling reason to keep it around for future reference.
 
 Comments should usually be placed on a separate line above the code they are referring to, not at the end of the same code line.
 
 ## Blank lines
 
 Please make a habit of grouping together related lines of code in blocks separated by blank lines. These are like your paragraphs if you were writing a novel — they greatly aid readability and your copy editor would have significant concerns with your writing if they were absent.
 
-If you have dozens of lines comprising a single unbroken block of logic, you are likely not splitting it apart enough to aid readability. Find sensible places to partition the logic and insert blank lines between each. Roughly 10% of the code you write should ideally be blank lines, otherwise you are likely underutilizing them at the expense of readability.
+If you have dozens of lines comprising a single unbroken block of logic, you are likely not splitting it apart enough to aid readability. Find sensible places to partition the logic and insert blank lines between each. At least 10% of the code you write should ideally be blank lines, otherwise you are likely underutilizing them at the expense of readability.
 
 ## Imports