Originally published at: How Does Team Discourse Use Discourse?
As we claim on our website, we use Discourse as our primary team coordination tool to build… Discourse! That means escaping email silos and minimising the number of disparate communication channels required to manage a fully distributed team. We are able to keep distractions like calls and meetings to a minimum and focus on actual…
53 个赞
holy cow. this is awesome. the idea had crossed my mind to use discourse as a full-bodied business communication and project system… but hearing it from you guys really does make it seem doable.
12 个赞
great insight thanks @HAWK - just shows how flexible it certainly can be if you want it to be!
3 个赞
So, Discourse is essentially the One Ring. Sauron would be proud. 
I love how you guys have figured out a way to get rid of all the distractions by building most of the features you need into one app.
4 个赞
I was thinking about this just last week! I remembered @HAWK saying she was working on it. Thrilled to see it come to life. 
Well, done.
8 个赞
This is awesome. Thank you very much!
I have a follow up question regarding task management.
Are you tracking commits with tasks for those that have code changes through discourse? Something similar to the way Jira w/ BitBucket or Github works?
I found a couple of plugins and topics that are related:
- Seems nice if you are/were using Github issues and want to mirror them in Discourse and use Discourse to further the conversation, but not if you don’t want to use Github issues.
https://meta.discourse.org/t/the-github-linkback-plugin/66081
- Looks for mentions in Discourse and then adds links to GH messages.
I realize that this can be done easily by manually pasting a Github/BitBucket commit into Discourse, but I’m curious if there’s something automatic.
Thank you again for the great post!
4 个赞
Hey Eric,
We use Github Linkback but we don’t have anything automated.
2 个赞
Very cool! 
Currently in the process of weaning people of from Hipchat in my org. and this is some very valuable input.
One question: why are you running two different instances? Wouldn’t it be possible to merge your internal one with meta and use subforums for everything?
Is it a matter of convenience? Was it set up before the tooling was ready? Don’t you trust the authentication/security model completely?
6 个赞
A couple of reasons.
Our internal instance sits on a different server so if Meta goes down we don’t lose all our runbooks etc.
It also allows us to have very different email and notification settings which means we’re less likely to miss important things in the noise.
15 个赞
Fair and logical reasons 
That brings up painful memories 
(we once stored our emergency customer contact list on the wiki, in the datacenter, where all the customer were hosted…)
3 个赞
Yeah we do too… but we have a replica in digital ocean and an extensive encrypted backup story
11 个赞
the idea had crossed my mind to use discourse as a full-bodied business communication and project system… but hearing it from you guys really does make it seem doable.
7 个赞
我们有一个 Discourse 实例，我们将其用作团队的内部中心。我们希望将某些方面公开给公众，而另一些方面则公开给客户。
我阅读了文章Team Discourse 如何使用 Discourse，我想知道你们为什么使用两个独立的实例：公开和内部？
我们计划使用一个唯一的实例，并通过用户组限制可见性。我们最初从唯一实例方法中看到的优势是集中化以及我们可以构建的链接图……但在阅读了这篇文章之后，如果有人能分享两个实例的优缺点以及 Team Discourse 的情况，那将非常有价值？
非常感谢！
7 个赞
不止你一个人问了这个问题
7 个赞
另一个原因是“自食狗粮”（dogfooding）多实例用例，因为我们有客户与我们一起托管数十个实例。
我们有 Discourse 实例之间的特殊单框嵌入（oneboxing），可以通过 Web 推送、电子邮件、Discourse Hub 获取集中式通知，通过 PWA 在移动设备上并排打开实例等。
9 个赞
在工作场所使用单个实例的最大挑战是：你很容易不小心将本应私密的内容公开分享。只需选择错误的类别或为新类别设置不正确的权限即可。
总结一下现在的进展：
- 很棒！这使我们能够在没有上述风险的情况下，支持和获取所有在 Discourse 上使用 Discourse 的用户的真实反馈。
- 我们的内部实例是 Discourse for Teams 的灵感来源。公司有很多潜力可以使用 Discourse 这样的工具来建立内部社区。
- 两个社区都非常活跃，因此随着我们的团队和 Meta 的发展，我们一直在寻找确保与两者保持联系的方法。
7 个赞
一篇引人入胜的文章，感谢分享（不知道之前怎么错过了）。
5 个赞
8 个帖子已拆分为新主题：设置支持收件箱