Seems like "yet another tool to try to offset the problem of requirements, code, and architectural decisions not being adequately documented for future staff to understand." Sometimes I wonder if software teams should add technical writers embed with developers, architects, QA, and BA assets to actually document All The Things and keep documentation up to date. Yes, that will mean re-writing documentations as people change their minds in response to business needs but it would provide an historical record that answers "How the hell did our systems end up looking like this?" which seems to plague every organization that hires programmers to write custom code. Sometimes it's hard to give the developers who wrote the code the benefit of the doubt that they made the wisest decision based on all known variables at the time. I'm certainly guilty of questioning the intelligence, breeding, motivations, etc of the programmer of an app I had to modify once... only to realize that <i>I</i> had written the code in question four years previously. Eventually I remembered why the feature had to be coded that way and wrote a 1200 word comment section explaining why the feature was written the way it was and how one should orient their state of mind to understand and edit the logic. And I further apologized for the clusterfuck of code that the feature was and left my personal email address in case a future programmer wanted to berate me for it. And three years later I did get an email from someone saying they had been laughing for ten minutes because they had gone from "WTF?" to gradual understanding as they read through my verbose description of why... ending with laughter that I was willing to take whatever vitriol they had left over via email so they could vent and get back to work. Whether that dev updated the comments to reflect their changes is something to which I have no answer.
There's nothing like writing up an Evernote or Wiki article on some feature, process, or how/why something works... and then nobody on the team ever reading.<p>I love writing documentation from time to time. But this helps by getting you to write documentation for only things people are asking about.
Over the years I’ve concluded, reluctantly, that the <i>ONLY</i> documentation solutions that matter are the code, revision control logs and issue trackers.<p>Create massive comment blocks to explain things if you have to but put it all there in the code, next to the things that matter. Then it has half a chance of still being accurate. And, you know exactly <i>where</i> the documentation is. If the code becomes obsolete and is removed, you naturally strip out documentation that is no longer relevant at the same time.<p>Revision control log messages are <i>important</i>. I <i>so</i> hate lazy messages; if you change 5 files in random ways and your message is “fixed bug”, I think you should be fired. If it’s in the issue tracker, your log had better mention the number. Add a paragraph daring to <i>explain</i> what the hell you did so I can read a sensible log history and figure out what happened when.<p>Issue trackers are useful for capturing every relevant detail, especially new information that is found while the bug is being investigated. The bug might come up again, and details can help to sort it out.
I'm excited at the potential this has to organize your own internal information that normally lies stagnant on a wiki (or heaven forbid, email) with no context of whether it's still valid or useful to anyone. It seems like it would be particularly useful for organizations with a distributed work force.<p>On the other hand, so much of StackOverflow's value comes from the economies of scale at hand, and I'm uncertain how well the model scales down to small sized teams or even medium sized companies.
So the biggest reason why I can see this succeeding is because of onboarding. In fact, I'd say that's the killer feature. It takes one person going through a development environment setup process to be really useful. They'll ask a lot of questions, get the answers...and then the setup process is suddenly really well documented without anyone having to go through the trouble of documenting it without knowing what to document.<p>Since new employees are expected to ask questions on how to get things working, using SO for Teams is natural. Then, explanations that would normally be sent in pieces over IM can be recorded.<p>The information still ages, but aged information on the right track is infinitely better than nothing at all.
Atlassian's "Questions for Confluence" is only half the price. <a href="https://www.atlassian.com/software/confluence/questions" rel="nofollow">https://www.atlassian.com/software/confluence/questions</a>
My question is, is this better than your self-hosted wiki? At least that's cheaper and isn't a vendor lock-in. Sure wiki doesn't have the best possible UI and the UX might be too so-and-so. If I were in a position to buy this kind of service I'd still want something more out of it.<p>Maybe if it offered a way to export Slack threads into SO as questions so they wouldn't get lost. Sure you could generate those questions manually from the thread and maybe prune them a little but I've found mostly people are too lazy for extra-work like that. Anyway that's my first impression, take it as you want.
Stack Overflow largely relies on Google Search, but for private teams it won't be available. And internal search is just unreliable.<p>Also I fail to see how answers on SO for Teams are supposed to be less "stale" than your old wiki articles.<p>For me, at least our corporate wiki is more organized, without duplicates, whereas Stack Overflow's modus operandi is largely relies on creating thousands of duplicated questions.
An open source alternative I've used in the past is Askbot: <a href="https://askbot.com/" rel="nofollow">https://askbot.com/</a><p>It's built on Django, and covers all of the standard Q&A features that I've needed to use.
Joel wrote a blog post about it, detailing how it currently works:<p><a href="https://www.joelonsoftware.com/2018/05/03/announcing-stack-overflow-for-teams/" rel="nofollow">https://www.joelonsoftware.com/2018/05/03/announcing-stack-o...</a><p>It was already linked on HN:<p><a href="https://news.ycombinator.com/item?id=16985574" rel="nofollow">https://news.ycombinator.com/item?id=16985574</a>
I'm sure I'm ignorant of other reasonable options, but this one is quite appealing as a small co, even if only used by one person. Just yesterday I was thinking about better ways to store easy-to-find answers to those dang tech issues that pop up once every six months. "How do I install pip manually on OS X with xyz constraints?"
Slightly offtopic, I recently looked at all top free internet websites/services that I use and wondered which of them I would miss if advertising dollars dry up. For me, it turned out to be stackoverflow and Google. I truly hope stackoverflow is a profitable venture at this point. I hope they have been trying various avenues to make money but no o no one has any info on profitability. Job ads pay well, but there is fierce competition there.
We've been running this in beta for a couple months now, happy to answer questions about it. The SO team has been super helpful during the process.
I have thought about building this so many times. I think there is a need for it, particularly for non-technical teams where processes don't evolve that fast, but adoption will be hard to ignite.
This is an interesting play but doesn't seem like a good fit.<p>The examples on the front page: "how do I connect to our database", "what kind of email templates do we have". Are these questions that you're going to get multiple answers for and I'm going to upvote the best and/or select one as the "selected" answer. I would think this would be a sign of dysfunction in most cases. And how does the gamification play into it? (maybe it's a secret bus-factor detector.)<p>It seems like a regular wiki/knowledge base would be a better fit for this kind of knowledge. How would the SO structure help.<p>A related note, I wonder if you can disable the "Soup Nazis"[1] feature or it's too deeply embedded in the psyche of the product.<p>[1]<a href="https://www.embeddedrelated.com/showarticle/741.php" rel="nofollow">https://www.embeddedrelated.com/showarticle/741.php</a>
Has anyone tried one of the open source clones sich as question2answer?<p><a href="http://www.question2answer.org" rel="nofollow">http://www.question2answer.org</a>
So much of the core mechanics of SO relies on SEO and a community of volunteer moderators, neither if which really exist in a corporation.<p>I suppose if a company had a paid librarian function, this could be successful. But in that case, even a normal wiki would probably work.<p>I seem to remember an article from Joel or Jeff many years ago describing why this exact model won't work. Can't seem to find it now though.
Pushing my message again, but if you've not done so in a while, visit <a href="https://stackexchange.com/sites#" rel="nofollow">https://stackexchange.com/sites#</a> and look at how many utterly non-technical topics are covered by this model. The application of the system is about far more than just traditional software development.
I think it's a mistake to look at this from the perspective of software developers. It's called "Teams" because it's for teams - which can be anything from software developers to facilities maintenance people. It's for teams that have questions (and answers), not for software developers who have questions (and answers).<p>By way of experience with this, we run an internally written Stack Overflow clone of sorts for a large industrial printing product we make. It's meant for people in our organization who have questions and are looking for answers. And as such, there are no "wrong" questions.<p>For example, someone might ask, "I'm traveling to the San Diego site - what's the most convenient hotel to stay at?", and create a new tag for "san-diego", "recommendations", and "hotels". Or they might post about "Top-of-form mark detected too close to the previous frame" using tags like "print-engine" and "top-of-form".<p>For us, both types of questions are very valid and "on topic" questions to post in our internal stack.<p>When we first launched our stack, we imagined it as being a kind of "crowd sourced internal knowledge capture" tool. But a real evolution in our thinking has occurred, and we've found that most people use it to post questions and answers at the same time. In other words, they've solved a problem and want to share the solution. And SO's "question/problem statement" followed by "answer/solution" template and framework makes it very easy for them to share this knowledge. Contrast with a wiki for example, where they are presented with a blank page and told to "document this issue".<p>One feature we are considering is the idea of wizards for certain types of posts. For example, if you are posting an answer about equipment work that requires opening electrical panels, we probably should have a warning about only doing this if you are certified for it. So the wizard idea might say, "Is this a solution that relates to electrical safety?" Checking yes automatically appends some boilerplate text with a caution about electrical certification.<p>We've also found that the voting up/down feature isn't that useful. People just don't do that voting stuff, nor do they really care about their reputation. What we are going to do is replace the vote system with a simple, "Did this answer help you?" type approach. It's literally the same thing, but with a different way of asking it. Because we don't actually do "down" votes, a "Yes" is a vote up, and a "No" prompts the user to post a comment explaining why it didn't help them, assuming it was what they were looking for. Was the answer not clear? Was it wrong? Did it not work? Is the information out of date? This kind of feedback (via comments) will help answer authors evolve their content to be better.
"Rest easy knowing that your Team’s data is secured in a dedicated network and logically separated into its own SQL schema. Learn more about our security policy. "<p>If its using logical separation on a shared SQL server, then is it really a "dedicated network"?
I feel like holding out single sign-on for a separate Enterprise tier priced at "Contact a sale rep for details!" is a mistake. Heck, I feel like any "contact a sales rep for details!" pricing tier is a mistake.
Why use this when Discourse is free? It is an open source product that lets you store all the data in your own database. And it’s by the same guys, too.