Don't mark milestoned issues as stale

[alcaeus]

Issues that are added to a milestone or a project should not be marked as stale, despite the feedback label.

[ostrolucky]

Why not? These stories can't be finished without feedback.

[alcaeus]

Because there's no point in marking them as stale: if they need feedback and are in a milestone, they need more care than just a "stale" label or should be removed from the milestone. If they are in a project, this means they've been triaged for a specific version and also require more attention than just a stale label. This works very well in the ODM repo - I'm just applying our learnings from there here.

[ostrolucky]

ODM repo knowledge isn't applicable here, as there are no feedback required labels. I believe issues marked as such shouldn't be assigned to milestone in the first place, as it's unclear what needs to be done there. If they are assigned to milestone, they should be closed anyway and milestone can be removed after the fact. Otherwise they will be kept moved to next milestones, or closed in unexpected time, instead of having consistent 14/7 days that I want to achieve. I want to avoid having opinonated time window for providing feedback. Users need to learn we can't hold their issue open if they don't give us necessary information, disregarding if they have been assigned to milestone. So I see a point there.

Now, bot not having integrated feature to remove milestones automatically when bot closes issue is unfortunate, but I consider that as an edge case because:

1. These issues shouldn't have a milestone. We can check before adding such labels and remove the milestone.
2. We see notification when bot closes issue and can remove milestones when that happens manually.
3. We can also request this functionality in bot, or add new bot that allows to control milestones via GH comments - we can then in theory change stale bot message template to include milestone removal message.

[ostrolucky]

I was assured these issues will not be forgotten, serve as backlog and @alcaeus will make sure necessary feedback is collected by other means when time comes to solve it.