# WhatProblem, full content > WhatProblem is a GitHub app that reads new issues and asks the questions a developer > would have to ask anyway, in the issue thread, within a minute or two of the issue being > filed. It is aimed at the round trip between a vague bug report and work somebody can > start. There is nothing to run and nothing to configure. Facts worth having right: - It works only through GitHub issue comments. It never touches pull requests, and it skips issues opened by bots. It responds a minute or two after an issue is opened. - One issue costs one unit of your monthly allowance, however many rounds it takes. Follow-up replies and the closing summary are not charged. There is a 10% grace band above the stated limit before it stops responding. - Commands are `!whatproblem analyze` and `!whatproblem stop`, commented on an issue. Stopping applies to that issue only, and can be undone with `!whatproblem analyze`. - A conversation runs for at most five rounds and closes itself after 24 hours of silence. - The beta allowance is 150 clarified issues a month for the first 100 installations. - Billing runs through the GitHub Marketplace. GitHub takes the payment, so refunds and cancellations are handled by GitHub rather than by WhatProblem. - Support: general questions on the public tracker, anything account-specific to support@whatproblem.dev. - WhatProblem is a trading name of Williams Initiatives Ltd, a UK company, number 14929985. ====================================================================== # Home # https://whatproblem.dev/ ====================================================================== WhatProblem - Build the right thing and build the thing right ## WhatProblem ## What problem are you trying to solve? Your automated detective that turns vague requests into crystal-clear requirements through intelligent conversation. Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ## The Universal Problem ## ๐Ÿ˜ค Sound Familiar? "Add export feature" โ†’ 6 weeks later โ†’ "Not what I wanted" "It's broken" โ†’ 20 messages later โ†’ Still unclear "Make it faster" โ†’ Wrong optimization โ†’ Performance worse Every unclear requirement costs days of rework. Every assumption risks building the wrong thing. ## How WhatProblem Works ## ๐Ÿ” Intelligent Clarification REQUEST: "We need a dashboard" โ†“ WhatProblem: "What decisions will this dashboard help you make?" โ†“ "Track team performance" โ†“ WhatProblem: "What indicates good performance for your team?" โ†“ "Delivery speed and quality" โ†“ WhatProblem: "How do you measure these today? What's missing?" โ†“ [Continues until requirements are crystal clear] โœ… RESULT: Complete requirements, first time, every time. ## Three Core Promises ## ๐Ÿ” Never Assumes, Only Clarifies No made-up features. No scope creep. Just thoughtful questions that uncover what's really needed. ## ๐Ÿ’ฌ Adapts to Any Conversation Works with detailed engineers and vague stakeholders alike. Keeps asking until everything's clear. ## ๐ŸŽฏ Uncovers Hidden Value Goes beyond "what" to understand "why" - revealing the business value that justifies the work. ## Where It Works โœ… GitHub Issues (public & private repos) ๐Ÿ”œ Pull Requests (coming soon) ๐Ÿ”œ Discussions (coming soon) ## Join the Beta ๐Ÿš€ 1-click installation ๐Ÿ”ง Zero configuration - just works Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ====================================================================== # Guides # https://whatproblem.dev/guides ====================================================================== Guides - WhatProblem ## Guides - Reference ยท 4 min read ## How to write a bug report A reference for what a bug report needs, why each part matters, and what to do when you cannot supply it. Written for the person filing, not the person receiving. Read it โ†’ - Reference ยท 3 min read ## How to triage an issue backlog A reference for deciding what happens to an incoming issue: the four possible outcomes, the order to check them in, and the traps that make backlogs grow. Read it โ†’ ====================================================================== # Blog # https://whatproblem.dev/blog ====================================================================== Blog - WhatProblem ## Blog - 1 August 2026 ยท 3 min read ## What a vague ticket actually costs, in numbers a manager can use The cost is not the developer's confusion. It is the wall-clock delay of a question crossing a timezone, multiplied by every unclear ticket you take. Read it โ†’ - 1 August 2026 ยท 4 min read ## The five questions that turn a vague issue into work someone can start Most bug reports are missing the same five things. Here is what to ask, why each one matters, and why teams so often do not ask at all. Read it โ†’ - 1 August 2026 ยท 4 min read ## Why issue templates get filled in with "N/A" Templates ask everyone the same questions regardless of what they are reporting. Here is why that fails, and what a template can realistically do instead. Read it โ†’ ====================================================================== # For maintainers # https://whatproblem.dev/for/maintainers ====================================================================== WhatProblem for Maintainers - Your First Line of Defense Against Vague Issues ## Your First Line of Defense Against Vague Issues Stop wasting days extracting basic information from bug reports. Let automation handle the detective work. Works on any public or private repository. Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ## The Maintainer's Daily Pain Monday: "Login broken" โ†’ Which login? โ†’ No response Tuesday: "Doesn't work on mobile" โ†’ Which mobile? โ†’ "iPhone" Wednesday: "Which iPhone?" โ†’ Which browser? โ†’ Ghost user Thursday: Close issue as "can't reproduce" Friday: Same issue reopened by someone else Sound exhausting? Because it is. ## Before & After ## โŒ BEFORE: "Submit button doesn't work sometimes" - 8 messages over 3 days - Still missing browser info - Can't reproduce - User frustrated and gone ## โœ… AFTER: "Submit button on checkout page fails" - Browser: Safari 17.2 on iOS - Error: "payment_token undefined" - Steps: Add item โ†’ Click checkout โ†’ Error - Fixed in 30 minutes ## Specific Benefits โฑ๏ธ Save 10+ hours/week on issue triage ๐Ÿ“ˆ Increase issue resolution by 3x ๐Ÿ˜Š Contributors provide better reports ๐ŸŽฏ Focus on fixing, not investigating ## How It Works 1 User opens issue: "Feature X is broken" 2 Bot responds in seconds with targeted questions 3 User provides details in structured format 4 You get complete, actionable issue 5 Ship fix instead of playing detective ## Beta Access โ€ข 1-click installation Perfect for: Open source projects, Team repositories, Corporate projects, Weekend side projects Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ====================================================================== # For product teams # https://whatproblem.dev/for/product-teams ====================================================================== WhatProblem for Product Teams - Ship Features, Not Clarification Requests ## Ship Features, Not Clarification Requests Turn stakeholder ideas into developer-ready specifications without the usual game of telephone. Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ## The Product Team's Reality STAKEHOLDER: "We need analytics" โ†“ YOU: Try to decode what they actually want โ†“ TICKET: "Add analytics dashboard" โ†“ ENGINEER: "This could mean 1000 different things" โ†“ RESULT: Wrong dashboard built, 3 sprints wasted ## The WhatProblem Difference REQUEST: "We need analytics" โ†“ WhatProblem: "What business decisions will these analytics inform?" "Track feature adoption" โ†“ WhatProblem: "Which features? What indicates successful adoption?" "New onboarding flow - need completion rates" โ†“ WhatProblem: "What's your target completion rate? Current baseline?" "Currently 45%, target 70%" โ†“ CLEAR SPEC: Feature adoption dashboard showing onboarding completion funnel with 45% baseline and 70% target ## ROI for Decision Makers โŒ Without WhatProblem 8 days per clarification cycle โœ… With WhatProblem 10 minutes to complete specs +40% Sprint velocity -60% Rework needed $$$ Saved on do-overs ## For Different PM Scenarios - Stakeholder requests โ†’ Technical specs - Customer feedback โ†’ Actionable features - Vague ideas โ†’ Clear requirements - Strategy โ†’ Developer-ready tickets ## Stop Being the Human Translator Let automation handle requirement gathering while you focus on strategy. Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ====================================================================== # For QA teams # https://whatproblem.dev/for/qa-teams ====================================================================== WhatProblem for QA Teams - Capture Every Detail, Every Time ## Capture Every Detail, Every Time Transform vague user complaints into reproducible bug reports that developers can actually fix. Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ## The QA Challenge CUSTOMER: "Site is slow" โ†“ SUPPORT: "We'll look into it" โ†“ QA: "Can't reproduce" โ†“ DEV: "Works on my machine" โ†“ CUSTOMER: "Still slow" โ†’ Churn The details were lost in translation. ## WhatProblem for QA REPORT: "Site is slow" โ†“ WhatProblem: "Which specific pages feel slow?" "Product search" โ†“ WhatProblem: "How long does it take? When did you notice this?" "30 seconds, started yesterday" โ†“ WhatProblem: "What search terms? How many results typically?" "'Blue widgets' - usually 500+ results" โ†“ ACTIONABLE BUG: Product search taking 30s for 500+ results Started: [date] Search term: "blue widgets" Expected: <3s Actual: 30s ## QA Superpowers ๐Ÿ” Complete reproduction steps โฑ๏ธ Specific performance metrics ๐Ÿ“ Environment details captured ๐ŸŽฏ Clear expected vs actual behavior ๐Ÿ“Š Severity based on user impact ## How It Fits Your Workflow 1 User reports issue in GitHub 2 WhatProblem clarifies automatically 3 QA gets complete bug report 4 Dev can reproduce immediately 5 Fix ships faster ## Better Bugs = Faster Fixes Turn vague complaints into fixable issues. Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ====================================================================== # For engineering managers # https://whatproblem.dev/for/engineering-managers ====================================================================== WhatProblem for Engineering Managers - Unblock Your Team Automatically ## Unblock Your Team Automatically Stop tickets from stalling due to unclear requirements. Get complete specs upfront, every time. Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ## The Hidden Productivity Killer ## ๐Ÿ“Š MEASURED - Sprint velocity - Story points - Deployment frequency ## ๐Ÿ• UNMEASURED Hours lost to "What did they mean by...?" Your team spends 30% of their time seeking clarification. That's 12 hours per developer per week. ## How WhatProblem Helps TICKET ARRIVES: "Need user export" โ†“ WHATPROBLEM CLARIFIES WITH REQUESTER: - Which user data? - What format? - Who needs access? - Compliance requirements? โ†“ DEVELOPER RECEIVES: Complete spec with all details No back-and-forth needed ## Metrics That Matter -85% Blocked tickets -70% Requirements churn +60% First implementation accuracy -75% Time to start coding ## For Your Specific Challenges - Product โ†’ Engineering communication - Stakeholder โ†’ Team requirements - Customer requests โ†’ Technical specs - Cross-team dependencies ## Give Your Team Complete Requirements See results in the first sprint. Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ====================================================================== # For developers # https://whatproblem.dev/for/developers ====================================================================== WhatProblem for Developers - Never Start Work With Half the Story ## Never Start Work With Half the Story When tickets arrive with complete requirements, you can actually build the right thing first time. Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ## Developer Life: Expectation vs Reality ## EXPECTATION: Ticket arrives โ†’ Clear requirements โ†’ Code โ†’ Ship โ†’ Done โœ“ ## REALITY: Vague ticket โ†’ Start coding โ†’ "Not what I meant" โ†’ 6 clarification meetings โ†’ Rebuild โ†’ "Still wrong" โ†’ Frustration level ๐Ÿ’ฏ ## Your New Reality SOMEONE REQUESTS: "Need API for mobile app" โ†“ WHATPROBLEM CLARIFIES (before it reaches you): "What data does the mobile app need?" "Which endpoints already exist?" "Authentication method?" "Rate limits?" โ†“ YOU RECEIVE: Complete API spec with all details - โœ“ Endpoints needed - โœ“ Data fields - โœ“ Auth: JWT - โœ“ Rate limit: 100/min ## Developer Benefits ๐ŸŽฏ Complete specs when ticket arrives โฑ๏ธ Start coding immediately ๐Ÿ”„ Fewer revision cycles ๐Ÿ“ Clear acceptance criteria ๐Ÿงช Testable requirements upfront ๐Ÿ˜Œ Build it right the first time ## How It Works 1 Someone creates unclear issue/ticket 2 WhatProblem asks them clarifying questions 3 They provide details 4 You get the complete picture 5 Code with confidence ## Code With Confidence Stop guessing. Start shipping. Install Free on GitHub ๐ŸŽ Beta users (first 100 installs) receive 150 clarified issues a month, free during beta testing -- beta seats remaining! ====================================================================== # Guide: How to write a bug report # https://whatproblem.dev/guides/how-to-write-a-bug-report ====================================================================== How to write a bug report - WhatProblem โ† All guides ## How to write a bug report Reference ยท 4 min read ยท kept up to date A bug report has one job: let somebody who was not there reproduce, or at least believe, what you saw. Everything below serves that job. Nothing below is bureaucracy. ## The short version - What you expected to happen. - What happened instead, literally, including "nothing". - How to get there , starting from a state a stranger can reach. - How often , and since when . - What you already ruled out. If you write nothing else, write the first two. They are the pair that separates a defect from a misunderstanding, and they are the pair most often missing. ## What you expected This is the part people skip because it feels obvious. It is not obvious to the reader, and it is the only part of the report that reveals what you were trying to do. A meaningful share of bug reports turn out to be disagreements about intended behaviour rather than faults. Stating your expectation is what surfaces that on day one instead of week three. Not useful The export is broken. Useful I expected the CSV to contain every row shown in the table, about 4,300. ## What happened instead Be literal. "It failed" covers at least eight distinct outcomes: an error message, a silent no-op, a spinner that never resolved, a partial result, a result that looked fine and was wrong, and several more. They are different defects. If there was an error message, paste the text. Not a screenshot of the text, if you can avoid it, because the text is searchable and the screenshot is not. If there was no error, say so explicitly: "no error, no warning" is a genuine finding and tells the reader the software did not know it had failed. ## How to get there Steps should start from somewhere the reader can also start. The most common failure in bug reports is steps that begin halfway through, from a state you had built up without noticing. Test each step against a stranger: could somebody who has never seen your setup do this? "Open the report you made earlier" fails. "Reports, then All Activity" passes. Name concrete data. "A large file" is not a fact; "a 4,300 row report" is, and the number may turn out to be the whole bug. ## How often, and since when Two short answers that decide how the ticket is handled. How often distinguishes "every time" from "once, and I moved on". Both are worth reporting. Only one of them is worth someone else's afternoon trying to reproduce. If you tried three times, say three times. Since when is the highest-value sentence in most reports. If it worked last week and does not work now, the search collapses to what changed in between. If it has never worked, you may be looking at a feature that does not exist rather than one that broke. ## What you already ruled out Almost everybody tries something before filing. They refresh, they try another browser, they ask a colleague whether it happens to them too. Almost nobody writes it down, so the next person repeats it. One line is enough: "Happens in Safari and Chrome, and to two colleagues as well." ## When you cannot reproduce it Unreproducible reports are still worth filing, but they need different content. Substitute: - A timestamp , even approximate. It converts the report into a log search, which is frequently better than reproduction. - An identifier : the account, the record, the request ID if one was shown. - What was unusual : first time using it, unusually large input, just after an update, poor connection. Those three turn "cannot reproduce" into "can investigate". ## What not to bother with Your diagnosis, presented as the problem. "The cache is broken" hides what you saw behind a guess. Say what you observed, then add the guess separately if you have one. It is often useful, just not as a substitute. Severity, unless you know how it is used. Most teams re-triage it anyway, and an inflated severity costs you credibility on the next report. Apologising for the report. "Sorry, this is probably my fault" makes readers discount it. If it turns out to be user error, that is still a finding: something was confusing enough to look broken. ## A complete example All five parts, four sentences Expected the CSV export from Reports, All Activity to contain all 4,300 rows shown on screen. Got a file with exactly 1,000 rows, no error and no warning. Reproduced three times from a fresh login on the QA account with the range set to 1 May to 29 July; it worked on 14 July when I ran the same report. Happens in Safari and Chrome, and to two colleagues on the finance team. That report is not longer because its author tried harder. It is longer because somebody asked the five questions, and every answer was already in their head when they sat down to file. ## WhatProblem does this in the issue thread It reads new GitHub issues and asks what is missing, a minute or two after they are opened, before anyone on your team has to. Install from GitHub Marketplace ====================================================================== # Guide: How to triage an issue backlog # https://whatproblem.dev/guides/how-to-triage-an-issue-backlog ====================================================================== How to triage an issue backlog - WhatProblem โ† All guides ## How to triage an issue backlog Reference ยท 3 min read ยท kept up to date Triage is deciding what happens to an issue, quickly, without doing the work. It is not prioritisation and it is not investigation. Confusing it with either is why most triage sessions overrun and most backlogs grow. ## There are only four outcomes Every incoming issue ends in one of these. Naming them makes triage faster, because the job stops being "think about this" and becomes "pick one". - Actionable. Somebody could start this today. It goes into the queue with a priority. - Needs an answer. Real, but not startable until a question is answered. - Not ours. A product decision, a support request, another team's, or working as designed. - Closed. Duplicate, obsolete, or unreadable. The second category is where backlogs go wrong, and it is worth being strict about it: an issue that needs an answer is not in the queue. It is waiting on a person, and if nobody is chasing that person it will wait forever. ## The order to check in Cheapest checks first, so you stop early. 1. Is it readable? If you cannot tell what it means in thirty seconds, it is not going to be worked on. Ask or close. Do not investigate. 2. Is it a duplicate? Search before reading closely. Merging early is much cheaper than merging after two people have commented on both. 3. Is it actually a defect? Ask what the reporter expected. If the expectation describes behaviour the software never had, this is a product decision and belongs with whoever owns that, with the reporter's own words attached. 4. Could somebody start it today? If not, name the single thing missing and ask for it. One question, not five. 5. Only now, how urgent? Priority is the last question, not the first, because three of the four outcomes above never reach it. ## The trap: triaging by writing quality Faced with a queue containing one crisp issue and one vague one, everybody picks the crisp one. It is the right local decision and it quietly reorders your roadmap by writing quality rather than importance. The correction is not to be more virtuous. It is to make the vague ones less vague at the moment they arrive, so that by the time anyone is choosing, the queue is comparable. Nothing you do at triage time fixes a distortion that was introduced at filing time. ## The trap: investigating during triage An issue looks interesting, somebody opens the code, and forty minutes disappear. The rest of the queue is now untriaged, and the forty minutes were spent on whichever issue happened to be intriguing rather than whichever mattered. Triage has a hard rule: no code. If an issue cannot be classified without opening an editor, classify it as "needs investigation", timebox it, and move on. ## The trap: the open issue that means nothing Every backlog accumulates issues nobody can interpret, often written by a colleague, sometimes by you. They resist closing because they might be important. They are not going to be worked on. Leaving them open advertises an intention that does not exist, and makes the backlog a less honest document. Close them with a comment saying they were closed for being unreadable rather than unimportant. If the problem is still real, it will be reported again by somebody who can currently see it. ## Cadence Triage decays fast. An issue triaged within a day gets a reporter who still remembers the details; one triaged after a fortnight gets silence. Little and often beats a weekly session. Ten minutes daily on new arrivals keeps the "needs an answer" pile moving, which is the pile that determines whether reporters keep reporting. ## What to measure Two numbers tell you most of what you need, and almost nobody tracks either. Time from filed to triaged. If this exceeds a couple of days, your clarifying questions are arriving after the reporter has moved on, and your answer rate will show it. The share of issues that needed a clarifying round trip. This is the tax you are paying on unclear reports, and it is the number that tells you whether anything you change at the filing end is working. ## WhatProblem does this in the issue thread It reads new GitHub issues and asks what is missing, a minute or two after they are opened, before anyone on your team has to. Install from GitHub Marketplace ====================================================================== # Blog post: What a vague ticket actually costs, in numbers a manager can use # https://whatproblem.dev/blog/what-a-vague-ticket-actually-costs # Published 2026-08-01 ====================================================================== What a vague ticket actually costs, in numbers a manager can use - WhatProblem โ† All writing ## What a vague ticket actually costs, in numbers a manager can use 1 August 2026 ยท 3 min read Engineers describe vague tickets in terms of annoyance. Managers have to describe them in terms of money, and the translation is usually done badly, because the obvious cost is the small one. The obvious cost is the developer's time: ten minutes reading a bad report, ten minutes writing a clarifying comment. Twenty minutes, call it ยฃ15. Multiply by a few hundred tickets a year and you get a number that is real but unpersuasive, and that any competent finance person will discount as noise. That number is wrong because it prices the wrong thing. ## The expensive part is wall-clock time, not work Here is what happens to a ticket that needs one clarifying question. - Day 0, 16:40. Reporter files "export is broken" and goes home. - Day 3, 09:15. It reaches the top of someone's queue. They read it, cannot start, and ask which export. - Day 3, 18:00. Reporter is in a timezone five hours behind and has finished for the day. - Day 4, 11:00. Reporter answers. - Day 4, 11:00 onwards. The developer is now mid-way through something else, so the ticket waits for the next slot. - Day 6. Work begins. Twenty minutes of effort, six days of latency. And every hour of that latency is one where a customer is still hitting the bug, a fix is still not shipped, and the ticket is occupying space in somebody's head. ## Three costs that do not appear on the timesheet The context switch is not twenty minutes. Reading a ticket, deciding you cannot act on it, and writing a question is an interruption with a tail. The developer had to load enough context to know the ticket was unanswerable, and that context is then discarded. Estimates for recovering deep focus vary between fifteen minutes and half an hour, and it happens twice: once going in, once when the answer arrives days later and they have to reload the whole thing. Unclear tickets get deprioritised, not clarified. This is the one nobody measures. Faced with a queue containing one crisp ticket and one vague one, everybody picks the crisp one, every time, and it is the right local decision. The vague ticket is not scheduled according to its importance, it is scheduled according to how well it was written. Over a quarter this quietly reorders your roadmap by writing quality, and you will not see it in any report. Reporters learn. Somebody who files a careful report and hears nothing for six days files a shorter one next time. The feedback loop teaches the opposite of what you want, and it teaches it to the people who were trying hardest. ## A number you can actually take to a meeting Do not price the effort. Price the delay, and price the queue distortion. Take your median time from issue filed to work started. Split your tickets into ones that needed a clarifying round trip and ones that did not. The difference between those two medians is the cost of vagueness, in days, per ticket, measured on your own data rather than an industry study. Most teams have never separated those two populations and are surprised by the gap. Then multiply by the number of tickets a year that needed a round trip. That is your annual delay, expressed in the only unit that matters to the person who asks when the fix ships. If you want a second number, count the tickets where the clarifying question was never asked at all, and the issue simply went quiet. In most trackers that population is larger than anyone expects, and it is pure waste: somebody took the time to report a real problem, and the organisation did nothing with it. ## The fix is timing, not discipline Every remedy that relies on the reporter writing better fails for the same reason: the reporter does not know what you need, and they never will, because they cannot see your code. What changes the number is when the question gets asked. Asked on day 3, it costs six days. Asked at 16:41 on day 0, while the reporter still has the failure on screen and their coat is not yet on, it costs about four minutes and the ticket arrives complete. Nothing else in the chain has to change. Same reporter, same question, same developer. Just asked while somebody is still there to answer it. ## WhatProblem asks these questions for you It reads new GitHub issues and asks what is missing, in the issue thread, before anyone on your team has to. Install from GitHub Marketplace ====================================================================== # Blog post: The five questions that turn a vague issue into work someone can start # https://whatproblem.dev/blog/five-questions-that-turn-a-vague-issue-into-work # Published 2026-08-01 ====================================================================== The five questions that turn a vague issue into work someone can start - WhatProblem โ† All writing ## The five questions that turn a vague issue into work someone can start 1 August 2026 ยท 4 min read The expensive thing about a vague issue is not the vagueness. It is the round trip. Somebody files "export is broken" on a Thursday afternoon. A developer picks it up on Monday, reads it twice, and asks which export. The reporter is in a different timezone, sees the question on Tuesday, and answers on Wednesday. Four working days have gone by and nobody has written a line of code or learned anything they could not have learned on Thursday. The fix is not better reporters. It is asking the questions at the moment the issue is filed, while the person still has the failure in front of them and the context in their head. There are five that do almost all of the work. ## 1. What did you expect to happen? This sounds like the softest question of the five and it is usually the most valuable, because it is the only one that recovers the reporter's mental model. "Export is broken" tells you a fact about the software. "I expected the CSV to contain every row I could see on screen" tells you what the software is for , in this person's hands, which is the thing you need in order to decide whether it is broken at all. A surprising share of bug reports turn out to be disagreements about intended behaviour. Those are worth finding on day one, because they are product decisions wearing a bug's clothing, and they do not belong in an engineer's queue at all. ## 2. What happened instead? Specifically, and preferably literally. "It failed" can mean an error dialog, a silent no-op, a spinner that never resolves, a partial result, or a result that looks fine and is wrong. Those are five different defects with five different owners. The word to be suspicious of is "sometimes". Sometimes usually means "I have not worked out the pattern yet", and the pattern is often the entire bug. It is worth asking directly: does it fail on every attempt, or did it fail once and you moved on? ## 3. How do I get there from a clean start? Reproduction steps are the one thing everybody already knows to ask for, and the one thing most often supplied in a form that does not work: steps that begin halfway through, from a state the reporter had already built up. The useful version starts from something the reader can also reach. A fresh session, a named test account, a specific record. If a step reads "open the report you made earlier", the ticket is not reproducible by anyone except its author. ## 4. How many people, how often, and since when? Three questions in one, and together they set the priority, which is not the reporter's job to guess but is very much their information to give. "Since when" is the highest-yield half of it. If something worked last week and does not work now, the search space collapses to what changed in between, and the ticket has effectively told you where to look. If it has never worked, you are dealing with a missing feature and a disappointed expectation, which is a different conversation. ## 5. What have you already ruled out? Almost nobody volunteers this and almost everybody has some. People try things before they file. They refresh, they try a different browser, they ask a colleague whether it happens to them too. That work disappears if nobody asks for it, and the developer repeats it. It also changes the tone of the ticket, from a demand to a handover. The reporter has done something, and the ticket says so. ## What that looks like in practice Before Export is broken. It worked before. Can someone look? After the same person answers five questions Expected the CSV export from the Reports page to contain all 4,300 rows shown on screen. Got a file with 1,000 rows, no error, no warning. Reproduced three times from a fresh login on the QA account, using the "All activity, last 90 days" report. Worked on 14 July, when I ran the same report for a board pack. Affects me and two others on the finance team, every time. I have already ruled out a browser issue: Safari and Chrome both produce a 1,000 row file. The second version is not longer because the reporter tried harder. It is longer because somebody asked. The 1,000 in that description is the whole bug, and it was in the reporter's head from the start. ## Why teams do not ask Everybody agrees these are the right questions. Very few teams ask them consistently, and the reason is social rather than technical. Asking a colleague to fill in a form feels like a rebuke, especially when the colleague is senior, or in another department, or a customer. So the developer guesses, or context-switches to go and ask in person, or quietly lets the ticket rot in triage. The questions do not get asked because there is no neutral party to ask them. Issue templates are the usual answer and they help, but they ask everybody the same thing regardless of what the issue actually says, so they are mostly ignored or filled in with "N/A". The questions that matter are the ones that follow from this report: nobody needs to be asked for reproduction steps on a feature request. ## The checklist - Expected: what should have happened, in the reporter's own words. - Actual: what happened instead, literally, including "nothing". - Path: steps from a state the reader can also reach. - Scope: how many people, how often, and since when. - Ruled out: what has already been tried. Five answers, usually five minutes, almost always on the day it is filed rather than the following Wednesday. That is the whole saving, and it is larger than it looks. ## WhatProblem asks these questions for you It reads new GitHub issues and asks what is missing, in the issue thread, before anyone on your team has to. Install from GitHub Marketplace ====================================================================== # Blog post: Why issue templates get filled in with "N/A" # https://whatproblem.dev/blog/why-issue-templates-get-filled-in-with-na # Published 2026-08-01 ====================================================================== Why issue templates get filled in with "N/A" - WhatProblem โ† All writing ## Why issue templates get filled in with "N/A" 1 August 2026 ยท 4 min read Every team that has been burned by a one-line bug report reaches for the same fix: an issue template. Required fields, a checklist, maybe a dropdown. Two months later the tracker is full of issues where half the fields say "N/A" and the reproduction steps say "see title". The template did not fail because people are lazy. It failed because it asks everybody the same questions regardless of what they came to say. ## A form cannot know what you are reporting A bug template asks for expected behaviour, actual behaviour, reproduction steps, environment and version. Now watch what happens when four different people meet it. Someone reporting a crash fills in all five and the template has earned its keep. Someone requesting a feature has no actual behaviour, no reproduction steps and no version that matters, so they type "N/A" three times and feel slightly stupid. Someone reporting a design problem has no version either. Someone reporting a documentation error has nothing to reproduce because the software worked perfectly, it was the page that was wrong. Three of the four learned that the form is mostly noise. And the lesson generalises: once a reporter has typed "N/A" into a required field, they have learned that fields are things you get past rather than things that matter. The next time they file a genuine crash, they will get past your reproduction steps field too. ## Required fields train people to lie Marking a field required does not produce an answer. It produces a answer. The person who does not have a version number types "latest". The person who cannot reproduce it types "happens sometimes". Both fields are now full, the form validates, and the ticket contains two statements that are worse than silence because they look like data. An empty field is a question you can still ask. A field containing "latest" is a question everyone now believes has been answered. This is the part that makes templates quietly expensive rather than merely ineffective. They do not just fail to collect information, they generate false confidence that the information was collected. ## What templates are actually good at They are good at exactly two things, and it is worth being clear-eyed about both. Routing. Splitting incoming work into bug, feature request and question, so it lands in front of the right person with the right label. That works because the reporter genuinely does know which of those they are doing. Setting a floor. A template says, in effect, "we expect a title and a paragraph, not a title". That is worth having even when nothing else in the form gets used. What they are bad at is the thing they get bought for: extracting the specific missing detail from a specific report. That detail changes with every issue, and a form is by definition the same every time. ## The alternative is a question, not a field When a colleague files something vague and you happen to be standing next to them, you do not hand them a form. You ask one question, and it is usually the right one, because you read what they wrote first. That is the difference. A template asks before reading. A person asks after. Everything a template does badly comes from being the wrong side of that line. The obvious objection is that nobody has time to read every incoming issue and compose a tailored question, which is true, and is why the "just ask them" advice has never scaled past small teams. But the reading and the asking are mechanical enough to hand off. That is the entire premise of what we build: read this issue, ask the two or three things this report is missing, in the thread, while the reporter still has the failure in front of them. ## If you keep the template, shrink it Assuming you are not ready to change anything else, the cheapest improvement is subtraction: - Make everything optional except the title. You lose nothing real and you stop manufacturing "N/A". - Split by type before you ask anything. A bug form and a feature form that each ask three relevant questions beat one form asking eight. - Cut every field you have never actually used to make a decision. Most teams have a version field they have not read in a year. - Ask for one example, not a category. "Paste one time this happened" gets you further than "how often does this happen". A short template that people fill in honestly is worth more than a thorough one they fill in to get past. That is a low bar, and most templates are under it. ## WhatProblem asks these questions for you It reads new GitHub issues and asks what is missing, in the issue thread, before anyone on your team has to. Install from GitHub Marketplace