|  | 
| 1 | 1 | 🥥 🥝 🍌 🫐 | 
| 2 | 2 | 
 | 
| 3 |  | -This repo is for issues that: | 
|  | 3 | +> [!CAUTION] | 
|  | 4 | +> While this repo is named "internal" it is public to the world. Please do not | 
|  | 5 | +> post customer names or any other sensitive business information. | 
|  | 6 | +
 | 
|  | 7 | + | 
|  | 8 | +This tracker is for issues that: | 
| 4 | 9 | 
 | 
| 5 | 10 | * Are not relevant to the community, e.g. deeply composed tasks | 
| 6 |  | -* Heavily discuss internal company processes such as Sprints and long term planning | 
| 7 |  | -* Discuss named customers or other private information | 
|  | 11 | +* Discuss internal company processes such as Sprints and long term planning | 
| 8 | 12 | * Span multiple repos and have no clear primary repo | 
| 9 | 13 | 
 | 
| 10 |  | -Please continue using public, project-specific repositories for as many | 
| 11 |  | -issues as possible. Try to write issues in a way that engages users. | 
|  | 14 | +Please continue using project-specific repositories for as many | 
|  | 15 | +issues as possible.  | 
|  | 16 | + | 
|  | 17 | +## coder/coder goals | 
|  | 18 | + | 
|  | 19 | +`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. | 
|  | 20 | + | 
|  | 21 | +Please write issues in `coder/coder` in a way that engages users. | 
|  | 22 | + | 
|  | 23 | +## rules of thumb | 
|  | 24 | + | 
|  | 25 | +1. A public issue (even in this repo) should never link to a private resource such as a Notion page, Slack thread, etc. | 
|  | 26 | + 1. Take screenshots of slack threads, publish notion pages, or simply copy | 
|  | 27 | + relevant information into the issue. | 
|  | 28 | +1. All issues, regardless of repository, should have a body. | 
|  | 29 | +1. If you have an issue and think there's basically zero chance a user would react/comment on it, put it here. | 
|  | 30 | + | 
|  | 31 | +## this is weird | 
|  | 32 | + | 
|  | 33 | +Most companies solve the problem of open source tracker bloat by moving | 
|  | 34 | +a lot of core development activity into private trackers such as JIRA. We | 
|  | 35 | +have opted for a different approach because: | 
|  | 36 | + | 
|  | 37 | +* Sometimes it's hard to know where an issue should live, GitHub makes it easy to move issues between repositories | 
|  | 38 | +* We want developers to be highly comfortable with GitHub as a tool | 
|  | 39 | +* GitHub projects makes it easy to track issues across repositories, so we can | 
|  | 40 | +avoid a painful syncing process between a public and internal tracker | 
|  | 41 | +* If a community member begins engaging with the internal tracker, we can | 
|  | 42 | +use it as a sign that that type of issue should be moved to coder/coder | 
|  | 43 | + | 
|  | 44 | + | 
|  | 45 | +# transfers | 
|  | 46 | + | 
|  | 47 | +On some interval, @ammario and the PMs will move issues between here and the | 
|  | 48 | +community. Please take this as a sign that the issue should've been originally | 
|  | 49 | +created in a different place. | 
0 commit comments