Who sets what

An issue carries a handful of labels and fields. The split is simple: facts are yours, judgements are ours — and the Portal never presents your proposal as our decision, or the other way round.

On the issue	Who sets it	Meaning
Title & description	You (editable by you afterwards)	The report itself
Type — Bug / Feature / Task	You propose on the form; the team confirms	What kind of work this is
Priority	You propose; the team sets the final priority	Your proposal tells us how it lands on your side
BC version	You	The version you saw the problem on
Target date	You (Features only)	When you'd need it — a wish, not a booking
Status — Open / Closed	You (your own issues) and the team	Whether work remains
Planned for	The team	The release your fix or feature is scheduled into

The lifecycle, in practice

1. You report — the issue opens, your organisation can read it, the team is notified.
2. We respond — questions and findings arrive in the thread; you get an e-mail per reply.
3. It gets scheduled — Planned for shows the release once the work is slotted.
4. It ships — the release appears under Releases, with notes.
5. It closes — by you when you're satisfied, or by the team with a closing reply. Reopen it if the problem returns; that beats filing a duplicate.