Clarify process around updating defaults

[patcon]

Sub-ticketed from #110

I can imagine there might need to be a rigorous process around updating defaults. Any thoughts on what those might be? A versioning system for config maybe?

Being able to change defaults without too much pain seems quite important. As I've said elsewhere, I feel that defaults are among the more political edges of technology -- it's where the impressionable psychology of each of us as end-users comes into play -- nudge theory is real! :)

[hiimbex]

Any updates to the stale.yml will take immediate effect the next times the bot takes a pass at a repo's issues.

Could you expand more upon what you mean by updating defaults? Do you mean the stale defaults stale itself uses? I imagine we would almost never update those since so many people are already dependent on them.

[patcon]

Thanks @hiimbex! :)

Do you mean the stale defaults stale itself uses?

Yep! Sorry if that was unclear

I imagine we would almost never update those since so many people are already dependent on them.

I've bored people with this elsewhere, but I apparently have a fuzzy plush axe to smooth into a bristly edge: I feel that we as tech people need to recognize that defaults are not simply helpful examples (in respectful disagreement to what you suggested elsewhere), they are political and they carry weight in determining use patterns (and therefore culture). Defaults are a foundation of the Nobel prize-winning work on nudge theory, and should be afforded respect in consideration of the non-rational side of human nature :)

And if we do accept defaults as important, then putting all faith in "never updating" seems a bit cavalier. It assumes the first whims of the first maintainer, before wider conversation, nailed the best defaults that suited the larger community commons. This feels unlikely to me, I suppose?

For example: if we eventually realize by scraping data that 99% of people running small projects don't actually change the default on exemptLabels, then we perhaps might come to a conclusion that defaults do matter here, and then we might have a responsibility to reconsider what sort of community-building we're nudging users toward. I don't feel particularly great about the idea that, as tool-builders, we wouldn't have laid groundwork for how this change could work.

Anyhow, thanks for humouring me if you read along this far 🎉

As for a specific suggestion: I feel that supporting multiple versions of defaults could be accomodated by adding a version key. Lack of key would be assumed to have the [current] version 1 defaults. Subsequent changes to defaults (or other keys), would involve a version bump.

[patcon]

Also, omg <3 your bots: https://github.com/behaviorbot

GitHub

behaviorbot

A series of GitHub Apps built with probot designed to help you build and maintain your open source community.

[hiimbex]

Thank you! They were fun to build.

Returning to the original topic of this issue, I definitely don't disagree that the defaults do carry some weight. after putting some more thought into it, I had an idea. Most people when creating the stale.yml file copy and paste all those defaults from what we have in the readme/ on the post installation page/on the probot website. So as a less destructive step for those currently dependent on the defaults, we could simply change those examples, so that new folks would look at those as a starting point.

But I would like to hear more concretely what types of changes to the defaults you'd like to see.

I'm not sure how I feel about versioning, just because I could easily see someone liking a version and needing only to change one or two fields. Also, stales code base is a bit complicated in my opinion, so i think that would be a rather large undertaking to implement, especially since I don't think the maintainers feel as strongly on this issue as you. (Having passion is never a bad thing!)

[patcon]

🙌

we could simply change those examples, so that new folks would look at those as a starting point.

Personally, I would excitedly see that as a much-appreciated step in a more gentle direction. Having said that, I can imagine others taking a stance that the defaults described in the readme should match the defaults in code. But I'm grateful for the inch, and feel it's a step in the right direction :)

But I would like to hear more concretely what types of changes to the defaults you'd like to see.

I'm totally happy to point to my own pet "why"s:

(I'll keep further discussion of each "why" in its respective issue -- I started to blur the lines here with my example, and that's my bad!)

1. #112 Consider exempting more default labels
2. #110 Don't close stale issues by default
3. #109 Change default label from "wontfix" to "stale"

Thanks for your "how"-related suggestion on doc'ing diff defaults!

[stale]

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