Ecosystem Issue/PR Grooming Sprints and public roadmap

[bhack]

I receive many mails of repeated Nagging assignee without maintainers activity.
How do you are handling Nagging Assignees?
Can you add an automatic label to have a quick internal overview of these issues?
Continuous ping to inactive maintainers doesn't give a good feeling about the library.

[bhack]

@ewilderj Sorry to mention you but I don't know if you have already a ticket policy on this repo.

[ewilderj]

cc @martinwicke @dksb to comment on this issue. We are certainly aware of it. Perhaps Deepak has an update.

[dksb]

@bhack Can you please share a few issues you are getting nagging messages for? We are revisiting the feature and see if any kind of nagging makes sense or not.

[bhack]

@dksp This is the best sorted query approximation that I can do now (of course it doesn't analyze Nagging Assignees frequency):
https://github.com/tensorflow/tensorflow/issues?page=2&q=is%3Aopen+Nagging+-label%3A%22stat%3Acontributions+welcome%22+sort%3Acreated-asc

Please share an improved one if you compose it.

[bhack]

I.e. at the top of that query result:

Nagging Assignee @shivaniag: It has been 479 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

[bhack]

I think that when we have 479 days of "Nagging Assignee" something needs to happen 😄

[bhack]

Probably also @av8ramit could be interested in this.

[bhack]

Two subsequent Nagging Assignee 153 and 158 days:
tensorflow/tensorflow#16087

[bhack]

It has been 240 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

tensorflow/tensorflow#11521

[av8ramit]

We will turn off nagging on the issue soon and then start emailing assignees directly.

[bhack]

@av8ramit Good. But I think that we need to know in some way what is the public status of an issue. Having 270 days of internal emails reminders will not let us to solve the problem in general. If you see in my query I had filtered out "Contributions welcome" that there are the ones that could "acceptably" stay opened forever without activity.
But in general we need to maintain a triage/management of the others. It is not just a question of public spam/noise of the notification but mainly an abandon-ware feeling.

[ewilderj]

I think this is a problem that @dksb is looking at. In my humble opinion, a project this large cannot escape the monotonically growing number of issues, however hard it tries to close them all. However we can certainly manage our messaging around them, I suppose. Can we characterize all these outlying issues in meaningful buckets?

[bhack]

@ewilderj I agree with you and it is what i've tried to do with the query. The original scope was to create a special label with the bot so that we can have a periodical review (re-triage?) activity on this cluster cause I think sometime it just needs a re-evaluation, a closure, a stale notification (just a check if users are alive) or a reassignment.
I have this query but probably you can have a better one.
So I think that if we can label a cluster we can make a periodical revaluation for action on these specific issues that was catch by nagging assignee or similar logic. What do you think?

[dksb]

@bhack your suggestions are good. Nagging is not very useful and we will turn public nagging off. But this is not a tooling problem but more of a process and a resource problem. "Contributions welcome" category is tricky, most issues are FRs that cannot be closed right away. We are working on addressing the issue backlog, while keeping up with the new issues. Cheers, Deepak

…

On Thu, Nov 29, 2018 at 6:17 AM bhack ***@***.***> wrote: @ewilderj <https://github.com/ewilderj> I agree with you and it is what i've tried to do with the query. The original scope was to create a special label with the bot so that we can have a periodical review (re-triage?) activity on this cluster cause I think sometime it just needs a re-evaluation, a closure, a stale notification (just for check if users are alive) or a reassignment. I've this query but probably you can have a better one. So I think that if we can label a cluster we can make a periodical revaluation for action on these specific issues that was catch by nagging assignee or similar logic. What do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB0xd-xemXWE_uvooN_z4WMCuWP9bnRpks5uzy6ogaJpZM4X34jQ> .

[bhack]

Exactly, and I've excluded "Contributions welcome" from the query cause in that case we have a clear communication. There is currently any internal plan to schedule that activity and the message is clear: "We are interested in that feature ot to maintain it but we are waiting for a community PR". I think that there is also a cognitive bias for TF core team to receive repetitive notification. It is better to cluster and have a specific handling. IMHO It is better to have a problem of resource scheduling, so that could be just a question of set a frequency of the re-triage, than be fooled by some attention bias.
To scale I think that soon or later you need to
design some community roles for high level contributors.