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
