@justo-mend I highly appreciate your response!
I actually meant proactively contacting your users, either by creating issues in the affected repositories, or by sending out e-mails (definitely a justified case!). Opening an issue in your own repo where probably less than 2% of your users are subscribed to notifications... good intention, improvable execution.
Now that we approach a decision, we can confirm more details.
Your post actually sounded (and still does) like the decision for that change was already made, just without a proper timeline.
We have confirmed there will be no additional permission changes required.
But it's worth knowing that no other products/apps/functions will run on your repos unless you actively sign up (and pay) for the other scanning engines to engage with your repos. I hope that eases some concern.
I do trust mend for a long time now, so my concern isn't directly aimed at you. I'm not really worried about you having bad intentions with this change, like preparing to monetize on successful products like many other projects did.
My concern is about giving a bad example to others by "mishandling" the oauth authenticity and trust. I mean, there's a reason why apps need to re-auth if new scopes are added. If I'm offering an application that requires access to mails on outlook.com, and I introduce a new feature now also requiring access to calendars on outlook.com, I need to explain and ask my users to approve the changed scopes. I would even go a step further and ask for a new approval if I intent to add a new use-case already covered by the approved scopes, while I'm technically not enforced to do so. Same goes for re-using a client identity (with scopes) for a different application. I consider this as fair and transparent, especially when a lot of companies forget about these values nowadays. It's okay if you see me as pedantic or overly correct - it's part of my moral and ethical values, and I'm proud of that.