Different stale settings for specific labels

[elliotblackburn]

Over at https://github.com/campus-experts/training, we're looking to use stale to handle neglected issues and PR's, however we would really like to put different durations across different labels.

Example use case

We have one training module which takes a long time to work through. It's quite typical that a user submits a first draft and we then review it. Once it's reviewed it can sometimes take a while for a user to push their changes as they often take a while to complete, we're talking on a scale of 2-3 weeks. However other modules can be much quicker and fixes can often be carried out in a matter of minutes and we want the expected turn around to be much quicker.

It would be fantastic if we could enter an array of labels with some override values, falling back to the top level stale settings. IE:

label x - is stale after 1 day and closed after 1 more
label y - is stale after 14 days and closed after 3 more days

[stale]

Is this still relevant? If so, please comment with any updates or addition details.

[elliotblackburn]

I believe this is still relevant to the probot stale project, at least no discussion has taken place to indicate otherwise 😄

[stale]

Is this still relevant? If so, please comment with any updates or addition details.

[elliotblackburn]

Yes this is still relevant and has been referenced in other issues

[bkeepers]

Seems like a reasonable feature. The easiest way to implement it would probably be to copy how different settings can be specified for issues and pulls. Maybe there could be a labels top level key, where settings can be specified for each label. Something like:

labels:
  x:
    daysUntilStale: 1
    daysUntilClose: 1
  y:
    daysUntilStale: 14
    daysUntilClose: 3

As an aside, I had thought about some drastic changes to stale configuration at one point that I think would also fit this use case…

The TL;DR, is that it should allow specifying an unlimited number of configurations. It might look something like this:

mark x stale issues:
  if:
    days: 1
    label: x
    is: issue
  then:
    label: stale
    comment: Whatever you want to say when marking the issue

close x stale issues:
  if:
    days: 1
    labels:
    - x
    - stale
    is: issue
  then:
    close: true
    
mark y stale issues:
  if:
    days: 14
    label: y
    is: issue
  then:
    label: stale
    comment: Is this still relevant? If so, please comment with any updates or addition details.

close y stale issues:
  if:
    days: 3
    labels:
    - y
    - stale
    only: issues
  then:
    close: true

So if you wanted different configuration for each label, you'd just use the if…label combination.

This is a drastic change, so I wouldn't wait for it to happen before exploring a solution, but wanted to throw it out there.

[elliotblackburn]

The logic based configuration looks like a really good idea for future extensibility and could open the doors to a highly custom configuration. One could probably use the logic system to power all existing configurations during it's implementation but as you said that's a very drastic change to the system.

The first proposal also seems like a good and simple approach to take, should be easy to lookup configuration for different issues. I guess a question it prompts though is what happens it two labels cause a rule conflict? I'm assuming it would be sensible to take the longest (thus most lenient) rule and apply it.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?