Pierre,first of all, I don't see why you are separating contributors and committers. We are all contributors and there is no distinction inside the Jira workflow.
Jira is a tool to report and track issues, support the workflow to solve it, document the solution history and discussions around it. The assignee makes visible who is *currently* working on the issue. The process starts with the creation of the issue by the reporter and ends with closing the issue by the last assignee. This can be any contributor, depending of the kind of issue and the action it takes to close the issue.
If the last action does not require a commit to the codebase, it can be any contributor.
If the last action is a commit to the codebase, the last assignee is a contributor with the role of a committer, naturally. End of process. It's really simple.
Jira is in no way designed or suitable to track individual's credits or measure the amount and value of the work a contributor has done for an issue.
This would require an accepted measurement of all contributions, their complexity and value and some mechanism to track it along the lifecycle of the issue. I'm pretty sure we (as a community) don't want this overhead to suit the needs of a single contributor.
If you want to track your contributions in your self constructed metric system, please do your bookkeeping outside of Jira and refrain from producing extra noise for your own needs.
Thanks for your cooperation, Michael Am 03.05.17 um 08:46 schrieb Pierre Smits:
If multiple parties are involved, I feel confident they can work it out and reach a consensus. Like I said, this has been discussed before. Anyway, more on how to work with JIRA has been written down in our wiki. That you (and/or anyone else) feels that you are spammed by JIRA is unfortunate. But having it email to a separate mailing (as the project decided a while back) should alleviate that sentiment. You (like anyone else) can unsubscribe from that mailing list to avoid getting notifications from activities on issues. I don't particularly believe it to be a good thing for the project to have INFRA asked to turn it of by default (and maybe it isn't even possible to do it for 1 project). But if you feel that strong about it, I suggest you find out. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Wed, May 3, 2017 at 3:46 AM, Scott Gray <scott.g...@hotwaxsystems.com> wrote:Hi Pierre, If I understand correctly, you believe that post-closure assignment should represent the person who should get the "credit" for the ticket? What if multiple people contributed? What if there was a lot of back and forth between the reviewers and the patch contributor? What if the committer had to rewrite and fix the patch? To be honest I don't really care who the post-closure ticket assignee is. The only solid use I can see is for gathering statistics about either contributor or committer and either way I don't think it's a useful metric anyway. One ticket can be 5 minutes work and another can be 5 months so ticket numbers aren't a useful representation of anything even if we ignore that multiple people are involved in almost every ticket. About this comment you made:It should not be used by committers as a mechanism to claim/imply thattheywere the sole contributor who scratchted the itchI've never heard of anyone stating that the post-closure assignee means anything other than the last person who was assigned to a ticket before it was closed. I think you're the only one attempting to add meaning to it. But hey, who cares, if it means something to you then I don't have an objection to that. Regarding the email spam, jira is a real pain for that. I wish we could turn off all notifications except for creation and comments, I want to follow discussions and ignore arbitrary ticket changes. Or at least turn those off for the jira mailing list, ticket watchers could still get all notifications directly. Regards Scott On 3 May 2017 at 01:13, Pierre Smits <pierre.sm...@gmail.com> wrote:This has been discussed before. JIRA is a tool for contributors. Intended to provide insight on openissuesand to simply identify who was the lead contributor that brought a closed issue to a succesful resolution. It should not be used by committers as a mechanism to claim/imply thattheywere the sole contributor who scratchted the itch (in other words:improvedthe code base of the project), when another contributor has done all the legwork (register the issue, investigate it, provide the patch - order of importance, etc.) and the committer did little more than the commit(whichis part of his obligation to help others and which comes with the privilege). Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Tue, May 2, 2017 at 10:15 AM, Scott Gray <scott.g...@hotwaxsystems.com>wrote:I'm of two minds: 1. Who cares, it's no big deal. If a contributor wants to micro manage their contributions, so what? 2. It creates unnecessary noise in an already busy mailing list andalsoprevents us from knowing which committers are most responsive to contributions. I agree with Pierre that it's not difficult to know who committed a particular issue when that issue is in focus. This is one of those topics where we don't currently have a policy soweeither need to make one or decide we don't care enough to bother. Regards Scott On 2/05/2017 7:44 PM, "Michael Brohl" <michael.br...@ecomify.de>wrote:Pierre, you are still reassigning lots of old Jiras to yourself withoutansweringour questions why you are doing so. Please stop it and give us your reasons why you are doing so. Thanks, Michael Am 02.05.17 um 09:36 schrieb Pierre Smits:I apologise for any inconvenience caused. Using JIRA as tool to 'blame' a committer when something goes sourisnotthe best what comes to my mind. There are other services of the ASFthathelp in that respect, such as ViewVC and FishEye. Those toolsprovidewaybetter means to assess who committed what and when (even forstatisticalpurposes). Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Sun, Apr 30, 2017 at 10:18 AM, Michael Brohl <michael.br...@ecomify.dewrote: Hi Scott,thanks for trying to clarify and giving your opinion on this. See my remarks inline. Am 30.04.17 um 04:30 schrieb Scott Gray: I would prefer they were left assigned to the committer since theonustends to fall on them if there are any post closure issues. Exactly what I would prefer also. In most cases the commit andbackporting is the last action taken and should be recorded as such. My guess if that Pierre wants to track what tickets he contributedtobeyond being the reporter. Could you confirm Pierre? Beyond what I've mentioned is there any other reason you have anissuewith it Michael? I think it is against the natural workflow as mentioned above. Icannotremember that anyone else assigns tickets back to himself aftertheyarefinished. It falsifies the statistics to reassign issues, especially if theyareold. When it comes to contributions, the committer contribution would be hidden. It produces unnecessary traffic in Jira and the notificationmailinglists and adds nothing valuable. Just trying to figure out everyone's reasoning so we can worktowards asolution. Thanks Scott, that's what I was trying to achieve also in my lasttwoquestions to Pierre. RegardsScott Regards,Michael On 29/04/2017 11:45 PM, "Michael Brohl" <michael.br...@ecomify.de> wrote:Hi Pierre, you are again reassigning lots of old and already closed Jiras to yourself. Can you please stop this and give us an explanation why you aredoingso? Thanks, Michael Am 23.04.2017 um 15:56 schrieb Michael Brohl <michael.br...@ecomify.de: Hi Pierre, what's the reason to reassign old and already closed issues toyourselfagain? Regards, Michael Am 23.04.17 um 13:06 schrieb Pierre Smits (JIRA):[ https://issues.apache.org/jira/browse/OFBIZ-8232?page= com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]Pierre Smits reassigned OFBIZ-8232:----------------------------------- Assignee: Pierre Smits (was: Jacopo Cappellato) Improve Dutch labels for commonext component-------------------------------------------- Key: OFBIZ-8232 URL: https://issues.apache.org/jira /browse/OFBIZ-8232 Project: OFBiz Issue Type: Improvement Components: commonext Affects Versions: Trunk Reporter: Pierre Smits Assignee: Pierre Smits Priority: Minor Labels: labels, refactoring Fix For: 16.11.01 Attachments: OFBIZ-8232-CommonExtUiLabels.xml.patch --This message was sent by Atlassian JIRA (v6.3.15#6346)
smime.p7s
Description: S/MIME Cryptographic Signature
