Issue templates: a form for reporting a bug and a form for asking for a feature

tiagoagueda commented

2026-10-01 10:29:14 +00:00

Owner

Requested by the maintainer on 2026-10-01, for every repository. The templates are written in the core first (postulo/postulo#351); this repository takes its own from those, with the fields that differ here.

New issue opens an empty box. Somebody reporting a bug has to guess what is needed, and the first reply is usually a question. A template asks once, at the start.

What to add

Forgejo reads issue templates from the repository itself: files under .forgejo/ISSUE_TEMPLATE/, either Markdown with a small header or YAML forms with typed fields, plus a config.yaml beside them that can switch off blank issues and add links shown above the choices. When templates exist, New issue offers them instead of an empty box.

A bug report (bug.yaml), labelled bug by itself, asking for what a fix needs:
- the extension's version, the browser and its version, and the operating system;
- the Postulo version it sends to;
- the kind of page it was used on (which job board), without requiring the address: a posting's address can say where somebody is applying;
- what was done, step by step; what happened; what was expected;
- anything from the logs, with personal details removed first. Postulo holds CVs, home addresses and the names of the people somebody is applying to; the form should say so in plain words above the box, because a pasted log or screenshot is where those leak.
A feature request (feature.yaml), labelled enhancement, asking for:
- the problem, and who has it, before the solution;
- what is proposed, and what else was considered;
- whether it is the extension's to do, or the core's (what the capture API accepts, how a page is read on the server): then the core gets an issue too.
config.yaml with links above the two forms:
- A security problem is not a public issue. Link to the core's SECURITY.md, which says how to report one privately. This is the most important line in the whole change: without it the bug form is where a vulnerability gets posted in the open.
- Translations: where to translate (postulo/postulo#349 decides the workflow), so a wrong word is corrected there rather than reported here.
- Questions: wherever the project wants them, if not in issues.
- Whether blank issues stay allowed. The maintainer files long, structured issues by hand; a form must not get in the way of that.

Forms should stay short. A field nobody will read is a reason not to finish the report; every field above is one the fix actually depends on.

For this repository

Most reports will be "this posting was read wrongly". The form should ask which fields came out wrong and what they should have been, and offer the popup's own diagnostic if it has one, rather than a screenshot of the whole page.
postulo-firefox and postulo-thunderbird are built from this repository's code; their forms send a parsing bug here.

Done when

New issue on this repository offers Bug report and Feature request, each applying its label, and shows the security link above them.
A report filed through the bug form carries what is listed above without anybody having to ask.
The forms match the core's wherever the fields are the same.

Requested by the maintainer on 2026-10-01, for every repository. The templates are written in the core first (postulo/postulo#351); this repository takes its own from those, with the fields that differ here. *New issue* opens an empty box. Somebody reporting a bug has to guess what is needed, and the first reply is usually a question. A template asks once, at the start. ## What to add Forgejo reads issue templates from the repository itself: files under `.forgejo/ISSUE_TEMPLATE/`, either Markdown with a small header or YAML forms with typed fields, plus a `config.yaml` beside them that can switch off blank issues and add links shown above the choices. When templates exist, *New issue* offers them instead of an empty box. - **A bug report** (`bug.yaml`), labelled `bug` by itself, asking for what a fix needs: - the extension's version, the browser and its version, and the operating system; - the Postulo version it sends to; - **the kind of page it was used on** (which job board), without requiring the address: a posting's address can say where somebody is applying; - what was done, step by step; what happened; what was expected; - anything from the logs, **with personal details removed first**. Postulo holds CVs, home addresses and the names of the people somebody is applying to; the form should say so in plain words above the box, because a pasted log or screenshot is where those leak. - **A feature request** (`feature.yaml`), labelled `enhancement`, asking for: - the problem, and who has it, before the solution; - what is proposed, and what else was considered; - whether it is the extension's to do, or the core's (what the capture API accepts, how a page is read on the server): then the core gets an issue too. - **`config.yaml`** with links above the two forms: - **A security problem is not a public issue.** Link to the core's `SECURITY.md`, which says how to report one privately. This is the most important line in the whole change: without it the bug form is where a vulnerability gets posted in the open. - Translations: where to translate (postulo/postulo#349 decides the workflow), so a wrong word is corrected there rather than reported here. - Questions: wherever the project wants them, if not in issues. - Whether blank issues stay allowed. The maintainer files long, structured issues by hand; a form must not get in the way of that. Forms should stay short. A field nobody will read is a reason not to finish the report; every field above is one the fix actually depends on. ## For this repository - Most reports will be "this posting was read wrongly". The form should ask which fields came out wrong and what they should have been, and offer the popup's own diagnostic if it has one, rather than a screenshot of the whole page. - postulo-firefox and postulo-thunderbird are built from this repository's code; their forms send a parsing bug here. ## Done when - *New issue* on this repository offers *Bug report* and *Feature request*, each applying its label, and shows the security link above them. - A report filed through the bug form carries what is listed above without anybody having to ask. - The forms match the core's wherever the fields are the same.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:29:14 +00:00

tiagoagueda added the

enhancement

documentation

labels

2026-10-01 10:29:14 +00:00

tiagoagueda referenced this issue from Postulo/postulo

2026-10-01 10:29:17 +00:00

Issue templates: a form for reporting a bug and a form for asking for a feature #351

tiagoagueda referenced this issue from a commit

2026-10-04 16:23:09 +00:00

Add issue forms for bugs and feature requests

tiagoagueda referenced this issue

2026-10-04 16:28:07 +00:00

Try the extension in a real Chromium and a real Firefox 140: the features of the 2026-10-04 round were only unit-tested #29

tiagoagueda commented

2026-10-04 16:28:09 +00:00

Author

Owner

Landed (1839b5f, .forgejo/ISSUE_TEMPLATE/): a bug form, a feature form and config.yaml with the security link. Left: not yet seen on the live Forgejo (templates show only once pushed, which they now are, so look at New issue); no Questions link because no place is decided; the bug form cannot offer the popup's own diagnostic because the popup has none; and the fields should be aligned with the core's forms once postulo/postulo#351 lands. Check the Weblate project URL and the SECURITY.md path in config.yaml.

Landed (`1839b5f`, `.forgejo/ISSUE_TEMPLATE/`): a bug form, a feature form and `config.yaml` with the security link. Left: not yet seen on the live Forgejo (templates show only once pushed, which they now are, so look at *New issue*); no *Questions* link because no place is decided; the bug form cannot offer the popup's own diagnostic because the popup has none; and the fields should be aligned with the core's forms once postulo/postulo#351 lands. Check the Weblate project URL and the SECURITY.md path in `config.yaml`.

tiagoagueda referenced this issue from a commit

2026-11-11 22:44:39 +00:00

Align the issue forms with the core's

tiagoagueda referenced this issue from a pull request that will close it,

2026-11-11 22:44:39 +00:00

Align the issue forms with the core's #57

tiagoagueda closed this issue

2026-11-11 23:39:24 +00:00