Reconcile knative-milestone-maintainers with project roles about community

[thisisnotapril]

Hey @mattmoor is this still an issue?

[mattmoor]

Yes, we don't have a "milestone maintainer" role in the project, but we do in peribolos.

[vaikas]

There are couple of questions:

• If we're (as I understand) moving away from Prow for tasks as much as we can
• Therefore, do we need to have the /milestone capability or a group that can address these labels. In that case, the concern is that there's no way with the current github acls to restrict only to milestones. Is this acceptable?

[evankanderson]

It sounds like Eventing is still using the /milestone command. It sounds like we should figure out who needs access to the command, or open up access to /milestone to all org members until we have a problem. (Seems reasonable to me.)

[vaikas]

@devguyio How would you like to address this?

[vaikas]

@devguyio just a ping on this to see if there's other ways to deal with this in Eventing?

[vaikas]

@devguyio would you mind taking a look and see how Eventing might want to work around this?

[devguyio]

apologies for missing this, I've change my GH notifications settings and seems I totally miss community related notifications. Right now only the WG leads of Eventing are changing issues milestones. We used to have @lberk but that's not the case any more.

I'd say we can remove the milestone-maintainers until it's needed again. I'm totally fine with that at least for Eventing WG.