Redo README for new purpose

ammario · ammario · commit 4001840b2f12 · 2024-09-25T13:04:05.000-05:00
diff --git a/README.md b/README.md
@@ -1,11 +1,49 @@
 🥥 🥝 🍌 🫐
 
-This repo is for issues that:
+> [!CAUTION]
+> While this repo is named "internal" it is public to the world. Please do not
+> post customer names or any other sensitive business information.
+
+
+This tracker is for issues that:
 
 * Are not relevant to the community, e.g. deeply composed tasks
-* Heavily discuss internal company processes such as Sprints and long term planning
-* Discuss named customers or other private information
+* Discuss internal company processes such as Sprints and long term planning
 * Span multiple repos and have no clear primary repo
 
-Please continue using public, project-specific repositories for as many
-issues as possible. Try to write issues in a way that engages users.
+Please continue using project-specific repositories for as many
+issues as possible. 
+
+## coder/coder goals
+
+`coder/coder` is for end-users to connect with Coder engineers and product managers. Our most important issues will always live there. Bugs/improvements for released features should always live there.
+
+Please write issues in `coder/coder` in a way that engages users.
+
+## rules of thumb
+
+1. A public issue (even in this repo) should never link to a private resource such as a Notion page, Slack thread, etc.
+   1. Take screenshots of slack threads, publish notion pages, or simply copy
+   relevant information into the issue.
+1. All issues, regardless of repository, should have a body.
+1. If you have an issue and think there's basically zero chance a user would react/comment on it, put it here.
+
+## this is weird
+
+Most companies solve the problem of open source tracker bloat by moving
+a lot of core development activity into private trackers such as JIRA. We
+have opted for a different approach because:
+
+* Sometimes it's hard to know where an issue should live, GitHub makes it easy to move issues between repositories
+* We want developers to be highly comfortable with GitHub as a tool
+* GitHub projects makes it easy to track issues across repositories, so we can
+avoid a painful syncing process between a public and internal tracker
+* If a community member begins engaging with the internal tracker, we can
+use it as a sign that that type of issue should be moved to coder/coder
+
+
+# transfers
+
+On some interval, @ammario and the PMs will move issues between here and the
+community. Please take this as a sign that the issue should've been originally
+created in a different place.
