@Jan I also recall that there were push back, in the past, because of write access to the repo's source code. I felt like that was related to another bot that did the same thing but I don't recall.
If these were the same bots, I believe they updated their permission requirements. When I preping this email, I looked into the permissions and believe they are acceptable to INFRA, but they will always have the last say. *Stale* - Read access to files located at .github/stale.yml - Read access to metadata - Read and write access to issues and pull requests *Request Info* - Read access to files located at .github/config.yml - Read access to metadata - Read and write access to issues and pull requests *Lock Threads* - Read access to files located at .github/lock.yml - Read access to metadata - Read and write access to issues and pull requests *No Response* - Read access to files located at .github/no-response.yml - Read access to metadata - Read and write access to issues Write access for all 4 bots is only towards issues and/or PRs. Not source code. Hopefully this time there is no push back from INFRA. On Sat, Apr 18, 2020 at 2:24 AM Jan Piotrowski <piotrow...@gmail.com> wrote: > 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 > >
