Powershell: Housekeeping - msftbot needs to be tamed a bit

[kilasuit]

Issues can get closed as answered when they really aren't

An example is #10509 where there is further conversation happening after the issue has been flagged as resolution-answered & a single day of no further responses.

Perhaps msftbot should look for issues that have not had a response for 3 days and then mark them as closed instead of the current 1 day behaviour

[vexx32]

I was thinking maybe a week or so? Because, really, if there is no discussion further, it doesn't matter if the wait time is 3 days or 1 week. But yeah, either way it definitely needs to be more than 1 day. It's too abrupt. 🙂

[iSazonov]

We set the label _manually_, GitHub does not send notifications for the event and users will not see the status change _until the issue is closed_. So the proposal make no sense.

[vexx32]

@iSazonov we're seeing issues closed when PS team or maintainers see the issue as answered. Users are not always looking for an answer and are instead making a module suggestion.

Additional time period is needed to allow users to communicate their intentions more clearly and resolve misunderstandings. So either the bot needs to be adjusted or maintainers / PS team need to be much more hesitant to mark issues as resolved or answered without first confirming with the user who opened the issue.

If we do not, people will be deterred from reporting issues. The perception currently is frequently that their requests are not being heard out completely, and being dismissed at the earliest opportunity.

[iSazonov]

@vexx32 It is __manual__ work to set resolution label (auto close works only from PRs). We could be deffer this for a week but (1) really we have no conflicts - we very rarely receive requests for reopen, (2) it can consume many time to review events for a week.

__I'd happy to get requests to close issues that deserve it __ that not only saves my time but makes the repo more clean.

There are many issues that are too general to be implemented and will never be resolved. I believe we should close such dead issues to force splitting them on issues which would be understandable, small and easy to implement.

[kilasuit]

@iSazonov we get that but respectfully you are just one of the collaborators and we aren't asking for the label removed

we very rarely receive requests for reopen,

this is in part because IMO it can feel hostile to open a ticket and have it rashly closed by a bot 1 day after the label assigned that it's resolved. This should be changed to a longer period to allow additional views

[kilasuit]

another hastily closed ticket because of msftbot #10540

[iSazonov]

@kilasuit #10540 is external issue. https://github.com/PowerShell/WindowsCompatibility is right place for the issue.

GitHub

PowerShell/WindowsCompatibility

Module that allows Windows PowerShell Modules to be used from PSCore6 - PowerShell/WindowsCompatibility

[doctordns]

I am not sure I totally agree with this (it's a wincompat issue not ours). At the end of the day, PowerShell 7 (at least P.3) can not support several modules (Best Practices, WSUS amongst them plus you can not install docker/WIn Containers). The goal of replacing WIndows PowerShell 5.x with PowerShell 7 is a worthy one and one I support - but these are two modules we need at least a workaround for.

And immediately closing an issue, eg #10540 without ensuring the issue is actually resolved (or resolvable), seems premature.

Finally, shouldn't it be for the OP to agree with closing an issue?

[iSazonov]

@doctordns Answer was that you can/should report to https://github.com/PowerShell/PowerShellModuleCoverage all MSFT modules you find incompatible with PowerShell Core. _There_ issue will remain open until fix.

GitHub

PowerShell/PowerShellModuleCoverage

Track issues related to using Windows PowerShell modules with PowerShell Core 6 - PowerShell/PowerShellModuleCoverage

[msftbot[bot]]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.