Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

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 <a href="/display/design/JIRA+workflow" data-linked-resource-id="1572892" data-linked-resource-type="page" data-linked-resource-default-alias="JIRA workflow" data-base-url="http://dev.clojure.org">this</a> 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:<ul><li>Ready for screening</li><li>Screened</li></ul>…with transitions to/from these states to the default JIRA workflow states (e.g. Open -&gt; Ready, In Progress -&gt; Ready, Screened -&gt; Open, Screened -&gt; Closed, etc).  You can see the net effect here: <a href="http://dev.clojure.org/jira/plugins/servlet/project-config/IGNOREJIRAEXP/workflows">http://dev.clojure.org/jira/plugins/servlet/project-config/IGNOREJIRAEXP/workflows</a> 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<img class="confluence-embedded-image" width="500" src="/download/attachments/8192121/Experimental-Clojure-dev-workflow.png?version=1&amp;modificationDate=1369258324665" data-image-src="/download/attachments/8192121/Experimental-Clojure-dev-workflow.png?version=1&amp;modificationDate=1369258324665" data-linked-resource-id="8552519" data-linked-resource-type="attachment" data-linked-resource-default-alias="Experimental-Clojure-dev-workflow.png" data-base-url="http://dev.clojure.org" data-linked-resource-container-id="8192121" title="Experimental-Clojure-dev-workflow.png" data-element-title="Experimental-Clojure-dev-workflow.png"><img class="confluence-embedded-image" width="300" src="/download/attachments/8192121/cemerick-flow-nice-figure.png?version=1&amp;modificationDate=1369258324644" data-image-src="/download/attachments/8192121/cemerick-flow-nice-figure.png?version=1&amp;modificationDate=1369258324644" data-linked-resource-id="8552518" data-linked-resource-type="attachment" data-linked-resource-default-alias="cemerick-flow-nice-figure.png" data-base-url="http://dev.clojure.org" data-linked-resource-container-id="8192121" title="cemerick-flow-nice-figure.png" data-element-title="cemerick-flow-nice-figure.png"> I've tested this with a dummy issue (<a href="http://dev.clojure.org/jira/browse/IGNOREJIRAEXP-1">http://dev.clojure.org/jira/browse/IGNOREJIRAEXP-1</a>) and I believe this now makes concrete most of <a href="/display/design/JIRA+workflow" data-linked-resource-id="1572892" data-linked-resource-type="page" data-linked-resource-default-alias="JIRA workflow" data-base-url="http://dev.clojure.org">workflow described and diagrammed on the wiki</a>.  Feel free to abuse that issue, create others, and see how workflow feels. Things that don't map well at the moment:<ul><li>Various states of the Patch and Approval fields.  There are no separate workflow states depending on whether a patch contains just code or code+tests (a good thing, IMO).  The draft workflow represents the other states of Patch explicitly.  I think the same goes for the Accepted field; the most important one there (&quot;incomplete&quot;) corresponds to an explicit &quot;Reject patch&quot; transition that automatically asks for a comment to be added to the issue.</li><li>The process of &quot;vetting&quot; (i.e. bucketing into a backlog vs. fast-tracked to Release.next based on importance), and the state change that goes along with it.  That can be added as a separate state in the workflow, but I haven't gotten to it so far.</li><li>There's currently no way to restrict a transition to the project lead, i.e. only Rich being able to &quot;OK&quot; a patch (or, a contrib project lead saying &quot;OK&quot;, though modeling that case seems like a non-issue at the moment).  Right now, approving a patch or closing or resolving an issue after an approved patch has been applied can only be done by &quot;Project administrators&quot;, which includes all members of jira-administrators *and* the current project lead.  Certainly not the right permissions, but more accurate than the current policy around the Approval field (diligently guarded by a &quot;Core team only, please&quot; label ;-)</li></ul>A final note: it would be good if most of the content of <a href="http://clojure.org/patches">http://clojure.org/patches</a> were replaced en masse with a link to <a href="http://dev.clojure.org/display/design/JIRA+workflow">http://dev.clojure.org/display/design/JIRA+workflow</a> — &quot;even&quot; I went to the former first (having forgotten about the latter), which is decidedly out of date AFAICT.