Change Details

During the #wikimedia_hackathon_2025 we have triaged and reviewed an interesting amount of things and I noticed that it's not so easy, from a Workboard, to understand which Tasks have a patch or not. Because I like the 5-Whys exercise recommended by our documentation, here: 1. Why? Because it's useful to know if a Task already has a patch or not 2. Why? Because it's useful for me to understand which Tasks HAS NOT a patch 3. Why? Because it's useful for me to understand what Tasks are really needing my help to start over it and start from scratch the triage and produce from scratch something (that for me may be waaaaaays more difficult than just review other people things, since review can be done from mobile, while producing new source code can be done only in specific time windows of my week) 4. Why? Because I'm in a f******* hackathon with very small free time to hack things and my friends already have proposed some patches thanks to `arc diff` but from this damn Workboard I cannot distinguish Tasks that already have somebody who is somehow working on it (with a patch) and tasks who has literally nobody (e.g. absolutely no patches) 5. Why? Because `arc diff` creates patches, and connects them to tasks, but from the Workboard you do not see that the Task is assigned to somebody or that the task has a patch ## Root Problem Probably the root problem is that, if a task is unassigned, and if I've submitted a patch for it, it may have no sense to leave the task unassigned as default, even in presence of a very tangible patch contributor, that is tangibly working on that task right now. ## Proposed Solution Similarly to what happens when I land a patch (and that it closes the tasks): 1. When running `arc diff` 2. If the tasks are unassigned, assign myself ## Non-Proposed Solution Anything else is intentionally not introduced in this proposal. For example, if the task is already assigned, this proposal does not want to do risky things like replacing the old assignee as default, even after submitting a more recent patch. As default a machine should not try to guess the office social interactions, so, it should not try to change the task assignee, if already set. ## Potential Pitfalls * Cookie licking * Context: Aklapper told me about the phenomenon of "cookie licking", that is, like somebody who licks all biscuits, with the intention of eating them all, but without eating them all, and causing that nobody else want these biscuits. On bug trackers, it may happen that people claims some tasks, but without doing anything, so nobody else usually work on these tasks, including the person who claimed it lol. I perceive this thing and I've seen Aklapper doing many many times this kind of tasks cleanup, asking the assignee to kindly unassign himself/herself after months (or years!) of inactivity on that task (not always because of "cookie licking" - but you see that it happens sometime). * ✅ It seems to me that the proposed workflow of having `arc diff` that also claims that unassigned task could not causes more "cookie licking", since I see no evidence that cookie licking manifests with people who published a patch. Cookie licking usually is very visible with people who just visit a task without any patch and says “yeah yeah I will work on it this Monday” or similar interesting intentions, but then they disappear for months, reducing other people possibility to do some triage over that task and proposing a patch for months. So, I would say this risk is not relevant: proposing a patch means that the user not only want to work, but also worked, producing something very tangible, and this has sense to be immediately highlighted to other people, so, telling that "User Foo is working on this task", so, using the "Assigned" field, that is designed to describe exactly that. * Compatibility with the Current Auto-Claim + Auto-Resolve by Diffusion commits * Context: at the moment, when Diffusion notices some commits about tasks (e.g. with "`Closes T123`" in the commit message, it both auto-claims + auto-resolves the tasks. * ✅ This already existing workflow that Auto-Claims and Auto-Resolves is totally compatible with this proposal and can be leaved as-is. Additionally, this already-existing workflow would even be "more meaningful" thanks to this proposal, since after the proposal, in normal conditions, you can just create a patch and immediately claim the task (new feature), and then land the patch and then just resolve the task (old feature).

During the #wikimedia_hackathon_2025 we have triaged and reviewed an interesting amount of things and I noticed that it's not so easy, from a Workboard, to understand which Tasks have a patch or not. Because I like the 5-Whys exercise recommended by our documentation, here: 1. Why? Because it's useful to know if a Task already has a patch or not 2. Why? Because it's useful for me to understand which Tasks HAS NOT a patch 3. Why? Because it's useful for me to understand what Tasks are really needing my help to start over it and start from scratch the triage and produce from scratch something (that for me may be waaaaaays more difficult than just review other people things, since review can be done from mobile, while producing new source code can be done only in specific time windows of my week) 4. Why? Because I'm in a f******* hackathon with very small free time to hack things and my friends already have proposed some patches thanks to `arc diff` but from this damn Workboard I cannot distinguish Tasks that already have somebody who is somehow working on it (with a patch) and tasks who has literally nobody (e.g. absolutely no patches) 5. Why? Because `arc diff` creates patches, and connects them to tasks, but from the Workboard you do not see that the Task is assigned to somebody or that the task has a patch ## Root Problem Probably the root problem is that, if a task is unassigned, and if I've submitted a patch for it, it may have no sense to leave the task unassigned as default, even in presence of a very tangible patch contributor, that is tangibly working on that task right now. ## Proposed Solution Similarly to what happens when I land a patch (and that it closes the tasks): 1. When running `arc diff` 2. For each "Closes <Task>" in the commit message 2. If the task is unassigned, assign myself ## Non-Proposed Solution Anything else is intentionally not introduced in this proposal. For example, if the task is already assigned, this proposal does not want to do risky things like replacing the old assignee as default, even after submitting a more recent patch. As default a machine should not try to guess the office social interactions, so, it should not try to change the task assignee, if already set. ## Potential Pitfalls * Cookie licking * Context: Aklapper told me about the phenomenon of "cookie licking", that is, like somebody who licks all biscuits, with the intention of eating them all, but without eating them all, and causing that nobody else want these biscuits. On bug trackers, it may happen that people claims some tasks, but without doing anything, so nobody else usually work on these tasks, including the person who claimed it lol. I perceive this thing and I've seen Aklapper doing many many times this kind of tasks cleanup, asking the assignee to kindly unassign himself/herself after months (or years!) of inactivity on that task (not always because of "cookie licking" - but you see that it happens sometime). * ✅ It seems to me that the proposed workflow of having `arc diff` that also claims that unassigned task could not causes more "cookie licking", since I see no evidence that cookie licking manifests with people who published a patch. Cookie licking usually is very visible with people who just visit a task without any patch and says “yeah yeah I will work on it this Monday” or similar interesting intentions, but then they disappear for months, reducing other people possibility to do some triage over that task and proposing a patch for months. So, I would say this risk is not relevant: proposing a patch means that the user not only want to work, but also worked, producing something very tangible, and this has sense to be immediately highlighted to other people, so, telling that "User Foo is working on this task", so, using the "Assigned" field, that is designed to describe exactly that. * Compatibility with the Current Auto-Claim + Auto-Resolve by Diffusion commits * Context: at the moment, when Diffusion notices some commits about tasks (e.g. with "`Closes T123`" in the commit message, it both auto-claims + auto-resolves the tasks. * ✅ This already existing workflow that Auto-Claims and Auto-Resolves is totally compatible with this proposal and can be leaved as-is. Additionally, this already-existing workflow would even be "more meaningful" thanks to this proposal, since after the proposal, in normal conditions, you can just create a patch and immediately claim the task (new feature), and then land the patch and then just resolve the task (old feature).

