Well, that hasn't panned out for us. We've been adding more non-engineers than engineers to staff. The non-engineers are hostile to GitHub, but friendly to Trello and Slack. I really can't blame them.
Although GitHub is a document manager, project manager, and discussion system, it makes less sense in those roles as you move away from code-centric workflows. I imagine One GitHub to Rule Them All not because I cherish that outcome, but because I find knitting best-of-breed components together doesn't produce the results I want.
Consider Slack: One of its key selling points is searchable community memory. If you put something into Slack, somebody else can most likely find it. That matters in proportion to the completeness of the community memory. If a query can find Slack messages, that's helpful. If the same query can also find Google documents and Trello cards and email messages, search becomes a superpower. The question becomes: How do you expose those things to Slack's search
Some, like Google Docs, can be ingested using Slack's native integrations. Others, like email to mailing lists (aka Google Groups), can be routed into Slack using glue providers like IFTTT and Zapier. But these integrations duplicate data and feel intrusive. It's true that dropping a document into a Slack channel or routing an email message there can alert the team to the existence of that item, as well as expose it to search. But you need to be selective about those alerts, and that makes for a lose/lose trade-off. Your choice is too much noise or incomplete search.
Why not enable Slack to search Google Groups directly Can you, for example, add Google Groups as a provider of results to Slack's search system
OpenSearch showed us a decade ago that it can be easily done. But there doesn't seem to be a search API for Google Groups, nor any way to wire such a feature into Slack's search box. As a workaround I made a Slack slash command, /gsearch, that gives you back the gnarly Google Groups search URL (that nobody can remember) with your query appended to it. That goofy solution is better than nothing, but it fails the One Search Box test. The missing ingredient here is API-level integration.
Now consider project management. For core software development artifacts and for issues surrounding their development, deployment, and support, GitHub is the system of record. But for non-engineers Trello is a more congenial way to organize, track, and discuss product and marketing plans, design sketches, and a range of other artifacts. We end up with a Venn diagram:
Only some GitHub issues need to become Trello cards that we can move around on our boards. And only some of our Trello boards need to track those cards.
I looked at the available GitHub/Trello integrations, and wound up taking a more surgical approach. I wrote a little Python script to query for a subset of our GitHub labels, fetch the associated GitHub issues, create Trello cards for them, and enable those cards to move around on the two Trello boards where we talk about them.
In this case there are simple APIs on both ends of the integration. But here the problem is harder than pulling in read-only search results. GitHub issues and Trello cards are read-write constructs with differing schemas. Complete two-way synchronization would be tricky and wouldn't make sense. Instead of wiring APIs together, I'd rather embed simple interactive renderings of GitHub issues in Trello cards that would act as live tiles we could shuffle without copying any data.
Maybe I'm expecting too much. It's certainly possible to combine these tools in useful ways, and I'm grateful for the affordances that enable me to do that. Still, I can't help but imagine easier and more effective ways the tools -- and we -- might work better together.