Sync settings to file on each change

[patcon]

This seems like an extension to #1

The proposal would address the concern that enabling this plugin would confuse the process of changing repo settings for people who don't yet know about probot:settings. This is perhaps more important for large organizations who might want to introduce the plugin without "breaking" things for people who aren't yet aware.

Sample painful conversation

bob: I've just set up probot:settings!
alice: ok great, what happens when someone now makes a change from the UI?
bob: good question. I'll assume that we'll have to update the file manually.
alice: ok, how will we know when someone changed via UI? And what will be the consequence if we don't notice?
bob: good point. We'll have to stay vigilant. If we don't, I assume that the next time the file is changed, it will override the change made via UI. But I'm not sure, I'll have to do some testing, and then we can document the edge-cases.
alice: Hm, ok. Given the caveats, is this really worth the process gains?
bob: i'm not sure anymore...

Suggested Feature

To negate these concerns, it would be rad if changes made via the UI were automatically submitted either 1) as updates on default branch, or 2) as a PR to default branch.

(2) seems safer, although might be a little awkward to deal with multiple changes to repo settings, via multiple form saves -- would this involve a specially-named patch branch that is appended to?

Also, there is the outstanding question of whether this requires the addition of a new action to the RepositoryEvent type, so that the plugin can know when something has changed:
https://developer.github.com/v3/activity/events/types/#repositoryevent

[bkeepers]

@patcon yes! I think it would be awesome to have 2-way sync. I don't think it would be that difficult because we already have to fetch the current settings and diff them against the file to see what changes to make. The hardest part, as you suggest, is just watching for all the right events.

[stale]

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

[patcon]

@bkeepers can you explain the desirable properties of stalebot? To be honest, I find its humanless tactics of discarding human effort to be offensive to the energies of contributor communities. But I say that with a ❤️

[bkeepers]

@patcon This is the crux of it: https://twitter.com/bkeepers/status/954002062609731584

There's always too much work to do, and not enough time to do it. If nobody cares about an issue, then it should be closed so the finite resources can be focused on issues that are still affecting people.

Twitter

Brandon Keepers on Twitter

“@jacebrowning @maybekatz I’ve never seen a successful software project that wasn’t understaffed. There’s always more work to do. Focusing on work that is actively affecting humans is the best way I’ve found to prioritize.”

[patcon]

EDIT: To clarify, only after writing this did I realize that you are the creator of stalebot -- I am opting not go through and readjust language, but just know that I didn't mean to be slagging on your creation while also critiquing the philosophy. (I thought it was just doing the latter.)

I appreciate you @bkeepers, even if I dislike a thing you made! ❤️

---

I appreciate that you are stretched thin (and I'm truly sorry to hear that), but I'm honestly not vibing on that thread you shared. Would it be fair to read your problem statement as:

There's always too much work to do, and not enough time people to do it.

Each ticket is a lead on someone who cared enough to put their brain into our problem space. They're the people most likely to save us. Closing their issues with a bot solves a maintainer's immediate problem (kinda?), but it certainly doesn't make anyone feel nice or valued, and it fails to leverage a prime opportunity for a project to boost its human capital :)

What about triage? What about doubling down on community-building, and asking for help?

And in regards to that thread, I would like to caution that the folks who follow that user (and who seemed to fully support the response) are mostly programmers. Potential contributors are not all programmers, and so can't move things forward in the same ways. Sometimes things need to sit and wait for the right [programmer] hero. Not everyone can give you code, but they can process a challenge through the lens of their experiences -- a project manager or a community organizer might dedicate themselves to your problem space for a thoughtful hour, and really think hard on it.

Creating a thing that thoughtlessly closes their issues is dismissive to what they bring. It is offensive to those who want to create spaces that welcome non-coders into having ownership and agency related to the digital tools that underpin their daily lives -- the things beneath the abstractions, which in theory open source gives them access to, but for which they can be easily shut out if the processes we use assume a certain form of engagement. I want GitHub to be a place where I can direct future people of all skills and backgrounds. Stalebot promotes a view of contribution hostile to that vision.

Anyhow, sorry if this is more than you wanted. You have the right to not engage, and I respect that.

Also, I'm not anti-bot btw. For example, I think they're great doing things like this:
mntnr/welcome#3

I'm anti-bot when the main purpose of the bot seems to be to avoid human interaction carte blanche (ie. not because it's good or bad interaction, but just because it consumes attention) and to drive counters to zero. I am very pro-bot when the bot augments human strengths, such as our abilities to build and maintain relationships and see one another, including all our efforts :)

[patcon]

I respect your personal need to do whatever makes your circumstances bearable, but I respectfully disagree that there's deeper wisdom in the path you're trailblazing. ❤️ ❤️ ❤️ It feels to be a dead-end where the humans in the story lose against the tech.

[JasonEtco]

@patcon your respectfulness in sharing your opinion is much appreciated 🙇 The points you've brought up are certainly valid. I don't think that Stale is right for every project, and I don't think its without flaw, so its important (for everyone, including us) to understand those flaws so we can build with them in mind. For example:

Closing their issues with a bot solves a maintainer's immediate problem

Stale doesn't close issues as soon as they become stale - first it asks if it should. I can't count the number of times a useful issue has gotten lost, and Stale has reminded me about it, resulting in an additional pass on that thing. If it did just close issues without asking, I totally agree that that'd be bad for everyone.

Would you like to open an issue in probot/stale? We're putting together a doc about why Stale exists and why some projects find it valuable, and I'd love to discuss the pros and cons.

[patcon]

I would LOVE to. Thanks so much for using your valuable time to read. I really really appreciate the invitation into the appropriate place ;)

[stale]

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