Open mviswanathsai opened 6 months ago
Description: This PR aims to add functionality that lets the user keep an issue in an intermediate state between stale and closed: rotten.
IMO the naming here is kind of counterintuitive; I'd expect stale to come first before rotten...
Yes, it is stale -> rotten -> closed.
Yes, it is stale -> rotten -> closed.
ah, got it, sorry, I just misunderstood at first... never mind...
Description: This PR aims to add functionality that lets the user keep an issue in an intermediate state between stale and closed: rotten. This enables the user to do Kubernetes-like (a very mild like) issue life-cycle management. This is done in Kubernetes using the traige-robot.
As per the changes in this PR, after an issue is created:
days-before-stale
.Stale
state.Stale
till a time period specified bydays-before-rotten
.Rotten
state.Rotten
till a time period specified bydays-before-close
.Stale
andRotten
.days-before-rotten: -1
i.e., does not rotten any issues and so does not disturb the flow of users who have already setup the action. However, provides the user with the option to use the new state if need be. So the default flow isStale
--> closed.Note: "This bot" refers to the triage-robot.
Related issue:
Check list: