docs: Update 4-goal.md

[freelerobot]

Describe Your Changes

Fixes Issues

• Closes #
• Closes #

Self Checklist

• Added relevant comments, esp in complex areas
• Updated docs (for bug fixes / features)
• Created issues for follow-up changes or refactoring needed

---

Important

Update .github/ISSUE_TEMPLATE/4-goal.md to focus on user roadmap goals with new sections for success criteria and more.

• Documentation:
  • Update .github/ISSUE_TEMPLATE/4-goal.md to focus on user roadmap goals.
  • Add sections for success criteria, non-goals, user research, design inspiration, and open questions.
  • Modify about field to "Roadmap goals for our users".

^{This description was created by for 376873b. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 376873b in 1 minute and 50 seconds. Click for details.

• Reviewed 46 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 4 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/ISSUE_TEMPLATE/4-goal.md:10

• Draft comment:
  Consider using 'one-liner' instead of '1 liner' for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While "one-liner" is technically more correct than "1 liner", this is an extremely minor stylistic issue in template text. The meaning is perfectly clear either way. This kind of nitpicky comment about writing style doesn't indicate any actual code or functionality problems. According to the rules, we should not make purely informative comments or comments that are obvious/unimportant. Perhaps consistent writing style is important for professional documentation that users will see? Maybe this helps maintain a polished appearance? While professional writing is good, this minor stylistic suggestion doesn't materially impact template usability or understanding. The rules specifically say not to make unimportant comments. This comment should be deleted as it's an unimportant stylistic suggestion that doesn't affect functionality or usability.

2. .github/ISSUE_TEMPLATE/4-goal.md:12

• Draft comment:
  Review example text 'Make onboarding to Jan 3x easier' for clarity and consistency with product naming.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to review text for clarity and consistency, which is not a specific code suggestion or a request for a test. It seems to be more of a general suggestion to ensure clarity, which violates the rule against asking the author to ensure things are clear or consistent.

3. .github/ISSUE_TEMPLATE/4-goal.md:20

• Draft comment:
  Consider replacing 'normie friendly' with a more professional term like 'user-friendly'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a style/wording suggestion in an example section. While "normie" is informal, it's clearly meant as an example and the casual tone might be intentional for internal documentation. The comment doesn't address any technical or functional issues. Templates often use a more casual tone to make them more approachable. The informal term could be seen as unprofessional if this template is used for external communication. The suggestion does make the language more professional. However, this is just an example in a template, and the casual tone appears intentional. The change isn't critical enough to warrant a comment. Delete the comment as it's purely about wording preference in an example section and doesn't affect functionality or clarity.

4. .github/ISSUE_TEMPLATE/4-goal.md:32

• Draft comment:
  Consider renaming 'Design inspo' to 'Design Inspiration' for a more formal tone.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is purely a stylistic suggestion about UI text. The rules explicitly state not to comment on UI or styling changes. The informal "inspo" was deliberately added in this PR, suggesting the casual tone was intentional. Even if it wasn't, this kind of minor wording preference doesn't warrant a comment. Maybe maintaining consistent formal tone throughout documentation is important for professionalism? The rules clearly state not to comment on UI/styling changes and to assume the author made these choices correctly. The informal tone could be intentional to make the template more approachable. This comment should be deleted as it violates the rule about not commenting on UI/styling changes.

Workflow ID: wflow_hsH5ur5BS4lbMCLI

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}