Add the new AI contribution policy

.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,7 +29,7 @@ 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.
 
@@ -37,7 +37,7 @@ Comments should usually be placed on a separate line above the code they are ref
 
 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
 

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

@@ -9,13 +9,17 @@ Collaboration is a key part of real-world software engineering. Graphite follows
 
 This assumes you understand enough about how Git works to utilize commits, branches, and multiple remotes. If you're new to Git, you will need to learn those topics on your own, but a good starting point is [this portion](https://youtu.be/vUzIeg8frh4?t=237) of the Graphite intro webcast which recommends installing the [Git Graph](https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph) extension for VS Code to visualize your Git history and branches.
 
+## AI usage
+
+If you are using any form of AI tools in your development workflow, you must read and comply with our [AI contribution policy](../ai-contribution-policy) before submitting your PR.
+
 ## Git branch name
 
 Before making your first commit, create a new branch with a name that describes what it's about. Aim for short but sufficiently descriptive. Kebab-case (using hyphens between words) is our usual convention. Don't include a prefix like `feature/` or `fix/` which just adds visual noise. An example like `fix-path-tool-selection-history` is fine, but almost too long.
 
-Rename it if you already made a branch with a different name. Create a new branch if you've been committing to `master` or another existing branch. If your branch is specifically called `master`, it becomes harder to work with during code reviews.
+**Warning: do not open a PR from a branch named `master`.** It makes code review considerably more difficult. Create a new branch if you've already been committing to `master` and open your PR from that correctly-named branch.
 
-After you push your branch to GitHub then open a PR, you won't be able to change its name. But please don't close a PR and open a new one just because the branch name isn't optimal. Just keep these tips in mind for the next time.
+After you push your branch to GitHub then open a PR, you won't be able to change its branch name. But please don't close a PR and open a new one just because the branch name isn't optimal. Just keep these tips in mind for the next time.
 
 ## Pull request
 
@@ -23,7 +27,7 @@ Once you have gotten your code far enough along that you are confident you'll be
 
 Later on when you are building larger features, a PR should be opened once you have meaningful progress. That way, it can be kept safe on GitHub and other maintainers can check in to see your status so your work is less of a mystery.
 
-Here's the important part: when you open a PR, it should be marked as a draft unless it is currently ready for review. The left image shows how to open a new PR as a draft, and the right image shows how to convert an existing PR to a draft.
+**Here's the important part:** when you open a PR, it should be marked as a draft unless it is currently ready for review. The left image shows how to open a new PR as a draft, and the right image shows how to convert an existing PR to a draft.
 
 <p><img src="https://static.graphite.art/content/volunteer/guide/draft-pr.avif" onerror="this.onerror = null; this.src = this.src.replace('.avif', '.png')" alt="Screenhots showing GitHub's &quot;Create pull request (arrow) > Create draft pull request&quot; and &quot;Still in progress? Convert to draft&quot; buttons" /></p>
 
@@ -45,7 +49,7 @@ As a bonus, it can be helpful for maintainers if you take a few minutes to write
 
 If you have concerns about a certain approach you took or if a certain part of your code is as clean as it could be, you can leave comments on lines of your own code from the "Files changed" tab after opening the PR.
 
-## Comment on the issue
+## Comment on the issue for assignment after it merges
 
 For any issue referenced in your PR (including tracking issues), we need you to leave a comment on issue. It doesn't matter what you write. You can just say "I opened PR #456" or something to that effect. This is only necessary because we will need to assign that issue to you upon merging your PR, but GitHub only allows assignments to those who have commented.
 
@@ -55,7 +59,7 @@ We don't commonly assign issues while a PR is still in progress, only upon landi
 
 ## Code review etiquette
 
-It is your responsibility to build the editor, thoroughly test your work, and employ common sense to avoid wasting a maintainer's time in needing to point out obvious flaws. It is not uncommon for inexperienced contributors to request review when their code entirely fails to implement the task at hand, or breaks surrounding functionality in a way that should have been immediately apparent. This doesn't leave a good impression and can frustrate maintainers.
+It is your responsibility to build the editor, thoroughly test your work, and employ common sense to avoid wasting a maintainer's time in needing to point out obvious flaws. It is not uncommon for inexperienced contributors to request review when their code entirely fails to implement the task at hand, or breaks surrounding functionality in a way that should have been immediately apparent. This doesn't leave a good impression and can frustrate maintainers. It may also be interpreted as AI-generated spam if the mistakes are egregious enough, which will lead to a ban according to our [AI contribution policy](../ai-contribution-policy).
 
 If you don't actually understand what is intended with your feature/fix and why this is meaningful to a user of Graphite, spend time becoming that user and understanding the context. [Learning](/learn) at least the basics of using Graphite is important. Then ask questions in Discord if you're still confused about specific edge cases or the wording of the task.
 
