My apologies, I was used to the workflow where the original requester (or a tester) Closes the Resolved issue once it has been verified as fixed.
While that might be useful for user-facing projects with GUIs etc, I don't think that is too useful for Commons RDF. So +1 to your proposed workflow of closing on release -- it also makes it cleaner to see what are 'unreleased fixes' without having to be too stringent on Fix For version on Resolved issues. On 23 April 2015 at 09:19, Sergio Fernández <[email protected]> wrote: > Hi, > > well, still many things to discuss to build a project. But because the > interaction with the issue COMMONSTDF-18, I'd like to bring to the table > the discussion about the jira workflow. > > Currently we hare using the Jira Default Workflow Scheme, you have it > depicted at: > > https://confluence.atlassian.com/download/attachments/185729632/jira-defaultworkflow.png > > In other projects what we do we resolved issues, but issues do not get > closed until they go out as part of a release (usually the release manager > does a bulk update). I personally like that simple convention, keeps a > pretty good overview about the current status. But I'm happy to listen to > other workflows. > > Cheers, > > -- > Sergio Fernández > Partner Technology Manager > Redlink GmbH > m: +43 6602747925 > e: [email protected] > w: http://redlink.co -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
