You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Bryan Ellis <er...@apache.org> on 2020/04/17 10:42:00 UTC

[PROPOSAL] Enable Probot Apps to Improve Issue Tracker

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.

Re: [PROPOSAL] Enable Probot Apps to Improve Issue Tracker

Posted by Bryan Ellis <er...@apache.org>.
@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 <pi...@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 <
> niklasmerz@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" <jc...@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-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: [PROPOSAL] Enable Probot Apps to Improve Issue Tracker

Posted by Jan Piotrowski <pi...@gmail.com>.
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 <ni...@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" <jc...@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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Re: [PROPOSAL] Enable Probot Apps to Improve Issue Tracker

Posted by Niklas Merz <ni...@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" <jc...@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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Re: [PROPOSAL] Enable Probot Apps to Improve Issue Tracker

Posted by julio cesar sanchez <jc...@gmail.com>.
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.
> >
> >
> >
>

Re: [PROPOSAL] Enable Probot Apps to Improve Issue Tracker

Posted by Bryan Ellis <er...@apache.org>.
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.
>
>
>