In the past, I've suggested using a custom workflow in JIRA to make it easier for everyone involved to follow and understand the contribution process.  That's always languished, but the cumulative pain I was seeing prompted me to speak up again about it at the /dev meetup at the Conj on Saturday.

I've created a custom workflow that attempts to formalize my understanding of the contribution process (based on this for the most part), and attached it to a dummy project in JIRA.  The result is what I think is what would be a less confusing experience for everyone involved, with useful actions ('submit for screening', 'reject patch', 'change approved', etc) being elevated to workflow transitions rather than being represented by multiple edits involving custom fields in addition to default workflow transitions.

I started with the default JIRA workflow, and added two new states:

…with transitions to/from these states to the default JIRA workflow states (e.g. Open -> Ready, In Progress -> Ready, Screened -> Open, Screened -> Closed, etc).  You can see the net effect here:

I take no credit nor blame for the entirely shoddy presentation of state diagram that JIRA generates — click the graph-esque icon on the right of that page to see the current version of it. (Admin access required; a screenshot of the current draft workflow, and below that a hand-created figure that should be identical to the screenshot, but easier to follow

I've tested this with a dummy issue ( and I believe this now makes concrete most of workflow described and diagrammed on the wiki.  Feel free to abuse that issue, create others, and see how workflow feels.

Things that don't map well at the moment:

A final note: it would be good if most of the content of were replaced en masse with a link to — "even" I went to the former first (having forgotten about the latter), which is decidedly out of date AFAICT.