@@ -65,13 +69,15 @@ It is also common for larger tasks to enter a round of review to confirm the dir
 
 Before marking your PR as ready for review, you should do a self-review. That means reading over the diff of all your changes to ensure they are correct, complete, and lacking frivolous changes like unintended whitespace alterations, leftover debugging code, or commented-out lines. Read over it with a fine-toothed comb so maintainers don't have to nitpick as much. It is only fair that your first code reviewer should be yourself, so you catch the obvious flaws first.
 
+Feel free to leave comments on lines of your own code in the diff if you want to communicate concerns or highlight uncertainties to the maintainer. This is also where you must [disclose AI generated lines of code](../ai-contribution-policy) if applicable.
+
 ## Passing CI
 
 Upon pushing a commit to your PR's branch, CI will need to build and test your code. PRs from forks will have to wait until a maintainer approves the CI run. If you're uncertain, run `cargo test --all-features` on your machine or ask a maintainer to trigger CI for you.
 
-You also have to pass `cargo fmt` and `cargo clippy` locally before your PR can be merged.
+You also have to pass `cargo fmt` and `cargo clippy` in CI before your PR can be merged. You should run these commands locally before pushing to confirm.
 
-Your goal is for the check called "Editor: Dev & CI / build (pull_request)" to pass with a ✅. If it fails with a ❌, you will need to investigate. If you need access to the build logs, ask a maintainer to provide them. Occasionally, other checks may fail, but you likely won't be responsible for fixing those and they can be ignored.
+Your goal is for the check called "Editor: Dev & CI / build (pull_request)" to pass with a ✅. If it fails with an ❌, you will need to investigate. If you need access to the build logs, ask a maintainer to provide them. Occasionally, other checks may fail, but you likely won't be responsible for fixing those and they can be ignored.
 
 ## Keeping your work up-to-date
 
@@ -85,6 +91,8 @@ When your branch can be updated with `master` without conflicts, you can click t
 
 Be sure to pull the rebased, or updated-with-a-merge-commit, branch after you or a maintainer updates it (or pushes other commits to it) to ensure you are working on the latest code.
 
+**Please do not** constantly rebase or merge every day while you're waiting for review since it's unhelpful and gets annoying. A reviewer will do that for you if there are no conflicts. But if there are conflicts, you *will* need to resolve them and push the updated code before review.
+
 ## Review process
 
 Assuming you have done what's explained above, a maintainer will aim to review your PR within a few days if possible. Feel free to send reminders because PRs can get overlooked.
@@ -96,11 +104,11 @@ There are two parts to the review process, QA and code review, which occur separ
 - Quality assurance (QA): A build of your code will be opened and tested to ensure it implements the requested functionality and doesn't introduce regressions. This is not a substitute for your own testing, but it is a necessary line of defense against overlooked issues. This is usually performed by Keavon, the founder and product designer, whose eye for detail keeps the app polished and consistent. Maintainers (and only maintainers) have the ability to invoke CI by commenting "!build" on your PR which will produce a build link. That is a unique link hosting a build of your PR's current code.
 - Code review: The code will be checked for flawed approaches, pitfalls, confusing logic, [style guide](../code-quality-guidelines) adherence, sufficient comments and tests, and general quality. A review may be left through GitHub or your PR may have commits added to it. Feel free to read the diffs of those commits to understand what was changed so you can learn from that feedback. Direct commits are often faster than leaving dozens of comments. These can range from nitpicks to larger improvements. Our process is to collaborate on PRs as a team to write the best code possible, meaning your PR won't always be exclusively written by you.
 
-When changes are requested, the maintainer will usually mark the PR as a draft again while awaiting your updates. It is your responsibility to mark it as ready for review again once you've addressed the feedback.
+When changes are requested, the maintainer will usually mark the PR as a draft again while awaiting your updates. **It is your responsibility to mark it as ready for review** again once you have addressed the feedback.
 
 - If a PR is a draft, the ball is in your court to move it forward.
-- If it's marked as ready for review, it means there is nothing more for you to do until the maintainer has time to review it.
+- If it's marked as ready for review, it means there is nothing more for you to do until the maintainer has time to review it. (You're encouraged to work on other PRs while waiting.)
 
 After any number of back-and-forth cycles, a maintainer (usually Keavon who often gives the final say) will merge your PR. All your commits will be squashed into a single new commit on the `master` branch. This keeps the Git history linear and easy to follow.
 
-Congratulations on landing your successful contribution! Ping `@Keavon` on Discord to be given the "Code Contributor" role.
+Congratulations on landing your successful contribution! Post a request in `#📄development` on Discord to be assigned the *"Code Contributor"* role.

website/content/volunteer/guide/student-projects/_index.md

