Hello,
Like any large project, we have a lot of old tasks/tickets/issues opened and it's hard to know what is still relevant, considering that a lot has changed, or there hasn't been anyone to work on them, etc.
To keep things under control, some open source projects have adopted a time limit on how long these can stay open. I would like to propose we do the same.
A soft threshold would trigger a warning being added to the task saying it's going stale. After a hard threshold is reached, the task would be closed.
This doesn't mean someone can't re-open the task and we could also have a special tag preventing the stale mechanism to activate on it.
Any thoughts?
Thank you
Sounds to me like it'd just be more work because someone would have to go around reviewing the tasks it closes and probably reopening the majority. Also it doesn't make much sense to do this at a project-level, if it's done it should probably be across the whole of Wikimedia Phabricator. Just because there hasn't been anyone to work on the task doesn't mean it's now irrelevant.
On Wed, 12 Dec 2018 at 09:19, Giovanni Tirloni gtirloni@wikimedia.org wrote:
Hello,
Like any large project, we have a lot of old tasks/tickets/issues opened and it's hard to know what is still relevant, considering that a lot has changed, or there hasn't been anyone to work on them, etc.
To keep things under control, some open source projects have adopted a time limit on how long these can stay open. I would like to propose we do the same.
A soft threshold would trigger a warning being added to the task saying it's going stale. After a hard threshold is reached, the task would be closed.
This doesn't mean someone can't re-open the task and we could also have a special tag preventing the stale mechanism to activate on it.
Any thoughts?
Thank you
-- Giovanni Tirloni Operations Engineer Wikimedia Cloud Services
Cloud-admin mailing list Cloud-admin@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/cloud-admin
On 12/12/18 7:31 AM, Alex Monk wrote:
Sounds to me like it'd just be more work because someone would have to go around reviewing the tasks it closes and probably reopening the majority. Also it doesn't make much sense to do this at a project-level, if it's done it should probably be across the whole of Wikimedia Phabricator.
If we start small and prove it works, it's easier to expand to make it a general policy. Starting big from the beginning is going demand consensus which will be hard to get, understandably.
Just because there hasn't been anyone to work on the task doesn't mean it's now irrelevant.
It gathers were there is interest from both parties, the one who reported and the one who is available to fix it.
Closing tasks doesn't mean they will disappear. They will still exist and serve their purpose to document what may once been an issue. Also, we can mark them with a tag "frozen" so they're skipping from the automated process.
I understand it's a different perspective from what has been adopted so far but the tasks are currently unmanageable as is. You can't realistic get a list of open tasks and know what is still broken, what needs work, etc. It's more like Gmail's "All Mail" at this point.
When projects like Kubernetes, from where I draw my experience with this method of work, adopted this policy, it initially caused some stress but I rarely see any complaints (if any) after it was implemented. I don't mean to piggyback on the Kubernetes hype but they are a very large project with a huge number of contributors, so I believe their experience is relevant.
The alternative is to keep the status quo if there is consensus this is desired. I'm fine with that too.
On 12/12/18 5:12 AM, Giovanni Tirloni wrote:
On 12/12/18 7:31 AM, Alex Monk wrote:
Sounds to me like it'd just be more work because someone would have to go around reviewing the tasks it closes and probably reopening the majority. Also it doesn't make much sense to do this at a project-level, if it's done it should probably be across the whole of Wikimedia Phabricator.
If we start small and prove it works, it's easier to expand to make it a general policy. Starting big from the beginning is going demand consensus which will be hard to get, understandably.
Just because there hasn't been anyone to work on the task doesn't mean it's now irrelevant.
It gathers were there is interest from both parties, the one who reported and the one who is available to fix it.
Closing tasks doesn't mean they will disappear. They will still exist and serve their purpose to document what may once been an issue. Also, we can mark them with a tag "frozen" so they're skipping from the automated process.
I think to some degree it depends on the kind of task. If the task describes an actual bug, then it seems wrong to close it if the bug still exists, even if fixing the bug is low priority. There was a recent fracas about this regarding the foundation wiki -- the communication team closed a bunch of issues that they didn't have time to fix, and the reporters took great offense.
My first thought about this is that if an issue real but we just can't work on it, it should be left open but as lowest priority. If an issue isn't real (or there's disagreement about what should be done but the 'do nothing' side wins out) then closing wontfix seems OK. Actually closing a bug that isn't resolved, though, seems wrong to me since people will re-report the same issue rather than finding the existing discussion of an issue.
I understand it's a different perspective from what has been adopted so far but the tasks are currently unmanageable as is. You can't realistic get a list of open tasks and know what is still broken, what needs work, etc. It's more like Gmail's "All Mail" at this point.
When projects like Kubernetes, from where I draw my experience with this method of work, adopted this policy, it initially caused some stress but I rarely see any complaints (if any) after it was implemented. I don't mean to piggyback on the Kubernetes hype but they are a very large project with a huge number of contributors, so I believe their experience is relevant.
The alternative is to keep the status quo if there is consensus this is desired. I'm fine with that too.
On Wed, 12 Dec 2018 at 16:18, Andrew Bogott abogott@wikimedia.org wrote:
On 12/12/18 5:12 AM, Giovanni Tirloni wrote:
On 12/12/18 7:31 AM, Alex Monk wrote:
Sounds to me like it'd just be more work because someone would have to go around reviewing the tasks it closes and probably reopening the majority. Also it doesn't make much sense to do this at a project-level, if it's done it should probably be across the whole of Wikimedia Phabricator.
If we start small and prove it works, it's easier to expand to make it a general policy. Starting big from the beginning is going demand consensus which will be hard to get, understandably.
Just because there hasn't been anyone to work on the task doesn't mean it's now irrelevant.
It gathers were there is interest from both parties, the one who reported and the one who is available to fix it.
Closing tasks doesn't mean they will disappear. They will still exist and serve their purpose to document what may once been an issue. Also, we can mark them with a tag "frozen" so they're skipping from the automated process.
I think to some degree it depends on the kind of task. If the task describes an actual bug, then it seems wrong to close it if the bug still exists, even if fixing the bug is low priority. There was a recent fracas about this regarding the foundation wiki -- the communication team closed a bunch of issues that they didn't have time to fix, and the reporters took great offense.
My first thought about this is that if an issue real but we just can't work on it, it should be left open but as lowest priority. If an issue isn't real (or there's disagreement about what should be done but the 'do nothing' side wins out) then closing wontfix seems OK. Actually closing a bug that isn't resolved, though, seems wrong to me since people will re-report the same issue rather than finding the existing discussion of an issue.
I agree that there are certain types of tasks where this makes sense - mainly requests where something has been asked for, questions sent back but no response. I think it is already fairly standard practice to close these after a little bit.
On 12/12/18 2:18 PM, Andrew Bogott wrote:
I think to some degree it depends on the kind of task. If the task describes an actual bug, then it seems wrong to close it if the bug still exists, even if fixing the bug is low priority.
Agreed. I think I'm coming at this issue (is there any issue?) from the perspective that keeping the bug report open will only serve to give a false feeling to the reporter that someone will look at it.
It's like projects like Fedora Linux do: after 2 releases, they will automatically close all tickets for release-2 _unless_ the reporter steps in and says they are still having the problem and can reproduce on a current release.
We don't have releases to guide our process, that's why I proposed a time limit instead.
There was a recent fracas about this regarding the foundation wiki -- the communication team closed a bunch of issues that they didn't have time to fix, and the reporters took great offense.
Yes, I remember that. If that was a simple issue of how tickets were being closed, I would consider the whole thing very silly because I believe teams should be allowed to self-organize in the way they find most effective (we're using Kanban, others aren't). But the whole situation seemed to be a venting opportunity for a lot of other long standing issues, that relationship seemed to be deteriorated since a long time.
My point being, simply closing the tickets shouldn't be taken as an offense but I understand that's not a opinion shared by the majority.
My first thought about this is that if an issue real but we just can't work on it, it should be left open but as lowest priority. If an issue isn't real (or there's disagreement about what should be done but the 'do nothing' side wins out) then closing wontfix seems OK. Actually closing a bug that isn't resolved, though, seems wrong to me since people will re-report the same issue rather than finding the existing discussion of an issue.
My concern is that the platform is an evolving thing. What was a problem 2 years ago could not be a problem anymore today. I keep bumping into tasks that are 2-4 years old and then confirm the problem is gone.
If we had an automated process in place, and considering we are very few and the workload is high, I think it'd be fair to share some responsibilities with reporters and ask them to confirm issues are still a problem after X months or accept they will be closed.
A list of people with elevated privileges could always mark a certain task as "frozen" to avoid it being closed, if they think that it affords it. For instance, we have a long standing task to select a PaaS platform, there is no reason to have that automatically closed. We have various tasks about tools not working years ago, there's no reason to keep them open.
I think my main points here are: 1) I see a problem with the amount of open tasks we have (and I'm not sure others agree, please provide your feedback) and 2) I believe maintaining these tasks should be a shared responsibility of reporters and fixers.
On 12/12/18 2:39 PM, Giovanni Tirloni wrote:
I think my main points here are: 1) I see a problem with the amount of open tasks we have (and I'm not sure others agree, please provide your feedback)
I checked the tags below and it seems we might have 200-300 tasks in total? I couldn't get a definite number from Phabricator but I expected more.
If those represent all of our work and the number really is 200-300, maybe my proposal is an overreaction and we should save it for when we hit the 500-1000 mark, if ever.
Cloud-Services Cloud-VPS Toolforge Data-Services
Thanks for the constructive conversation, much appreciated.
On Wed, Dec 12, 2018 at 9:58 AM Giovanni Tirloni gtirloni@wikimedia.org wrote:
On 12/12/18 2:39 PM, Giovanni Tirloni wrote:
I think my main points here are: 1) I see a problem with the amount of open tasks we have (and I'm not sure others agree, please provide your feedback)
I checked the tags below and it seems we might have 200-300 tasks in total? I couldn't get a definite number from Phabricator but I expected more.
If those represent all of our work and the number really is 200-300, maybe my proposal is an overreaction and we should save it for when we hit the 500-1000 mark, if ever.
Cloud-Services Cloud-VPS Toolforge Data-Services
Thanks for the constructive conversation, much appreciated.
The discussion here was constructive, so thank you all for that on what can be a contentious issue in our larger technical community.
Giovanni, I would recommend that you have a discussion with Andre about ideas you may have for large scale workflow changes in Phabricator even if they are confided to "our" projects/tags. In his "bugmaster" role Andre has spent a lot of time documenting common practices in our community and comparing them to other communities he has worked with or studied. My current feeling is that it is appropriate to close tickets which are related to projects that have been abandoned and undeployed. For most others I would recommend the "lowest" prioritization approach that Andrew mentioned. I do agree that this makes viewing some tags in exclusion like the "all mail" problem you mentioned, but we do have our own tags that we can add/remove from issues to make tracking a bit less chaotic.
Bryan
On 12/12/18 4:06 PM, Bryan Davis wrote:
Giovanni, I would recommend that you have a discussion with Andre about ideas you may have for large scale workflow changes in Phabricator even if they are confided to "our" projects/tags. In his "bugmaster" role Andre has spent a lot of time documenting common practices in our community and comparing them to other communities he has worked with or studied. My current feeling is that it is appropriate to close tickets which are related to projects that have been abandoned and undeployed. For most others I would recommend the "lowest" prioritization approach that Andrew mentioned. I do agree that this makes viewing some tags in exclusion like the "all mail" problem you mentioned, but we do have our own tags that we can add/remove from issues to make tracking a bit less chaotic.
That makes sense! I'll consolidate my ideas and do a bit more research then consult with Andrew. Thank you!
cloud-admin@lists.wikimedia.org