I) Open Dormant Issues on Inactive Repositories

jlangy commented 3 years ago

Feature: Open Dormant Issues on Inactive Repositories

    As a BCGov GitHub Administrator
    I want to know the difference between abandoned and infrequently updated repositories
    so that I can remind the repository owners to do follow-up actions such as
    archiving the repository and adding dormant or retired life cycle badges.

    Archiving unmanaged repositories are important to make them read-only for all users
    and indicate that they are no longer actively maintained.

    Repomountie should run idempotently. It should not create duplicate dormant issues and
    should recover from errant behaviour by closing duplicate dormant issues
    to avoid frustrating repository owners with unnecessary spam issues.

    If a dormant issue goes ignored for 90 days, repomountie should create a comment
    on the existing open dormant issue in order to notify the repository owners and
    should not create a duplicate issue to avoid future issue spam.

    - idempotently: in imperative programming, a subroutine with side effects is idempotent
    if the system state remains the same after one or several calls, in other words
    if the function from the system state space to itself associated to the subroutine is
    idempotent in the mathematical sense.
    https://en.wikipedia.org/wiki/Idempotence

    Background:
        Given inactivity threshold period of 180 days

    Scenario Outline: Notification for dormant repositories
        Given a repository last updated <Update_days> days ago
        And the repository <Archived>
        And the repository <Open_dormant_issue> a open dormant issue
        And the repository <Closed_dormant_issue> a closed dormant issue created <Closed_issue_days> days ago
        When when the repository information gets analyzed
        Then repomountie <Result> a dormant issue.

        Examples:
            | Update_days | Archived        | Open_dormant_issue | Closed_dormant_issue | Closed_issue_days | Result          |
            | 179         | Is Archived     | Does not have      | Does not have        | N/A               | Does not create |
            | 179         | Is not Archived | Has                | Does not have        | N/A               | Does not create |
            | 179         | Is not Archived | Has                | Has                  | 179               | Does not create |
            | 179         | Is not Archived | Does not have      | Does not have        | N/A               | Does not create |
            | 179         | Is not Archived | Does not have      | Has                  | 179               | Does not create |
            | 179         | Is not Archived | Does not have      | Has                  | 181               | Does not create |
            | 181         | Is Archived     | Does not have      | Does not have        | N/A               | Does not create |
            | 181         | Is not Archived | Has                | Does not have        | N/A               | Does not create |
            | 181         | Is not Archived | Has                | Has                  | 179               | Does not create |
            | 181         | Is not Archived | Does not have      | Does not have        | N/A               | Creates         |
            | 181         | Is not Archived | Does not have      | Has                  | 179               | Does not create |
            | 181         | Is not Archived | Does not have      | Has                  | 181               | Creates         |

    Scenario Outline:  Comment on dormant issues
        Given an issue last updated <Update_days> days ago
        And the repository <Archived>
        When when the repository information gets analyzed
        Then repomountie <Result> a comment on the dormant issue.

        Examples:
            | Update_days | Archived        | Result          |
            | 89          | Is Archived     | Does not create |
            | 89          | Is not Archived | Does not create |
            | 91          | Is Archived     | Does not create |
            | 91          | Is not Archived | Creates         |

Related links on repomountie

junminahn commented 3 years ago

I made a pr to the original repo. https://github.com/bcgov/repomountie/pull/136

junminahn commented 3 years ago

We will propose to update the current behaviour of the repomountie to consider all edge cases and proceed once the feature is signed off.

jleach commented 3 years ago

If a dormant issue goes ignored for 180 days, repomountie should create a comment
on the existing open dormant issue in order to notify the repository owners and
should not create a duplicate issue to avoid future issue spam.

Similar logic is already implemented and for consistency I'd like to rely on this logic. See handlers.ts line 157:

      requestUpdateForMyIssues(context, owner, repo),

EDIT: If we would like to change when it asks for an update on an open issue then we should be consistent (unless we have good reason not to be) and update all the bots issues accordingly. If we do want this issue to be a special snowflake then lets adapt existing logic to be more flexible ratter that write custom logic for this feature.

jleach commented 3 years ago

Scenario: Close all dormant issues for archived repositories Given a repository is archived And it has open dormant issues When when the repository information gets analyzed Then repomountie closes all dormant issues

Can this be done? Maybe using the API makes this possible but when you archive a repository you can not update Issues or Pull Requests via the Web. I think GitHub advising this housekeeping prior to archiving a repo.

junminahn commented 3 years ago

If a dormant issue goes ignored for 180 days, repomountie should create a comment
on the existing open dormant issue in order to notify the repository owners and
should not create a duplicate issue to avoid future issue spam.
Similar logic is already implemented and for consistency I'd like to rely on this logic. See handlers.ts line 157:
      requestUpdateForMyIssues(context, owner, repo),
EDIT: If we would like to change when it asks for an update on an open issue then we should be consistent (unless we have good reason not to be) and update all the bots issues accordingly. If we do want this issue to be a special snowflake then lets adapt existing logic to be more flexible ratter that write custom logic for this feature.

@jleach yes, I see repomountie checks stale issues for 90 days and creates a comment on it.

