What would you like to learn? Looking for recommendations 👀

Hi Friends,

I’ve been reflecting on our community and wanted to take a moment to share how grateful I am for your support of each other, we are very grateful for the time you spend helping others and sharing your experiences. Thank YOU :wave:t4:

And while I’m here also to share that we are exploring the possibility of hosting live teachable sessions, they would be in a 30 minute format via zoom call. We’d love to hear from you and welcome your ideas for topics. Feel free to drop any suggestion as a reply here :pray:

With sincere appreciation,
AG

4 Likes

More advanced Git stuff like rebasing instead of merging, and using release branches instead of just releasing from master, backfilling patches to older releases etc.

2 Likes

I work for one of the largest state government department in my state. They’ve been using TFVC since before I joined. I’m currently the TFS Administrator. We’re thinking of moving to the cloud, probably using Azure DevOps for project management and CI/CD, but GitHub for our source repository.

As the TFS administrator there are two bad habits that I struggle with which people do in this state department. In fairness to my colleagues, I believe they never received any training on proper source control, branching strategies, etc. The first is people have a bad tendency to do their own modifications to code, then check it into TFS, stomping on whatever else someone before them has checked in. For example, more often than I’d like, Person A will add a file and check it in. Then later Person B will add their own file or remove a file, then check everything in, ignoring the conflicts the Visual Studio (VS) raises. Now Person A’s file is gone (as far as TFVC is concerned) because it’s no longer in the VS project file. This happens repeatedly, so many times that it becomes almost a full time job, just getting the files correct so that both Person A and Person B can continue their work.

The second bad habit results from some managers wanting to get new apps generated as fast as possible. So, what happens is a team will create a base VS project. Then when they need to start a new project to satisfy some new need, they will create a new empty project in TFS, fetch the empty project down to a new folder on their machine, then go back to the base project where they will branch it into the new folder they created on their machine, and start working with it there. There is never any intention of merging these new projects back into the base project. So, new projects proliferate in this way. We’ve got several of those types of projects now. It’s my understanding that the managers who’ve encouraged their people to do this have done so with the erroneous thinking that if their people make a change to common code files in the base project, then it will automatically be migrated to all child projects that have been branched in this fashion. Of course, this doesn’t work as they expected. But they’re still getting a new functioning project, which they are happy with.

The first problem is one which I think any practitioner of TFVC or Git could fall into doing if they’re not careful. The second bad habit is something I think might only be possible to do with TFVC. I’m not entirely sure. I’ve been using Git for almost two years, but I’ve been working alone so haven’t any experience branching and merging with two or more people. Anyway, we desperately need to have training, generically speaking on proper branching and merging strategies and with Git in particular.

2 Likes

I think training on branching strategies for multiple collaborators in a repo would be great. Maybe this could take the form of tutorials. I see a lot of technical descriptions of these patterns online but not real world examples.

1 Like

Thank you @mattwelke we appreciate your feedback! I agree with you and always try to never user foo and bar when documenting things, at this age I think it is very reasonable to create a sample set and work with real life data.

@Rod-in-NM Thanks for your detailed feedback, please keep it coming. I appreciate you sharing your specific challenges, so we can hone in the best tutorials to help. I’m working with the team to put a free training session together, more to follow, and thank you again.

Best,
AG

1 Like

I would like to see more about customising CodeSpaces, with Docker and Dotfiles etc.

Thank you @andreagriffiths11 :slightly_smiling_face:

1 Like

I’d like to see a seamless sync experience between Codespaces and VSCode settings.

I’d like to see two globally editable sections for project readme files. Header/Footer — so we can easily manage to add info about sponsorship and logos stuff for companies that help us support/maintain our open source work.

Thank you! :raised_hands:

1 Like

I’d love to see a crash course in managing notifications. Working across multiple orgs for work, plus open source contributions means that there are too many for me to keep track of. Any tips on how better to manage them?

2 Likes

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.