I am creating this from the discussion as part of ticket OFBIZ-3630.
My issue as a non-contributor was that there is no way to distinguish tickets that are created vs. ones that a fix as been proposed and attached. This was important for me because it provided me a way to see which of my tickets I have provided a patch for (and which I had just reported) as well as being able to search through tickets that I could "provide a helping hand on" -- each I clicked on actually already had a patch and were just sitting as unresolved. It seemed to me it also would provide a way for contributors to see which tickets have pending review / commit patches available vs. reported problems. I had proposed the use of the Resolved status for when a fix has been proposed and attached. This was under the influence from the "Contributors Best Practices" guide which suggested that bugs were immediately moved to Closed (and Resolved was not being used). From my understanding, the standard filters used by Contributors would cause this issues to not come up on their radar. If using Resolved in this way is not a reasonable solution, does anyone have a better solution? The easiest issue I can point to is OFBIZ-3100 (https://issues.apache.org/jira/browse/OFBIZ-3100) which has a big collection of sub-tasks, some of which are closed, reopened, resolved, and unresolved. |
Bob Morley wrote:
> I am creating this from the discussion as part of ticket OFBIZ-3630. > > My issue as a non-contributor was that there is no way to distinguish > tickets that are created vs. ones that a fix as been proposed and attached. > This was important for me because it provided me a way to see which of my > tickets I have provided a patch for (and which I had just reported) as well > as being able to search through tickets that I could "provide a helping hand > on" -- each I clicked on actually already had a patch and were just sitting > as unresolved. It seemed to me it also would provide a way for contributors > to see which tickets have pending review / commit patches available vs. > reported problems. > > I had proposed the use of the Resolved status for when a fix has been > proposed and attached. This was under the influence from the "Contributors > Best Practices" guide which suggested that bugs were immediately moved to > Closed (and Resolved was not being used). > > From my understanding, the standard filters used by Contributors would cause > this issues to not come up on their radar. If using Resolved in this way is > not a reasonable solution, does anyone have a better solution? The easiest > issue I can point to is OFBIZ-3100 > (https://issues.apache.org/jira/browse/OFBIZ-3100) which has a big > collection of sub-tasks, some of which are closed, reopened, resolved, and > unresolved. Do a search for the reporter==you, and status==patch available, or some other status. |
Are you suggesting adding a new workflow status "patch available" or the use of a label? I would be in favor of a "Pending Review" or some similar status. Perhaps ... Open -> In Progress -> Pending Review -> Resolved -> Closed Where Resolved may be skipped by the contributor? This would also provide a state where items may be reviewed by other contributors for large scale changes, etc. |
Bob Morley wrote:
> > Adam Heath-2 wrote: >> Do a search for the reporter==you, and status==patch available, or >> some other status. >> > > Are you suggesting adding a new workflow status "patch available" or the use > of a label? I would be in favor of a "Pending Review" or some similar > status. Perhaps ... > > Open -> In Progress -> Pending Review -> Resolved -> Closed > > Where Resolved may be skipped by the contributor? This would also provide a > state where items may be reviewed by other contributors for large scale > changes, etc. Er, have you actually tried to search for an issue? Click the Find Issues link in jira, and look at the available items you can search on. |
That status is not available for the Ofbiz project (it is as a status for Apache projects in general). If you do a find of the Ofbiz project the available statuses only include Open, In Progress, Reopened, Resolved, and Closed.
If you want to add this status to Ofbiz that would be great. |
In reply to this post by Bob Morley
Bob Morley wrote:
> I am creating this from the discussion as part of ticket OFBIZ-3630. > > My issue as a non-contributor was that there is no way to distinguish > tickets that are created vs. ones that a fix as been proposed and attached. > This was important for me because it provided me a way to see which of my > tickets I have provided a patch for (and which I had just reported) as well > as being able to search through tickets that I could "provide a helping hand > on" -- each I clicked on actually already had a patch and were just sitting > as unresolved. It seemed to me it also would provide a way for contributors > to see which tickets have pending review / commit patches available vs. > reported problems. > > I had proposed the use of the Resolved status for when a fix has been > proposed and attached. This was under the influence from the "Contributors > Best Practices" guide which suggested that bugs were immediately moved to > Closed (and Resolved was not being used). > > From my understanding, the standard filters used by Contributors would cause > this issues to not come up on their radar. If using Resolved in this way is > not a reasonable solution, does anyone have a better solution? The easiest > issue I can point to is OFBIZ-3100 > (https://issues.apache.org/jira/browse/OFBIZ-3100) which has a big > collection of sub-tasks, some of which are closed, reopened, resolved, and > unresolved. Starting a new response. Your use of Resolved is not correct. I reference https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#StatusTypes. Looking at that page, there doesn't seem to be a way for submitted to be involved in the workflow whatsoever, beyond the initial creation. |
If the use of Resolved is incorrect, that is fine. My terming of a "contributor" vs. a "non-contributor" may be incorrect as well. Would you consider anyone in the community that provides code a contributor or would that be reserved for people with "commit" privilege? In either case, there are a variety of existing JIRA statuses that could be added to the Ofbiz project to resolve this issue. The one that lines up with my initial thinking seems to be "Ready To Review" which would seem to reflect what the commiter would be doing (but a different status may make sense). Again, having another status here would help me (as someone that can not commit but is trying to provide code back to the project) and I would suspect it may help commiters more intelligently plow through the backlog of available patches. Wadaya think? |
On 31/03/2010, at 2:02 PM, Bob Morley wrote:
> My terming of a > "contributor" vs. a "non-contributor" may be incorrect as well. Would you > consider anyone in the community that provides code a contributor or would > that be reserved for people with "commit" privilege? Might help: http://www.apache.org/foundation/how-it-works.html#roles Regards Scott smime.p7s (3K) Download Attachment |
In reply to this post by Bob Morley
Bob Morley wrote:
> > Adam Heath-2 wrote: >> Your use of Resolved is not correct. I reference >> https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#StatusTypes. >> >> Looking at that page, there doesn't seem to be a way for submitted to >> be involved in the workflow whatsoever, beyond the initial creation. >> > > If the use of Resolved is incorrect, that is fine. My terming of a > "contributor" vs. a "non-contributor" may be incorrect as well. Would you > consider anyone in the community that provides code a contributor or would > that be reserved for people with "commit" privilege? > > In either case, there are a variety of existing JIRA statuses that could be > added to the Ofbiz project to resolve this issue. The one that lines up > with my initial thinking seems to be "Ready To Review" which would seem to > reflect what the commiter would be doing (but a different status may make > sense). > > Again, having another status here would help me (as someone that can not > commit but is trying to provide code back to the project) and I would > suspect it may help commiters more intelligently plow through the backlog of > available patches. In the past that has been handled informally through the dev mailing list. Jira emails the list to tell us when patches have been contributed. If you feel a Jira issue isn't getting the attention it deserves, you can make a comment in the issue to bump it to the mailing list. -Adrian |
In reply to this post by Scott Gray-2
Thanks Scott that explains the roles perfectly. |
In reply to this post by Adrian Crum
If we feel there is no need for a more formal status that indicates when a ticket is ready to be committed then that is cool. I have moved all of my personal tickets that I had moved to resolved and changed them back to reopen. I suspect I should have put a comment in them saying that they were ready for commit though as opposed to moving to reopen for further work ... |
I think it makes sense to have some way of distinguishing issues that have been filed from ones that have been filed and fix is provided - but I'm not sure about adding additional statuses to the workflow. Normally I'd totally agree (I've coded many workflows and creating custom statuses in JIRA and it's really powerful) - but I'm not sure how much access we would have to things at that level with infra.
Cheers, Ruppert On Mar 31, 2010, at 2:27 PM, Bob Morley wrote: > > > Adrian Crum wrote: >> >> In the past that has been handled informally through the dev mailing >> list. Jira emails the list to tell us when patches have been >> contributed. If you feel a Jira issue isn't getting the attention it >> deserves, you can make a comment in the issue to bump it to the mailing >> list. >> >> -Adrian >> >> > > If we feel there is no need for a more formal status that indicates when a > ticket is ready to be committed then that is cool. I have moved all of my > personal tickets that I had moved to resolved and changed them back to > reopen. > > I suspect I should have put a comment in them saying that they were ready > for commit though as opposed to moving to reopen for further work ... > -- > View this message in context: http://n4.nabble.com/Use-of-JIRA-Resolved-status-tp1747129p1747352.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
Seeing that other ASF projects had these statuses in play I took a quick search across these projects and was able to find one INFRA ticket that was very similar : http://issues.apache.org/jira/browse/INFRA-1659. This being the case, I suspect it would just be a matter of Ofbiz consensus and the right person cutting the INFRA ticket. My guess is that David Jones likely setup our ASF JIRA project and is likely our JIRA admin? (I seem to recall reading something that suggested a project could have two admins; but I do not recall). |
Administrator
|
Hi Bob,
Sorry for the "resolved" misleading. It was not a problem for me because I use another way to manage issues not closed. But anyway, It's only a matter of asking to infra. For instance, I have already asked to remove the question type at INFRA-2206. Thanks to your reference, I have asked for the same than INFRA-1659 at https://issues.apache.org/jira/browse/INFRA-2586 Jacques From: "Bob Morley" <[hidden email]> > Tim Ruppert wrote: >> >> I think it makes sense to have some way of distinguishing issues that have >> been filed from ones that have been filed and fix is provided - but I'm >> not sure about adding additional statuses to the workflow. Normally I'd >> totally agree (I've coded many workflows and creating custom statuses in >> JIRA and it's really powerful) - but I'm not sure how much access we would >> have to things at that level with infra. >> > > Seeing that other ASF projects had these statuses in play I took a quick > search across these projects and was able to find one INFRA ticket that was > very similar : http://issues.apache.org/jira/browse/INFRA-1659. This being > the case, I suspect it would just be a matter of Ofbiz consensus and the > right person cutting the INFRA ticket. My guess is that David Jones likely > setup our ASF JIRA project and is likely our JIRA admin? (I seem to recall > reading something that suggested a project could have two admins; but I do > not recall). > -- > View this message in context: http://n4.nabble.com/Use-of-JIRA-Resolved-status-tp1747129p1747620.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
In reply to this post by Bob Morley
Seems like something that would make things clearer so probably not a bad way to go. If there was a way to see from the attachments that we had an upload already, I'd probably go for that - but in the absence, the additional status seems like a reasonable request to me. +1
Cheers, Ruppert On Mar 31, 2010, at 9:44 PM, Bob Morley wrote: > > > Tim Ruppert wrote: >> >> I think it makes sense to have some way of distinguishing issues that have >> been filed from ones that have been filed and fix is provided - but I'm >> not sure about adding additional statuses to the workflow. Normally I'd >> totally agree (I've coded many workflows and creating custom statuses in >> JIRA and it's really powerful) - but I'm not sure how much access we would >> have to things at that level with infra. >> > > Seeing that other ASF projects had these statuses in play I took a quick > search across these projects and was able to find one INFRA ticket that was > very similar : http://issues.apache.org/jira/browse/INFRA-1659. This being > the case, I suspect it would just be a matter of Ofbiz consensus and the > right person cutting the INFRA ticket. My guess is that David Jones likely > setup our ASF JIRA project and is likely our JIRA admin? (I seem to recall > reading something that suggested a project could have two admins; but I do > not recall). > -- > View this message in context: http://n4.nabble.com/Use-of-JIRA-Resolved-status-tp1747129p1747620.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
Administrator
|
Done at https://issues.apache.org/jira/browse/INFRA-2586
But it seems there is still an issue... Jacques From: "Tim Ruppert" <[hidden email]> > Seems like something that would make things clearer so probably not a bad way to go. If there was a way to see from the > attachments that we had an upload already, I'd probably go for that - but in the absence, the additional status seems like a > reasonable request to me. +1 > > Cheers, > Ruppert > > On Mar 31, 2010, at 9:44 PM, Bob Morley wrote: > >> >> >> Tim Ruppert wrote: >>> >>> I think it makes sense to have some way of distinguishing issues that have >>> been filed from ones that have been filed and fix is provided - but I'm >>> not sure about adding additional statuses to the workflow. Normally I'd >>> totally agree (I've coded many workflows and creating custom statuses in >>> JIRA and it's really powerful) - but I'm not sure how much access we would >>> have to things at that level with infra. >>> >> >> Seeing that other ASF projects had these statuses in play I took a quick >> search across these projects and was able to find one INFRA ticket that was >> very similar : http://issues.apache.org/jira/browse/INFRA-1659. This being >> the case, I suspect it would just be a matter of Ofbiz consensus and the >> right person cutting the INFRA ticket. My guess is that David Jones likely >> setup our ASF JIRA project and is likely our JIRA admin? (I seem to recall >> reading something that suggested a project could have two admins; but I do >> not recall). >> -- >> View this message in context: http://n4.nabble.com/Use-of-JIRA-Resolved-status-tp1747129p1747620.html >> Sent from the OFBiz - Dev mailing list archive at Nabble.com. > > |
Hey -- It seems that the ticket we pointed INFRA to had a original request for the "Patch Available" workflow status to be added, but through the comments (which I should have read initially) they went with a new ticket attribute named "Patch Available" as a tick/boolean. This has caused some confusion, and I think it is generally better to have the workflow status available so I have commented on the INFRA-2586 ticket and hopefully Gavin will revert the "tick" and go with the workflow status. |
Administrator
|
Thanks for clarifying Bob
Jacques Bob Morley wrote: > Jacques Le Roux wrote: >> >> Done at https://issues.apache.org/jira/browse/INFRA-2586 >> But it seems there is still an issue... >> >> Jacques >> > > Hey -- It seems that the ticket we pointed INFRA to had a original request > for the "Patch Available" workflow status to be added, but through the > comments (which I should have read initially) they went with a new ticket > attribute named "Patch Available" as a tick/boolean. This has caused some > confusion, and I think it is generally better to have the workflow status > available so I have commented on the INFRA-2586 ticket and hopefully Gavin > will revert the "tick" and go with the workflow status. |
Administrator
|
I checked the actions workflow in the OFBIZ-3628, and thanks to Gavin all seems OK now
Jacques From: "Jacques Le Roux" <[hidden email]> > Thanks for clarifying Bob > > Jacques > > Bob Morley wrote: >> Jacques Le Roux wrote: >>> >>> Done at https://issues.apache.org/jira/browse/INFRA-2586 >>> But it seems there is still an issue... >>> >>> Jacques >>> >> >> Hey -- It seems that the ticket we pointed INFRA to had a original request >> for the "Patch Available" workflow status to be added, but through the >> comments (which I should have read initially) they went with a new ticket >> attribute named "Patch Available" as a tick/boolean. This has caused some >> confusion, and I think it is generally better to have the workflow status >> available so I have commented on the INFRA-2586 ticket and hopefully Gavin >> will revert the "tick" and go with the workflow status. > |
Free forum by Nabble | Edit this page |