@@ -13,12 +13,15 @@ Student projects require adherence to a set schedule with regular check-ins, mil
 
 Use this [contributor guide](..) to start out with the code. Then when you're ready, reach out through [Discord](https://discord.graphite.art) and use the `#🎓student-projects` channel to discuss and work towards proposing a project with the Graphite core team.
 
+## AI contribution policy
+
+Be sure to familiarize yourself with our [AI contribution policy](../starting-a-task/ai-contribution-policy) before getting involved with the Graphite code base. Proposals also must not be written by AI or else they will be rejected.
+
 ## Google Summer of Code
 
 GSoC is a program offering students a [stipend](https://developers.google.com/open-source/gsoc/help/student-stipends) for successful completion of an internship-style experience with an open source organization. Read about [how it works](https://summerofcode.withgoogle.com/how-it-works/).
 
-<!-- Graphite [participated in GSoC 2024](https://summerofcode.withgoogle.com/programs/2024/organizations/graphite) and we anticipate doing so again in 2025 if our organization's application is accepted. Getting involved early is a great way to have a head start and stand out in your application. -->
-Graphite is [participating again in GSoC 2025](https://summerofcode.withgoogle.com/programs/2025/organizations/graphite). Applications closed [April 8](https://developers.google.com/open-source/gsoc/timeline). We accept year-round contributions; getting involved early is a great way to have a head start and stand out in your application in next year's program.
+Graphite participated in [GSoC 2024](https://summerofcode.withgoogle.com/programs/2024/organizations/graphite) and [2025](https://summerofcode.withgoogle.com/programs/2025/organizations/graphite) and we anticipate doing so again [in 2026](https://developers.google.com/open-source/gsoc/timeline) if our organization is accepted back. We accept year-round contributions; getting involved early is a great way to have a head start and stand out in your application in the upcoming program.
 
 ### Writing a proposal
 
@@ -33,7 +36,7 @@ When it comes to writing the proposal, which you will submit to the GSoC applica
 
 - **Proposal structure:** Please consult the [Blender GSoC application template](https://developer.blender.org/docs/programs/gsoc/application_template/) as reference for our desired format. For project ideas already listed below, omit the "Benefits" section. Remember: don't waste your—and our—time restating information that we already know, like background info about Graphite or our tech stack; we just want to hear your thoughts and plans about what you uniquely bring to the table and how you'll execute the project. Proposals should be utilitarian, not formal, while also demonstrating your professional communication skills. Using an LLM to write your proposal won't be to your advantage.
 - **Experience:** We're especially interested in your background and work experience, so attaching a résumé or CV is an optional but recommended way to help us understand your capabilities. If able, please also include links to past open source contributions or personal projects in the bio section. Our goal is to provide an environment for you to learn and grow as a productive software engineer and team collaborator, not to help you learn the basics of coding, so any included work examples will help us understand your potential as a self-motivated contributor to the open source community.
-- **Work timeline:** Your goal is to write a proposal that inspires confidence in your ability to successfully complete the project, which means understanding in detail what's involved at a technical level and how you plan to tackle it. A detailed work timeline is the most important written part of your proposal. It should be broken into weekly or bi-weekly milestones with a couple sentences of technical detail. The summary in the project idea list below doesn't give enough information to develop a timeline, so you'll need to discuss this with the core team on Discord.
+- **Work timeline:** Your goal is to write a proposal that inspires confidence in your ability to successfully complete the project, which means understanding in detail what's involved at a technical level and how you plan to tackle it. A detailed work timeline is the most important written part of your proposal. It should be broken into weekly milestones with a couple sentences of technical detail. The summary in the project idea list below doesn't give enough information to develop a timeline, so you'll need to discuss this with the core team on Discord.
 - **Prior PRs:** The largest factor in our selection decision will be the quality and extent of your prior contributions to Graphite made during the proposal formulation period (or before, if applicable). Include a link to `https://github.com/GraphiteEditor/Graphite/commits?author=YOUR_GITHUB_USERNAME` in your proposal and feel free to write up a summary of what you've contributed and learned from the process. You may also keep contributing during the month after applications close, before we've finalized our selections, for those additional PRs to be considered.
 
 </details>
@@ -55,7 +58,7 @@ These projects are more advanced but are highest priority for Graphite's develop
 
 *This is a newly added project pending a full written overview. Come ask on Discord for details.*
 
-- Build out infrastructure in the language/compiler/runtime/engine using [rust-gpu](https://github.com/Rust-GPU/rust-gpu) and/or [CubeCL](https://github.com/tracel-ai/cubecl).
+- Build out infrastructure in the language/compiler/runtime/engine using [Rust GPU](https://github.com/Rust-GPU/rust-gpu).
 - [See the GitHub issue.](https://github.com/GraphiteEditor/Graphite/issues/2168)
 - Best for someone with both an aptitude for low-level graphics programming (experience in one of WGPU, Vulkan, OpenGL, etc.) and an interest in compilers and programming languages.