diff --git a/src/blog/contributing-guidelines-2026.md b/src/blog/contributing-guidelines-2026.md
new file mode 100644
index 00000000..afd41609
--- /dev/null
+++ b/src/blog/contributing-guidelines-2026.md
@@ -0,0 +1,38 @@
+{%
+ author: [${tsc}, ${foundation}]
+ date: "2026-07-25"
+ tags: [governance]
+%}
+
+# AI Tools, Contributing Guide and Code of Conduct Updates
+
+## New Contributing Guide
+
+We have published a new [contributing guide](/projects/contributing-guide.md) for Typelevel organization projects and a [start contributing guide](/community/start-contributing.md) for new contributors!
+
+These guidelines cover similar ground to [the ones](/gsoc/ai.md) we have provided to Google Summer of Code applicants in the past. The new guide is an evergreen document to point any new contributor to for guidance. It covers where to start on an issue, copyright, and how to structure pull requests, and permitted use of AI tools.
+
+### AI-assisted Contributions
+
+With AI coding tools coming into wide use, it has become very easy for potential contributors to write code without thinking, resulting in contributions that are not actually helpful. To mitigate this, the contributing guide has two guidelines regarding AI-assisted contributions specifically. Individual projects may have additional restrictions in their own contribution policies, but the below is our default expectation:
+
+* We **are** allowing AI-assisted coding contributions. We expect contributors to disclose when they have used such tools and be responsible for their contributions regardless of how they are coded.
+* We are **not** allowing AI-generated text for any other purpose, including pull requests descriptions, issues descriptions, replies, documentation or other prose. We expect that contributors understand their work well enough to explain it themselves.
+
+While these tools can be used poorly, we recognize that they can be useful, especially for experts who can properly guide their output. However, to continue maintaining Typelevel projects, we need contributors who actually understand the code they are contributing. We are not interested in getting drive-by contributions from people that do not understand their contributions.
+
+Maintainers do not have unlimited time devote to their projects. As a contributor, please respect the time they are giving you by giving them your attention when you interact with Typelevel projects, rather than handing off the interaction to an AI tool. Generating a long and wordy description of something which can be more concisely and organically expressed serves no one's best interests. Rubber stamping something done even more autonomously by an AI in your name is even less useful.
+
+## Code of Conduct Update
+
+On the same vein, we have also made a small addition to the [code of conduct](../code-of-conduct/README.md), adding a new behavior to the "Our Community" section:
+
+> - **Using your own words.** We take the time to communicate with our own thoughts and writing.
+
+Similarly to how AI-generated text isn't permitted outside of code, we expect community members to also respect each other's time. We should put our own effort into their community interactions, not hand them off to an AI tool.
+
+### Use of Translation Tools
+
+We do understand that LLMs are excellent tools for bridging language barriers, and as always, we strive for the most inclusive environment possible on our projects and in our community spaces. To that end, we allow the use of AI tooling as a linguistic aid when English is not your primary language. Specifically, when you are authoring your own words in your own language and then leveraging a tool to translate those words to English prior to posting in a Typelevel forum, this is considered acceptable and even encouraged behavior.
+
+This is very different from fully autonomous authorship of long-form prose.
diff --git a/src/blog/directory.conf b/src/blog/directory.conf
index c1a3d905..bebe5555 100644
--- a/src/blog/directory.conf
+++ b/src/blog/directory.conf
@@ -9,6 +9,13 @@ typelevel {
bio: "The Typelevel Steering Committee was the former governing body of Typelevel, until the Foundation was established in 2025."
}
+tsc {
+ name: Technical Steering Committee
+ avatar: "https://github.com/typelevel.png"
+ github: typelevel/tsc
+ bio: "The Technical Steering Committee advises the board on overall technical priorities for the Foundation, especially the designation and stewardship of Organization Projects; and curates the portfolio of Typelevel Affiliate Projects, including soliciting and reviewing applications."
+}
+
foundation {
name: Typelevel Foundation
avatar: "https://github.com/typelevel.png"
diff --git a/src/code-of-conduct/README.md b/src/code-of-conduct/README.md
index 55ac9cbf..19f49102 100644
--- a/src/code-of-conduct/README.md
+++ b/src/code-of-conduct/README.md
@@ -20,7 +20,7 @@ Behaviors that reinforce these values contribute to a positive environment, and
- **Being respectful.** We're respectful of others, their positions, their skills, their commitments, and their efforts.
- **Gracefully accepting constructive criticism.** When we disagree, we are courteous in raising our issues.
- **Using welcoming and inclusive language.** We're accepting of all who wish to take part in our activities, fostering an environment where anyone can participate and everyone can make a difference.
-
+- **Using your own words.** We take the time to communicate with our own thoughts and writing.
## Our Standards
@@ -77,6 +77,11 @@ For questions related to our code of conduct, or to report possible violations,
* [Arman Bilge](mailto:arman@typelevel.org)
* [Lucas Satabin](mailto:lucas.satabin@gnieh.org)
+## Changelog
+
+* March 8, 2024: Initial version.
+* August 3, 2026: "Using your own words" behavior added.
+
## Attribution
This code of conduct is a modified version of the [Python Software Foundation Code of Conduct](https://www.python.org/psf/conduct), licensed under the [Creative Commons Attribution-ShareAlike 3.0 Unported License](https://creativecommons.org/licenses/by-sa/3.0/).
diff --git a/src/community/start-contributing.md b/src/community/start-contributing.md
index f8917847..1fa804ab 100644
--- a/src/community/start-contributing.md
+++ b/src/community/start-contributing.md
@@ -3,6 +3,7 @@
Typelevel projects power a large part of the functional Scala ecosystem. They are also complex, long-lived codebases with active communities. Contributing can feel intimidating at first, but even bug reports, small fixes, and documentation updates help move our projects forward!
+See also the [Contributing to Typelevel Projects](../projects/contributing-guide.md) for a detailed explanation of our contribution policies.
**Become a user of the ecosystem you want to contribute to.**
@@ -30,7 +31,7 @@ Typelevel projects power a large part of the functional Scala ecosystem. They ar
**Open a PR and iterate**
- Fork the repo, create a branch, and implement the change. Add or update tests where appropriate.
-- Open a PR with a clear description of the problem and your solution.
+- Open a PR with a clear description of the problem and your solution. Read the [Contributing to Typelevel Projects](../projects/contributing-guide.md) guide.
- Expect review feedback, ask questions, adjust your changes, and iterate.
## Where to Ask for Help
@@ -39,4 +40,6 @@ Typelevel projects power a large part of the functional Scala ecosystem. They ar
- Use library-specific channels like `#cats`, `#cats-effect`, `#fs2`, or `#http4s` for more focused questions.
- You can also ask directly on a GitHub issue if your question is specific to that issue.
-> **Note:** This guide emphasises learning and understanding. While most Typelevel projects accept AI written contributions, simply using such tools to fix a bug does not help you learn the codebase and gain the understanding needed to make more significant contributions.
+> **Note:** This guide emphasises learning and understanding. While most Typelevel projects accept AI written contributions, simply using such tools to fix a bug does not help you learn the codebase and gain the understanding needed to make more significant contributions.
+>
+> We recommend writing code yourself as you start contributing to a project.
diff --git a/src/projects/README.md b/src/projects/README.md
index 422f8644..9a6c9109 100644
--- a/src/projects/README.md
+++ b/src/projects/README.md
@@ -1,3 +1,4 @@
{%
laika.title: Typelevel Projects
+ laika.html.template = projects.template.html
%}
diff --git a/src/projects/contributing-guide.md b/src/projects/contributing-guide.md
new file mode 100644
index 00000000..ecd1be02
--- /dev/null
+++ b/src/projects/contributing-guide.md
@@ -0,0 +1,93 @@
+# Contributing to Typelevel Projects
+
+These guidelines apply when contributing to any Typelevel organization project. Please also refer to individual project guidelines for additional guidelines.
+
+Typelevel affiliate projects are also welcome to integrate these guidelines into their contributing guidelines.
+
+> This document focuses on policy. See also the [Start Contributing](../community/start-contributing.md) guide if you want step-by-step guidance on contributing to Typelevel projects.
+
+Welcome to the Contributing to Typelevel Projects guide. This document provides an overview of Typelevel's expectations when contributing to organization projects. At a very high level:
+
+We **want** contributors who are interested in gaining a deeper understanding of the projects they're working on, learning how and why they were built, and working with the community to improve our projects.
+
+We do **not** want contributors that increase the workload for maintainers without any gain for the project or any learning for the contributor.
+
+The following sections provide guidance on how to make contributions that fall into the first category.
+
+
+## Respect our Code of Conduct
+
+When you contribute to Typelevel, we expect that you respect our [Code of Conduct](/code-of-conduct/README.md).
+
+## Start With an Issue
+
+To contribute to a Typelevel project, start a conversation before creating a pull request. This can be in a new issue, continuing the conversation in an existing issue, or any other communication channel being used by the project. This gives maintainers and other contributors a chance to work with you on your idea at an earlier stage to make sure it is an acceptable contribution.
+
+When you are reporting a bug, your issue should clearly state the expected versus actual behavior you are observing. An ideal bug report includes a minimal reproducer that can easily be run (e.g. a scala-cli script, a small repository, or a saved Scastie) to demonstrate the issue. When you are unable to do so, please provide what other information you can, for example: specific steps that caused the issue, stack traces, or error messages.
+
+When you are reporting a security issue, *do not* open a Github issue. See the project security policy or the [Typelevel security policy](/security.md).
+
+## Pull Requests
+
+The following guidelines are particularly relevant for pull requests:
+
+### Respect Copyright
+
+You must be mindful of the copyright and patent rights of anything you submit.
+
+If you authored every part of your contribution and own the rights, this is not a problem. You can submit your contribution without reading further.
+
+However, any code or assets you took from somewhere else, including code generated by AI, may be subject to copyright or patent rights, which you must respect. In such cases, you need to check the license of the material.
+
+"Source-available" is **not** "open-source", and not all open-source licenses are compatible with each other. We strongly recommend against reading any "source-available" or incompatibly-licensed code before contributing to Typelevel projects.
+
+### Contribute One Change at a Time
+
+Each pull request should contain a single self-contained change. Avoid pushing multiple unrelated changes in the same pull request.
+
+As a rule of thumb, if your pull request could be split into two pull requests without breaking anything, it should probably be two separate pull requests.
+
+The exception to this rule is "batching changes", where you make the same kind of change to multiple places in the codebase. In this case, it is preferable to make one larger pull request instead of many small ones.
+
+> **Note:** Imagine yourself in the shoes of the reviewer: how can you make the PR easy to review and approve?
+>
+> This is best achieved if your pull request is simple, coherent, and uncontroversial.
+>
+> Limiting pull requests to one change at a time also simplifies the Git history, makes it possible to revert or cherry-pick specific changes, and reduces the potential of accidentally introducing bugs.
+
+### Explain Your Contributions
+
+When submitting a pull request, please make use of the pull request description.
+
+Your pull request description should, as clearly and succinctly as possible, in your own words, explain all the necessary information to understand the changes you made.
+
+For example, if you're just fixing a typo, a single sentence description is appropriate. However, if your change is large, we expect you to be more thorough with your explanation.
+
+Here are the components of a thorough pull request description:
+
+- **Summary of changes:** A short overview of what is changed.
+- **Motivation:** Why you opened the pull request. Ideally, this is a link to an issue.
+- **Related work:** Link to similar pull requests or ongoing discussions that provide additional context.
+- **Technical overview:** Briefly explain each of the changes in this pull request, and why they are necessary.
+- **Testing:** How you tested the pull request, and the results of your testing.
+- **Discussion:** How you see the pull request in context. For example, list risks and caveats and how they could be mitigated. If existing projects may be negatively affected, you should disclose this here, with particular attention to possible compatibility breakages and regressions.
+- **Additional work:** If applicable, highlight anything you need help with or feedback on, and describe any necessary or potential follow-up work.
+
+> **Note:** You may not need *every* one of these components, and you do not need to copy this exact structure. Always ask yourself what would be most helpful for reviewers, and try to balance brevity and thoroughness appropriately.
+
+### Contribute Only What You Stand Behind
+
+Only submit code that you understand, are prepared to explain to a maintainer, and be responsible for. This especially applies if you implement the idea of another person, copy code from elsewhere, or if you use AI tools to assist you with your contribution. In all of these cases, you must disclose which part of your submission wasn't fully authored by you. Regardless of the code's origin, by opening a pull request, you are putting your reputation as a contributor behind the code.
+
+#### Use of AI Tools
+
+You may use AI tools to help write code, but must write issue and pull request descriptions, documentation, code comments and other explanatory text in your own words. You are expected to understand the code you contribute well enough to write about the code yourself, regardless of how it was created.
+
+#### Use of Translation Tools
+
+While Typelevel communications are primarily conducted in English, our contributors and users are worldwide and may not be proficient in written English. Using machine translation tools (including LLM translation tools) to translate your writing to English is always acceptable. You may also include the original text in your message.
+
+
+---
+
+This document is based on the [Godot Pull request rules and guidelines](https://github.com/godotengine/godot-contributing-docs/blob/f46474c855c36883b61d0438414365c771ea78dd/pull_requests/pull_request_guidelines.rst) by the Godot Engine Contributors and is licensed under the [CC BY 3.0 license](https://creativecommons.org/licenses/by/3.0/deed.en).
diff --git a/src/projects/default.template.html b/src/projects/projects.template.html
similarity index 93%
rename from src/projects/default.template.html
rename to src/projects/projects.template.html
index b0ad82ac..a8cbd263 100644
--- a/src/projects/default.template.html
+++ b/src/projects/projects.template.html
@@ -13,6 +13,13 @@
Typelevel Projects
community guidelines. While not directly supported by the Foundation, these projects are designed to be compatible
with the overall Typelevel ecosystem.
+