During the #wikimedia_hackathon_2025 we have triaged and reviewed an interesting amount of things and I noticed that it's not so easy, from a Workboard, to understand which Tasks have a patch or not. Because I like the 5-Whys exercise recommended by our documentation, here: 1. Why? Because it's useful to know if a Task already has a patch or not 2. Why? Because it's useful for me to understand which Tasks HAS NOT a patch 3. Why? Because it's useful for me to understand what Tasks are really needing my help to start over it and start from scratch the triage and produce from scratch something (that for me may be waaaaaays more difficult than just review other people things, since review can be done from mobile, while producing new source code can be done only in specific time windows of my week) 4. Why? Because I'm in a f******* hackathon with very small free time to hack things and my friends already have proposed some patches thanks to `arc diff` but from this damn Workboard I cannot distinguish Tasks that already have somebody who is somehow working on it (with a patch) and tasks who has literally nobody (e.g. absolutely no patches) 5. Why? Because `arc diff` creates patches, and connects them to tasks, but from the Workboard you do not see that the Task is assigned to somebody or that the task has a patch ## Root Problem Probably the root problem is that, if a task is unassigned, and if I've submitted a patch for it, it may have no sense to leave the task unassigned as default, even in presence of a very tangible patch contributor, that is tangibly working on that task right now. ## Proposed Solution Similarly to what happens when I land a patch (and that it closes the tasks): 1. When running `arc diff` 2. If the tasks areFor each "Closes <Task>" in the commit message 2. If the task is unassigned, assign myself ## Non-Proposed Solution Anything else is intentionally not introduced in this proposal. For example, if the task is already assigned, this proposal does not want to do risky things like replacing the old assignee as default, even after submitting a more recent patch. As default a machine should not try to guess the office social interactions, so, it should not try to change the task assignee, if already set. ## Potential Pitfalls * Cookie licking * Context: Aklapper told me about the phenomenon of "cookie licking", that is, like somebody who licks all biscuits, with the intention of eating them all, but without eating them all, and causing that nobody else want these biscuits. On bug trackers, it may happen that people claims some tasks, but without doing anything, so nobody else usually work on these tasks, including the person who claimed it lol. I perceive this thing and I've seen Aklapper doing many many times this kind of tasks cleanup, asking the assignee to kindly unassign himself/herself after months (or years!) of inactivity on that task (not always because of "cookie licking" - but you see that it happens sometime). * ✅ It seems to me that the proposed workflow of having `arc diff` that also claims that unassigned task could not causes more "cookie licking", since I see no evidence that cookie licking manifests with people who published a patch. Cookie licking usually is very visible with people who just visit a task without any patch and says “yeah yeah I will work on it this Monday” or similar interesting intentions, but then they disappear for months, reducing other people possibility to do some triage over that task and proposing a patch for months. So, I would say this risk is not relevant: proposing a patch means that the user not only want to work, but also worked, producing something very tangible, and this has sense to be immediately highlighted to other people, so, telling that "User Foo is working on this task", so, using the "Assigned" field, that is designed to describe exactly that. * Compatibility with the Current Auto-Claim + Auto-Resolve by Diffusion commits * Context: at the moment, when Diffusion notices some commits about tasks (e.g. with "`Closes T123`" in the commit message, it both auto-claims + auto-resolves the tasks. * ✅ This already existing workflow that Auto-Claims and Auto-Resolves is totally compatible with this proposal and can be leaved as-is. Additionally, this already-existing workflow would even be "more meaningful" thanks to this proposal, since after the proposal, in normal conditions, you can just create a patch and immediately claim the task (new feature), and then land the patch and then just resolve the task (old feature).