Expand stale management to Issues #124016
Comments
|
I removed devx label. |
|
We decided that "devx" is the best label for this at the triage review meeting.
PyTorch's stance right now is that we don't mark issues as stale, because if issues (like bugs) then it may still be relevant years later.
Issues marked as |
|
We have more then 5k+ open Issue/Feature requests so I think that generally doesn't make sense to totally trust old tickets as Orgs changes, allocated resources changes, project policies changes and the framework evolve over time. Just to make an example here is the list of the sorted oldest ticket: And here is the list of the sorted least recently updated: Without a periodical grooming activity I don't think we could trust the validity of these old tickets so I think a stale it could be a natural way to check if there is enough real attention around a ticket in the community. So I think it is hard to focus on 5k+ open tickets. It is hard to understand what it will be developed internally, on what we want to allocate the review resources or on what we want to support eventually a third party implementation etc. |
|
Other then this I think that we have also some problem in the PRs stale policy: |
@zou3519 where did this stance come from? Perhaps it's time to reconsider this idea |
|
/cc @penguinwu |
|
tl;dr: Closing issues simply because some arbitrary amount of time has passed is a mistake. A firm "issues never get stale" is the correct response. Github has excellent search functionality you can use if you want to filter out old issues. Why? Below are my reasons/opinions (Strong opinions, weakly held. You are more than welcome to disagree with me 😃): Issues are often relevant even years after they are opened: Anecdotally, is an example from last week when I became a first time contributor to PyTorch. This PR fixed:
All of these issues are more than half a year old -- one was created over a year ago. While old, every one described live bugs in PyTorch. Issues that could be investigated and fixed by someone. Builds the community: As a first time contributor it would have taken me more time to understand what was going on and find the issues if they had been closed. Perhaps even given up on finding the right context before shipping the fix. Keeping issues open increases discoverability and makes it more likely that someone find what they're looking for. Which is even more important for issues that are hard to debug. It makes it more likely that someone becomes an active, contributing member of the community. Respects the community: With close-on-stale, a lot of issues will get closed before someone has a chance to investigate. I think that's disrespectful to the people who took time out of their day to file a bug report, and goes against the spirit of open source. Issues with a great description; Copy-pastable reproduction steps; Automatically closed after 150 days; Without anyone even bothering to try to repro. That's what you too often get in projects that adopt a close-on-stale policy. When filing bugs it really makes one wonder: "What's the point? Nobody's ever going to look at this anyway." Number of open issues is an uninteresting metric: Not something to try to optimize. I'm all for closing items that are actually obsolete, but closing for the sake of closing sounds like something you do when you have really, really bad OKRs, resource constraints, and committed to a closure SLO (see Goodhart's Law). The backlog is never going to become manageable: Even with auto-close. This "cleanup" only creates a bigger mess as live bugs will have to be reopened/recreated/lifecycle managed ad infinitum. Continuous issue bankruptcy is not the solution. The search bar is. |
|
As it seems that the Pytorch team is not interested in organising a regular grooming activity like other popular projects on GitHub I think that the stale management is the only health solution to clean up the system. With every system/community with limited resources and so. I mean. also with the limited capacity of allocating eventually PR reviewers. Issues are not only technical artifacts but also social one. So also if an historical ticket is valid but there is no more social attention on it or we don't have the capacity to allocate reviewers or to re-triage it we can send a stale message and wait enough time (2 weeks?) for a community or triage team reaction on the ticket. If not it will be a mess to understand if open tickets are still valid from a technical or social point of view. |
|
Please check also Chaoss metrics (Linux Foundation) about responsiveness: |
|
P.s. as we are able to organize regular Docathon I suppose we are able to organize also Grooming hackathlon |
|
I see this was removed few days ago from PyTorch OSS Dev Infra. Are we going to reject this proposal? |
|
Each subteam in PyTorch is responsible for managing it's own issues. Removing it from that project means the Developer Infrastructure team won't be tackling solving this for all of PyTorch (at least not until there's an org-wide willingness to have such a feature) As a side question, @bhack would you mind sharing which company/team you're a part of? It's been awesome to see how active you are here the past few months, and I've love to a bit more context on who you are :) |
Are you at META right? If you think there is something interesting to exchange I could send you an email. Let me know... |
@bhack yup I'm at Meta. My email is first name, first letter of my last name, at meta.com |
|
@ZainRizvi I sent you an email. We can follow-up in that thread for things not strictly related to this ticket. |
|
At the end, it seems that @BoyuanFeng is manually reviewing some tickets or not? |
|
We are over 14K open tickets are we sure that the community is able to focus with this huge number of historical tickets? |
Uh oh!
There was an error while loading. Please reload this page.
🚀 The feature, motivation and pitch
We have really a lot historically issues with a de fafcto unknown status.
Can we expand stale management to Issues other then PRs?
Also do we really need to maintain our own custom action with the current Github stale action features?
In any case I think It could improve to understand also what issue it is really actionable by the community or by the "foundation" team and increase project inclusiveness (LinuxFoundation/CHAOSS):
https://chaoss.community/kb/metric-issue-label-inclusivity/
See also:
https://discuss.pytorch.org/t/pytorch-github-org-grooming/197163/7
/cc @ZainRizvi @kit1980 @huydhn @clee2000 @malfet
Alternatives
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: