@gyzerok

@bpasero truly epic day today as we are finally there after more than a month of work! Big thanks to you for guiding me
through this! 🎉

I believe this is the last bit needed to enable encodings.

Great 🚀 . This was by far not a simple task, given complexities with streams etc and also because this code is hit every time a text file is read or written. I am happy how this turned out in the end 👍

Contributing to VSCode was very enjoyable both because I love the editor and use it for many years and because it was very
interesting to work with the codebase.
During my work I tried to keep changes that are not strictly important for the feature to work to minimum, so you are not
overwhelmed by the amount of changes. However I had some ideas about small refactorings which I would like to try out and
see your opinion on if result looks good. I guess I feel a bit of ownership now for the code I worked with 😄

Feel free to do more contributions as you see fit, for example we have 2 queries for issues where we are open for contributions:

• help wanted
• good first issues

Especially around web I think there is even a lot more that can be done, even if we are missing these labels feel free to jump on it: https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Aweb

A very simple example would be moving SUPPORTED_ENCODINGS to encoding.ts, so all the encoding stuff lives together.

Yeah that sounds about right, the only reason it was not there before is because encoding.ts was in base layer. But now that it moved in workbench, I am fine moving it over.

I know that you in VSCode team have to deal with huge amount of issues and PRs every day, so I don't want to create more
work for you just for the sake of it. That's why I would like to ask if you are open to the idea of me doing it. And also what
would be the best process for it. Can I just open a PR not connected to any issue?

I think it is always good to correlate a PR back to an issue, e.g. in our testing process at the end of the month we use issues to verify new features or bug fixes. Having a PR without an issue would not allow us to follow that process.

Is there an area in particular where you thought about contributing?

Yeah that sounds about right, the only reason it was not there before is because encoding.ts was in base layer. But now that it moved in workbench, I am fine moving it over.

Cool, that's exactly the reason though you've had before :)

I think it is always good to correlate a PR back to an issue, e.g. in our testing process at the end of the month we use issues to verify new features or bug fixes. Having a PR without an issue would not allow us to follow that process.

How would I connect something like moving SUPPORTED_ENCODINGS to an issue. The one for encodings support is closed now. Plus this is more of a refactoring, it has nothing to do with the issue itself. Should I create a fresh issue for that to follow this process?

Is there an area in particular where you thought about contributing?

Thanks you for suggesting which categories of issues I can look at.

I think I'll try to see if there are issues I can solve on the web side. While I am waiting Remote - SSH to allow to select static port to run server on, I am stuck with using web version 😄 Might as well help you improve the experience on that front. Basically encodings was the area which I was personally missing.

Also I highly appreciated your test coverage, which helped a lot during my work. I will see if I can make it even better!

How would I connect something like moving SUPPORTED_ENCODINGS to an issue. The one for encodings support is closed now. Plus this is more of a refactoring, it has nothing to do with the issue itself. Should I create a fresh issue for that to follow this process?

I agree, this example is probably one where an issue is too much. Though we do have the label debt that can be used for refactorings and cleanup such as this one. Feel free to do that change this time without an issue since we already talked about it.

The reason we typically ask for an issue first is also so that VSCode devs have a chance to comment wether they would accept a PR or not. For example we often receive PRs for cosmetic or style code changes or even linting fixes that we close because we did not ask for help or it comes down to personal preference of the developer if certain code is written like it is. Often a refactoring falls into this category and thus the PR author might end up doing a lot of work without getting accepted.

Bottom line, a PR is safest if it traces back to a "help wanted" issue 👍