"staleIssueMaxDaysOld": 90

I believe that we can delegate the scenario Comment on dormant issues for inactive repositories to the existing requestUpdateForMyIssues? @wenzowski do you have any opinion of this?

jleach commented 3 years ago

Scenario: Close duplicate dormant issues Given a repository has two or more duplicate open dormant issues When when the repository information gets analyzed Then repomountie closes all dormant issues except the oldest dormant issue open

I think this might make a great independent feature to be applied to all issues. If not already there will probably be other features in the future that create duplicates - would be nice to have one features that deals with duplicate open issues.

junminahn commented 3 years ago

also, it seems not possible to close open issues on already archived repositories as they are read-only.. We might need to drop the scenario Close all dormant issues for archived repositories.

junminahn commented 3 years ago

Scenario: Close duplicate dormant issues Given a repository has two or more duplicate open dormant issues When when the repository information gets analyzed Then repomountie closes all dormant issues except the oldest dormant issue open

I think this might make a great independent feature to be applied to all issues. If not already there will probably be other features in the future that create duplicates - would be nice to have one feature that deals with duplicate open issues.

very good point! I am a little afraid that this might be out of scope this feature though. @wenzowski do you have any other insights into this?

jleach commented 3 years ago

@jlangy I think you have one other scenario to consider. What happens when a repos has a closed dormant issue but the repo has not been archived?

i.e:

A repo is dormant for 181 days, someone closes the "dormant issue" but does not address the problem leaving the repo un-archived?

You can: a) Re-open the closed issue immediately or give it a grace period; b) Do nothing, no more "dormant issues" are created.

ProTip: I'd fix the existing issue first and add this as another independent feature.

junminahn commented 3 years ago

@jlangy I think you have one other scenario to consider. What happens when a repos has a closed dormant issue but the repo has not been archived?

i.e:

A repo is dormant for 181 days, someone closes the "dormant issue" but does not address the problem leaving the repo un-archived?

You can: a) Re-open the closed issue immediately or give it a grace period; b) Do nothing, no more "dormant issues" are created.

ProTip: I'd fix the existing issue first and add this as another independent feature.

so, it will simply create another one rather than re-opening closed one as the content will be different.

eazeredo commented 3 years ago

@jlangy I think you have one other scenario to consider. What happens when a repos has a closed dormant issue but the repo has not been archived?

i.e:

A repo is dormant for 181 days, someone closes the "dormant issue" but does not address the problem leaving the repo un-archived?

You can: a) Re-open the closed issue immediately or give it a grace period; b) Do nothing, no more "dormant issues" are created.

ProTip: I'd fix the existing issue first and add this as another independent feature.

Hey Jason, The first scenario will create a 'new issue' given a not updated repo at least +180 days has not an open dormant issue created at least 180 days ago. Thinking in an example, given a repo with 361 days not updated and one closed dormant issue created 181 days ago, another issue will be created when repomountie executes the feature.

wenzowski commented 3 years ago

@junminahn I believe the original intent for when a repo has a closed dormant issue but the repo has not been archived would create a new issue in order to act like a heartbeat, yes? Should the story be updated to capture that intent? The number of repos that are maintained but change infrequently is quite low, and the risk of non-maintenance in production services was identified as significant, yes? I imagine the other option would be to reopen the existing closed issue. I also imagine that a future feature might read the lifecycle tags or a similar mechanic for something like a maintainer-declared neverdormant exemption? An example of a repo that might want this is future feature is https://github.com/bcgov/bc-sans

As far as splitting independent features go, I'm a firm believer that in order to empower our product owners to make efficient decisions on effective technical recommendations we should split things out wherever we identify isolatable functionality, as Jason has identified above.

junminahn commented 3 years ago

@wenzowski

the original intent for when a repo has a closed dormant issue but the repo has not been archived would create a new issue

Yes, the first scenario covers that up already. I don't think we need to update the case.

other option would be to reopen the existing closed issue

As the first scenario simply creates a new one, no need to re-open the closed one and also the content will be different.

feature might read the lifecycle tags or a similar mechanic for something like a maintainer-declared neverdormant exemption

This is a very good feature we can recommend in another feature request.

we should split things out wherever we identify isolatable functionality

I totally agree with this point. I believe we can separate the scenario Close duplicate dormant issues as an independent feature so that it will go through all issues to close duplicates. Should we drop this scenario from this feature and create another feature then?

junminahn commented 3 years ago

@jleach @wenzowski @eazeredo I dropped and updated the scenarios to describe better. Let me know if there is still unclear statement.

jleach commented 3 years ago

@junminahn Are we good to go with fixing the existing feature? Any more discussion needed?

junminahn commented 3 years ago

@jleach based on your feedback of scenario Close duplicate dormant issues, we created a separate feature Close Duplicate Repomountie Issues https://github.com/bcgov/github-optimization/issues/93 Once we decide to have card #93 as a separate feature, we will re-iterate this feature to update.

@wenzowski am I following the process correctly?

bcgov / github-optimization

I) Open Dormant Issues on Inactive Repositories #39

Related links on repomountie