-
Notifications
You must be signed in to change notification settings - Fork 212
Clarify process around updating defaults #111
Comments
Any updates to the 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. |
Thanks @hiimbex! :)
Yep! Sorry if that was unclear
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 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 |
Also, omg <3 your bots: https://github.com/behaviorbot
|
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!) |
🙌
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 :)
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!)
Thanks for your "how"-related suggestion on doc'ing diff defaults! |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
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! :)
The text was updated successfully, but these errors were encountered: