Delegate Linear issues to devboxes
Set up devboxes in Linear
- Sign up for free.
- A Linear admin installs the devboxes app, and you choose which Linear team belongs to which devboxes project.
- Delegate an issue to devboxes, or mention @devboxes on it. Comments on the issue continue the conversation.
What devboxes sees
devboxes works only in the places you connect, on the projects you choose. It uses AI models, and their output can be wrong, so check the results before you rely on them.
Search Acme
support
2
-
@devboxes Müller GmbH and Brandt & Söhne both got their payment reminder twice, on Saturday and again on Monday. can you file it for billing in Linear? please don't fix it yet, Lisa wants to plan it in first
-
Looked at 4 sources - Read this thread
- Found Tuesday's reminder change
- Read the weekend rule in the reminder job
- Filed ENG-219 for billing
Since Tuesday's release, reminders due on a weekend move to Monday, and the job still sends the weekend one too, so those customers get both. I filed
ENG-219 for billing with a recommended fix and left the code as it is. Linear ENG-219 Weekend payment reminders go out twice
Backlog Billing, Bug
Filed ENG-219
-
Tasks that use Linear
- Turn a customer report into an issue Files the report with the team that owns it, so they start with the cause already found and a fix to try.
- Check whether a customer's problem is a known bug Tells you whether the team already knows about a customer's problem, and adds the new report to the issue that matches.
- Check whether a fix has shipped Tells you whether a customer's fix has shipped and which release first included it.
- Find out whether your product already does something Tells you whether your product already does what a customer is asking for, before you answer them.
- Prepare for a customer's renewal call Lists what a customer reported this year, and whether each report is fixed or open, before you talk to them.
- Scope a feature request into an issue Takes a request customers keep making and turns it into an issue that spells out what would have to change.
- Add acceptance criteria to an issue Adds acceptance criteria to a short issue, so the team builds what was actually meant.
- Split a large feature into smaller issues Breaks a feature that's too big for one change into smaller linked issues the team can take one at a time.
- Size a request before planning Gives you a rough size for a request before it goes into a plan, and says what drives that size.
