Note that the current workflow only really covers points 1-4, while 5 has no formal process at present and 6-8 are part of the Package Lifecycle which needs a high degree of automation to actually work in practice (if at all):

1. [User:] File Package Request (action)
(state is unpackaged)
2. [Packager:] Accept/Reject (action)
(now the package is in development, which is a state)
3. [Packager:] Package ready for QA (state/judgement)
(package builds and runs, quality undecided)
4. [QA:] Validated for inclusion (state/judgement)
(package builds and runs and satisfies quality criteria)
5. [Developer:] Included in -devel (action + state)
6. [Promoter:] Promoted from -devel to -qa (action + state)
7. [QA:] Validated for promotion from -qa to stable (state/judgement)
8. [QA Promoter:] Promoted from -qa to stable (action + state)

Instead of using 'Close Request' without relevant context in several places, we propose that the workflow transitions be renamed to 'Accept', 'Reject', 'Ready', 'Validated', 'Included' and 'Promoted' with contextually relevant descriptions.

• Resolve Issue
• Close Issue
• Link Issue

I did this because I feel that a reporter should at least be able to close their own issues as resolved/closed.

I'm as yet undecided on the Link issues, because I think that ideally, users should be able to get on board on bug-zapper weekends and feel like they can actually do stuff.

To paraphrase pscott, "What shouldn't a user be able to do?"