The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Thanks not easy at this time, get some agents phoning me to find out if I have any roles available (?), buy 'Stuff' I meant AVI video files, configuration data, docs & diagrams of how to connect widget A to Widget B with letting the magic smoke loose! The test are being converted by myself and another to JIRA via Zephyr (or whatever!) the Chief is a big 'Jira Ninija' and got upset by people trying to use Jira like a relational Database...
Also late to the party...long-winded too And, good luck on your job search!
TL;DR - The single act of purchasing new tool is not going to solve an organization's problems. One must set up conventions and workflows for the tool to optimize team collaboration for the organization.
I have found in my "travels" that there is a misconception typically at the decision-making-level in organizations, that these types of tools (GIT, SVN, VisualSourceSafe, Sharepoint/Confluence, JIRA, Wikis, and bunches of others) and the features they provide, once purchased, make all your problems go away without any additional work. The flawed assumption is that the tool forces a specific workflow and thus forces team members to use the tool in just one way and by doing so, creates a single organizational structure for the data to be stored, which we all know is not correct - instead of the desired/assumed "file cabinet" for data (project docs, source, etc.), these tools become "junk drawers" (often referred to as the "wild west") where teams don't know what data is where, what is the latest version, identical doc's are stored in different locations/folders causing data coherency issues, nobody knows what is in the master/trunk branch (or tags or any of the other branches) - and it gets worse and worse as time goes by.
The key to team success is, once the tool is purchased, one or a few people build up a moderate level of expertise so they know best how to use the tool then create (and document) a structure (branch definition for source tools, folder structure for doc tools) and workflow that works best for all the organization's requirements, then get buy-in/agreement, and put in the constructs (like varying access rights per group) prior to its use, and police it's use (which can be time-consuming) during its use.
Mind you, for those that do contracting, you are often forced into the customer's source control/configuration mgt structure - sometimes a good thing, sometimes not.
In agreement with others on the post, using a source control tool like git/GitLAB/BitBucket/Subversion for documentation control is not a good idea - Subversion/Confluence tools are more appropriate. I find source control tools deal best with text-based files (like code), but not well with binaries (like MS docs, etc.) wrt version control.
Since I work for a small company, we have shied away from those complete solutions from Atlassian that are costly (JIRA/Confluence/BitBucket). We do use Atlassian JIRA for tasking/bug tracking, cloud-based Sharepoint for documentation, and internal GitLAB for source control. There is some use of Subversion, but find git more intuitive/logical although I have found the git paradigm is confusing when you first get started
I think they were referring to TFS Team Foundation not Teams, Microsoft's source control offering rather than the chat app, built into Visual Studio, the old VB6 used to have one called Source Safe or something like that.
I've heard that the main character is a real pain in the butt!
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain