Future of Gitter
-
I'm wondering if it's worth keeping gitter
There is a lot of promise with gitter:
- ChatOps
- We used it briefly for system notifications, our servers were pulling configuration updates and applying them, any errors were notified in gitter activity channel
- "Low overhead" communication, very easy to post a message compared to creating a post.
After a year or two:
- low usage, last messages posted are from a couple months ago
- low rate of usage, a message or less per month is typical
- we've tended to use forum PMs
- chat room activity channel was mostly ignored, I was the only one who occasionally watched for system notifications.
- slow response times, responding to messages has not been terribly fast
- we removed the gitter chat channel link from the project readme, it's an unadvertised channel
-
@LaFayette I vote to kill it. I think we just have too many different communication channels already. I'd rather use github issues and the forum chat which cover most of what we were using it for.
-
@redrum @LaFayette I agree with Red. Gitter was only nec when we did not have the forum stable yet. Also the Warclub/Lobby server has not been crashing every once in a while like the old days
-"Knock's on wood!" 
I would like to possibly keep the error notification part if that is easy to continue? -
@LaFayette I log in there occasionally - and I would not miss it. I would agree on reducing the variety of communication channels.
-
@prastle The error notification was an interesting use of gitter. We turned off the 'old style' of infrastructure automation where all servers applied updates every 5 minutes. Keep in mind it was designed so that the updates are idempotent, meaning the servers would ensure their configuration matched the requested, and if not it would alter the configuration so it did match. Typically then there were no actual updates happening, and if anything bad happened there was an error notification. Again, this system is now legacy and is turned off.
Going forward, deployments will be a 'push', meaning it will be initiated by command and servers will then 'receive' updates (and again they'll update their config as needed to match the requested). Prerelease I'm thinking will be run from the travis build on each update of the codebase, where we store the infrastructure/system configurations. If anything fails there, it would fail the overall build. We have a notification system to create a github issue ticket when the build fails and it auto-closes when the build is fixed.
Somewhat TBD how production deployments would be initiated. In the short term it might be hand driven, where a person initiates the deployment command. This is pretty rare event (almost unfortunately so), so the error notification is not super valuable to wire to gitter.
I think going forward we'll likely flag errors by creating github issues automatically. It would probably be great to see automatic scanning of production for errors and to create those tickets. Long story long, gitter perhaps does not have a role to play. Gitter would be really sweet if we had a chat bot where you could say:
- You: commands
- Gitter: Your commands are: [deploy ...]
- You: deploy
- Gitter: Where would you like to deploy? [prerelease, prod]
- You: prod
That is an example of chatops. I don't think we'll do that anytime soon and is probably not a good fit for how we build or our specific project (we want to cut humans out of the loop as much as possible).
-
It seems like there is consensus to axe gitter
-
No problem with getting rid of it either, I check the forum almost daily whereas I rarely ever look at gitter, I only have a look when I get a notification.
Might be worth adding a thread to bunker where we can post whenever we do some low-disturbance maintenance like restarting a server or something.
Obviously this isn't useful when updating the forum ^^ -
@LaFayette oki doki
