https://github.com/coder/internal
Non-community issues related to coder/coder
https://github.com/coder/internal
Last synced: 18 days ago
JSON representation
Non-community issues related to coder/coder
- Host: GitHub
- URL: https://github.com/coder/internal
- Owner: coder
- Created: 2024-07-04T13:57:00.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2024-09-25T20:11:15.000Z (over 1 year ago)
- Last Synced: 2025-12-26T12:55:13.520Z (about 2 months ago)
- Homepage:
- Size: 1.95 KB
- Stars: 3
- Watchers: 0
- Forks: 0
- Open Issues: 363
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
🥥 🥝 🍌 🫐
> [!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
* Discuss internal company processes such as Sprints and long term planning
* Span multiple repos and have no clear primary repo
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.
## 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.
1. Strive to represent as much of your coder/coder work on coder/coder. Try to
make that work interesting to users.
## 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.