Do you think we'll get the "closed as primarly opinion-based" flag squad on SO for Teams too?
Currently the only close reason available inside Teams is "Close as Duplicate". There also currently is no flagging inside a Team.
Stack Overflow for Teams
41–50 of 163 posts
Re: Stack Overflow for Teams
#42An open source alternative I've used in the past is Askbot: https://askbot.com/
It's built on Django, and covers all of the standard Q&A features that I've needed to use.
Re: Stack Overflow for Teams
#43I'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. On the other hand, so much of StackOverflow's value comes from the economies of scale at hand, and I'm uncertain how…
There was an open source version of Stack Overflow that I set up internally a few years ago at a previous company. I was the only one on the team who actively used it, but even then I found it useful as it was a place to squirrel away these useful little pieces of information you come across and don't know quite what to do with. I ended up coming back to find stuff I'd put there a few times and was starting to refer others to questions here and there.
Then after a couple months, just as it felt like it was getting some traction, the server got wiped out accidentally by our server team and there were no backups. I never got around to putting it back up.
I hope not having your knowledge base arbitrarily wiped out by careless admins would be a feature of this service.
Re: Stack Overflow for Teams
#44Joel wrote a blog post about it, detailing how it currently works:
https://www.joelonsoftware.com/2018/05/03/announcing-stack-o...
It was already linked on HN:
Re: Stack Overflow for Teams
#45Do you think we'll get the "closed as primarly opinion-based" flag squad on SO for Teams too?
Actually this brings up one of the things I like the most about this SO for Teams idea - it could also be used as a sort of slant.co substitute, where a large dev team is trying to settle on a common programming language or persistence framework, and each person can register their opinion or vote on an existing one. After N days, the whole group decides to select the option with the most votes. Since voting is anonym…
It was a weak joke concerning the usual complaints about SO and because I thought it was an on-premise offer, not integrated in the main SO site. As said below, there's no flagging in SO Teams.
If you need anonymous voting for decision concerning language/framework, I think you have a big problem: it would mean individuals are afraid of voicing their opinions regarding a technical choice and that's not something that can just be solved with a tool.
Re: Stack Overflow for Teams
#46I want to create a public Stack Overflow, just using the engine but rebranded as my own QA site.
Re: Stack Overflow for Teams
#47I 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.
Re: Stack Overflow for Teams
#48Seems 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…
For the past few weeks, I've been digging into a codebase that is legendary among my team for its complexity. While I have disagreements over some architectural choices, the biggest pain point has been the lack of documentation: when I look up the JIRA story referenced in the git commit, it's often a 4-pointer (the highest value we use before we break stories up) with no context. I found one story that had EIGHT pull requests linked to it, and all that was documented was "modify {entity}".
This code base is not even two years old, and I'm already concerned about its long-term viability. The colleagues that worked on it are extremely helpful, but details are fading from their memories over time. Its one saving grace is the fairly extensive test suite, so at least I have some degree of confidence that I won't be breaking things whenever I look at it the wrong way.
Re: Stack Overflow for Teams
#49I'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. On the other hand, so much of StackOverflow's value comes from the economies of scale at hand, and I'm uncertain how…
There was an open source version of Stack Overflow that I set up internally a few years ago at a previous company. I was the only one on the team who actively used it, but even then I found it useful as it was a place to squirrel away these useful little pieces of information you come across and don't know quite what to do with. I ended up coming back to find stuff I'd put there a few times and was starting to refer…
can confirm: that's definitely one of the features of this product.
Re: Stack Overflow for Teams
#50Seems 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…
For the past few weeks, I've been digging into a codebase that is legendary among my team for its complexity. While I have disagreements over some architectural choices, the biggest pain point has been the lack of documentation: when I look up the JIRA story referenced in the git commit, it's often a 4-pointer (the highest value we use before we break stories up) with no context. I found one story that had EIGHT pull…
Perhaps a framework for minimal effective documentation would help. Requiring documentation that starts with "As a {role} I want to {verb}" might not be as effective as saying an application can be defined as a set of features, and each feature is described by it's list of acceptance criteria -- each of which map to one or more unit tests. In addition to all of this would be something in free-form prose from a business operations person describing why a feature needs to be added or modified. "Our competition is kicking our ass because they have feature X in their product and we don't -- we need to fix this." I'm not sure every feature should have something that looks like a mission statement but it would certainly elucidate the motivation for adding/modifying the feature in question.