That seems a reasonable workflow to me. I agree about the danger in this thing becoming a catch-all for every user-submitted failing test-case if people issue pull requests against it directly rather than attaching their archived version of it to a JIRA issue.
If we are in fact going to proceed this way however, its probably worth codifying this workflow in the README for the new test repo so that its clear that users aren't expected to issue pull requests to it directly but are instead to treat it more as a 'read-only' project intended only to jump-start their creation of a repro test case (since obviously the fork+pull model is more in keeping with the expected workflow github encourages). Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Sat, Sep 3, 2011 at 3:56 PM, Stuart Carnie <[email protected]>wrote: > Excellent, I can just remove my repo now and use the official in future. I > think the name is fine. > > Regarding the work flow for on the github repo, my thought was after > identifying an issue: > > - individual would clone official repo locally, > - add their test case to reproduce the issue (using the JIRA number as > the folder), > - submit archived project as an attachment to the JIRA issue > > Then the developer assigned to review and / or fix the issue can pull down > the attachment, and if confirmed to need a fix, copy the NH-#### folder > directly into the main test suite and resolve. > > If the fork on github and have contributors issue pull requests, you'll end > up turning this small test framework into a repository for all > user-submitted defects. > > Thoughts? >
