Hi, the workflow looks like this:
* A new issue is created -> the issue is in state "open" * Work begins -> perform workflow action "start progress" -> issue is in state "coding in progress" * Work is done -> perform workflow action "attach pull request" (enter the number of the pull request) -> issue is in state "pull request sent" * Pull request is applied on GitHub -> perform workflow action "pull request closed" (chose resolution, e.g. done) -> issue in state "resolved" * Double-check everything, perform action "close issue" -> issue is in state "closed" The screenshots in Dan's mail give quite a good impression of how it works. Currently I add a comment with an issue's pull request, so I think this would be quite useful. Gunnar 2011/3/19 Steve Ebersole <st...@hibernate.org> > So what are the states involved in the custom workflow? Transitions? > > On Saturday, March 19, 2011, at 09:30 am, Gunnar Morling wrote: > > Hi, > > > > while talking about JIRA configuration another thing came into my mind, > > which relates to the issue workflow. > > > > For Seam's JIRA Dan set up an enhanced workflow, which provides a closer > > integration with GitHub pull requests. For one there is a dedicated issue > > field "pull request", but also the issue lifecycle is linked to pull > > requests with a new issue state "pull request sent". > > > > IMO that's pretty useful as it improves visibility of the issue/pull > > request relationship and reduces chances, that pull requests get lost. > > More information can be found in this mail: > > > > > http://seam-framework.2283336.n4.nabble.com/git-pull-request-JIRA-workflow- > > td3272708.html > > > > In case there should be interest in using that workflow for Hibernate's > > JIRA I think Dan would happily provide more information how this was set > > up. > > > > Gunnar > > > > > > > > More information > > > > 2011/3/19 Gunnar Morling <gunnar.morl...@googlemail.com> > > > > > Right, for HV that notification scheme is used and I consider it > useful, > > > too. > > > > > > Gunnar > > > > > > > > > 2011/3/19 Hardy Ferentschik <hibern...@ferentschik.de> > > > > > >> I think it makes sense for all projects. I think Validator and Search > > >> are using it already. > > >> I not they should at least in my opinion. > > >> > > >> --Hardy > > >> > > >> On Fri, 18 Mar 2011 19:13:01 +0100, Steve Ebersole < > st...@hibernate.org> > > >> > > >> wrote: > > >> > I will be changing Hibernate Core JIRA project to use the > > >> > participant-based > > >> > notification scheme. Should I change over any other projects while > I > > >> > am in > > >> > there? > > >> > > > >> > What is participant-based notification? Basically, any participant > > >> > (reporter, > > >> > assignee and all commenters) is automatically notified on changes. > > >> > > > >> > --- > > >> > Steve Ebersole <st...@hibernate.org> > > >> > http://hibernate.org > > >> > _______________________________________________ > > >> > hibernate-dev mailing list > > >> > hibernate-dev@lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > > >> _______________________________________________ > > >> hibernate-dev mailing list > > >> hibernate-dev@lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > --- > Steve Ebersole <st...@hibernate.org> > http://hibernate.org > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
