I think in the past we also got pushback from INFRA on using bots via apps because of access to data etc (similar to CI services etc). Not sure if that changed in the last few months.
J Am Fr., 17. Apr. 2020 um 13:44 Uhr schrieb Niklas Merz <niklasm...@apache.org>: > > I think I have to agree there. > > I would vote -0 for stale locking. This is really a mixed bag. As a user this > annoyed me in some projects that issues are closed and locked but are > discussing exactly my problem. Marking as stale or wontfix should be a good > idea. But locking them could be a manual step? Locking should avoid spammy > responses and not turn users away from giving feedback when maintainers don't > triage for some time. > > +1 for closing old issues and asking for response automatically and the other > tags. I like that the times in the PRs are quite long. > > > April 17, 2020 1:04 PM, "julio cesar sanchez" <jcesarmob...@gmail.com> wrote: > > > I'm -1 for the stale bot, I've seen in other repos and it just ends closing > > valid issues and PRs because the maintainers didn't have time to look into > > them, but that's maintainers "fault" and I think it "punish" users. > > > > I'm +1 for the other ones. > > > > El vie., 17 abr. 2020 a las 12:43, Bryan Ellis (<er...@apache.org>) > > escribió: > > > >> I forgot to link PR: > >> > >> https://github.com/apache/cordova/pull/210 > >> > >> This PR contains the configurations for the apps described previously. > >> > >> On Fri, Apr 17, 2020 at 7:42 PM Bryan Ellis <er...@apache.org> wrote: > >> > >> I would like to better improve our GitHub issue tracker by adding some of > >> the Probot apps that can be installed to GitHub. > >> > >> There are many available apps and I wanted to start off with a selected > >> few that would help mitigate some of the tedious tasks. > >> > >> The apps I would like to bring up in this discussion and to vote on are: > >> > >> - Stale > >> - Request Info > >> - Lock Threads > >> - No Response > >> > >> The "*Stale*" app is used to automatically close issues and prs which > >> have no activity over a period of time. This app provides a lot of > >> configuration flexibility. We can warn users after x number of days that > >> the issue/pr has become stale and append a stale label. After x number of > >> days being stale, then the app will close the issue/pr. We can ensure > >> that > >> the issues and prs are not closed immediately and provide users ample > >> time > >> to reply back. > >> > >> The "*Request Info*" app is used to automatically alert users when they > >> have created a new issue or pr that does not have any description. The > >> app > >> will inform them that they will need to provide information for use to be > >> able to help them. One of the great things about this app is that it can > >> also check against our templates. If a user has submitted an issue or pr > >> with only the default template, it will also fail the check. > >> > >> The "*No Response*" app is used to automatically close issues that have > >> not received a response from the author. This app pairs nicely with the > >> "request-info" app which manages the warning and label pinning. This app, > >> on the other hand, does not support PRs as the "request-info" also > >> supports. This means we will need to manually manage PRs in the meantime > >> while we wait for the app to be updated. > >> > >> The "*Lock Threads*" app is used to lock the threads of closed issues or > >> prs after (x) number of days of inactivity. This is to help prevent > >> long-lived issues and prs after being resolved and closed. If a user > >> still > >> has issues to report after the thread of an issue or PR is locked, they > >> should create a new issue. The locking of the thread does not occur > >> immediately after an issue or PR is closed. Users can still have an > >> opportunity to communicate if they feel the issue was closed prematurely. > >> > >> Here is an example of PR to configure and use the bots. Obviously, I > >> would > >> also need to enable the bot on each repo. > >> > >> Please let me know what is your thoughts on this and even make a vote on > >> it. I would like to move forward and start using the power of the apps > >> that > >> can be installed. > >> > >> Here is the general process based on the configurations in the PR. > >> > >> *For proper Issues & PRs* > >> > >> - After 2 months of no activity, the issue/pr will become stale and > >> the thread will be warned. A "stale" label is appended. > >> - After 2 weeks of being stale, and continues to have no activity, the > >> issue/pr is closed. > >> - After 2 weeks of being closed, and continues to have no activity, > >> the issue/pr thread will become locked. > >> > >> In total, this process covers ~3 months. (88 days exactly). After being > >> flagged stale, users have still enough time to create an activity to > >> prevent the app from closing and locking the thread. > >> > >> Additionally, I have also declared labels of "security" and "pinned" to > >> be > >> ignored by the app so it will never go stale. > >> > >> *For issues & PRs that have no description or matches the template.* > >> > >> - Shortly after the submission of a bad issue or pr, the app will post > >> a warning that information must be provided. Also, "info-needed" > >> label is > >> applied > >> - After 4 days of no response, the bot will close the issue. (PR will > >> need to be manually managed for now) > >> - After 2 weeks of being closed, and continues to have no activity, > >> the issue/pr thread will become locked. > >> > >> In total, this process covers ~18 days. The author of the ticket will > >> have > >> enough time to correct the issue before the app closes and locks the > >> thread. > >> > >> If we have enough votes for this, what I will do is merge in the PR and > >> then do a mass deploy to all repos. I will also enable the bots to each > >> repo. > >> > >> Please provide a vote on this as well. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
