Because of the recent controversy, I had put forward this issue in an effort to understand whether or not I could reasonably contribute to this project. It was explained that my worries were not well founded. As explained in that issue, I was looking for a Microsoft project I could contribute to.
I do not like conflict for various reasons that stem from my upbringing, and do my best to find a compromise and to diffuse a situation. Requests like 1, 2, 3, 4, and others, demonstrate many reasons for wanting something that I've wanted myself, and am more than willing to implement: the UI icons should be subject to extensibility, just like the rest of VS Code. Not only would this solution accomodate both the groups who want no/different holiday themed icons and the groups who want holiday themed icons, but it would also accomodate those who certain theming isn't applicable at the same time of the year, which could have avoided the very mistaken attempt at using a snowflake instead, despite literally half of the four-seasonal regions being in summer right now, and the equatorial region not experiencing winter. But it happens to go further, as an accessibility thing. As mentioned in my initial issue, I am autistic, which has a very high comorbidity with sensory integration disorders, of which I also have. Some of the icon designs give me trouble. Here's where I beleive your approach is wrong, and further reason why extensibility is the appropriate way to handle this. SID's work in drastically different ways, and what gives me trouble can easily be totally acceptable or even pleasing to another individual with an SID. There is absolutely no universally accommodating approach for SID problems. While looking into this, I had discovered that it's not just SID's that present problems with the default UI icons, as there's at least one individual with nearsightedness that struggles due to design concept of the icons, not anything about a particular icon. However as I have seen from several twitter polls from this project, many people do like the existing icons. They still deserve to have those icons. For all of these reasons, I am sure that extensibility is the appropriate way to resolve all of these issues, and as I had stated, was more than willing to implement this.
So, I had gone through the process of cloning the VS Code repo, and installing/configuring all the required tooling. The process was difficult but I got it working.
There was one particularly difficult part of the build system that I reserved for a different issue. My understanding is that VS Code relies on node-gyp, which is more or less a repackaging of gyp, a project generator similar to cmake. gyp is unable to to handle non-ASCII user profile paths on Windows, which means node-gyp is unable to handle non-ASCII user profile paths on Windows, which means VS Code's build tools are unable to handle non-ASCII user profile paths on Windows. Aside from the obvious techncial deficiencies and very out-of-date nature of this software, it poses a problem I beleived to be a barrier of entry to contributions of this project for individuals who's primary language is not covered by the ASCII character set, making their username unlikely to be covered by the ASCII character set. Having to create a new user account and migrate necessary things over just to contribute to a project is an unreasonable burden on most of the worlds people, especially with how much globally aware software exists now. Per the Microsoft Open Source Code of Conduct:
Our communities welcome and support people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin ...
and
...We are a world-wide community of professionals...
Yet for many people around the world, contributing it more difficult than a very select group.
Now to be clear, I fully agree this is an issue with upstream software. Gyp is the problem. However, I do not understand why this issue was closed. To me, it comes off as "it's not an issue" because "it's someone elses problem". VS Code is still effected by this, even if it's someone elses responsibility to fix it.
My main area of programming has to do with text, and I've done an entire ASCII -> UNICODE migration in a language runtime before, so surely I can update gyp to be more globally aware as well. So I go clone gyp and start looking through it. There are some older complaints about the aforementioned, with some even included patches that never made it to the right people. However gyp has changed so much over the years that the patches would not apply anymore. So while I'm poking throughout the code, I take some breaks to also poke through VS Code issues others have filed, so I can keep in mind other areas I might be able to contribute to. This is where any and all confidence about inclusivity in this project starts to die.
I want to explain at this point, that my head and eyes are starting to hurt quite badly because github's text editor is too cramped and it bothers me. So I'm going to make this much shorter than the full extent of what I have found. I will only be citing a few of the over two dozen alarming issues I have come across. The change in my perceptions was not just a "oh look at this odd example I found".
There are numerous examples 1, 2, 3, and more, of accessibility complaints being immediately dismissed, because the existing design works appropriately for fully-abled individuals. One of the dismissive comments is, I beleive, extremely unselfware. Dismissing navigational difficulties involving notifications on the basis of "extensions are using them wrong" only holds logically if this project and the official Microsoft extensions are holding true to these principles. This is where the lack of selfawareness comes in. Simply navigate to source file for a language in which there is no extension installed, but is available in the marketplace. What comes up? A notification about the extension. A notification that a disabled person, depending on their input methods, will either have great difficulty navigating to, or be unable to navigate to. "But this is just a notice" right? No, it's a convenience, which is why this particular example is so interesting. Because no keyboard navigation methods exist for switching over to it, cursor movement is required, which is substantially more difficult for certain disabilities. This means that despite the convenience all fully-abled people are afforded, and some disabled people, that other disabled peoples will instead have to navigate to the extensions tab, type or speak (and hope its recognized) the extension name, and then still navigate over to install. I completely agree tab should not be used for this purpose. However, a keybinding for switching to a notifications context would be hugely beneficial for these people. And that's where we get into the other issue. How these were handled is unacceptable. Rather than explain why, I think it would be more constructive and better representative to explain roughly how I think things should have been handled. First, explain why things are in their current state. Second, explain the intended workflow. Third, ask the OP if the intended workflow is suitable, and if not, to elaborate on why it's not and what a possible solution might be. This is encouraged by the Microsoft Open Source Code of Conduct:
Understand disagreements: Disagreements, both social and technical, are useful learning opportunities. Seek to understand the other viewpoints and resolve differences constructively.
And yet, this was not done on a substantial number of issues.
And unfortunantly, I can't even comment on the most serious issue, because I beleive it might cause myself to violate the CoC. So that's unpleasant and I'm not sure how to go about resolving this one.
From what I have seen, I do not at all feel like this project is inclusive in the way it intends to be. Certain types of inclusivity issues are given more priority than others, with disability/accessibility issues seeming to be the most dismissed. I do not feel comfortable contributing to this project. I hope these issues can be resolved.
Because of the recent controversy, I had put forward this issue in an effort to understand whether or not I could reasonably contribute to this project. It was explained that my worries were not well founded. As explained in that issue, I was looking for a Microsoft project I could contribute to.
I do not like conflict for various reasons that stem from my upbringing, and do my best to find a compromise and to diffuse a situation. Requests like 1, 2, 3, 4, and others, demonstrate many reasons for wanting something that I've wanted myself, and am more than willing to implement: the UI icons should be subject to extensibility, just like the rest of VS Code. Not only would this solution accomodate both the groups who want no/different holiday themed icons and the groups who want holiday themed icons, but it would also accomodate those who certain theming isn't applicable at the same time of the year, which could have avoided the very mistaken attempt at using a snowflake instead, despite literally half of the four-seasonal regions being in summer right now, and the equatorial region not experiencing winter. But it happens to go further, as an accessibility thing. As mentioned in my initial issue, I am autistic, which has a very high comorbidity with sensory integration disorders, of which I also have. Some of the icon designs give me trouble. Here's where I beleive your approach is wrong, and further reason why extensibility is the appropriate way to handle this. SID's work in drastically different ways, and what gives me trouble can easily be totally acceptable or even pleasing to another individual with an SID. There is absolutely no universally accommodating approach for SID problems. While looking into this, I had discovered that it's not just SID's that present problems with the default UI icons, as there's at least one individual with nearsightedness that struggles due to design concept of the icons, not anything about a particular icon. However as I have seen from several twitter polls from this project, many people do like the existing icons. They still deserve to have those icons. For all of these reasons, I am sure that extensibility is the appropriate way to resolve all of these issues, and as I had stated, was more than willing to implement this.
So, I had gone through the process of cloning the VS Code repo, and installing/configuring all the required tooling. The process was difficult but I got it working.
There was one particularly difficult part of the build system that I reserved for a different issue. My understanding is that VS Code relies on node-gyp, which is more or less a repackaging of gyp, a project generator similar to cmake. gyp is unable to to handle non-ASCII user profile paths on Windows, which means node-gyp is unable to handle non-ASCII user profile paths on Windows, which means VS Code's build tools are unable to handle non-ASCII user profile paths on Windows. Aside from the obvious techncial deficiencies and very out-of-date nature of this software, it poses a problem I beleived to be a barrier of entry to contributions of this project for individuals who's primary language is not covered by the ASCII character set, making their username unlikely to be covered by the ASCII character set. Having to create a new user account and migrate necessary things over just to contribute to a project is an unreasonable burden on most of the worlds people, especially with how much globally aware software exists now. Per the Microsoft Open Source Code of Conduct:
and
Yet for many people around the world, contributing it more difficult than a very select group.
Now to be clear, I fully agree this is an issue with upstream software. Gyp is the problem. However, I do not understand why this issue was closed. To me, it comes off as "it's not an issue" because "it's someone elses problem". VS Code is still effected by this, even if it's someone elses responsibility to fix it.
My main area of programming has to do with text, and I've done an entire ASCII -> UNICODE migration in a language runtime before, so surely I can update gyp to be more globally aware as well. So I go clone gyp and start looking through it. There are some older complaints about the aforementioned, with some even included patches that never made it to the right people. However gyp has changed so much over the years that the patches would not apply anymore. So while I'm poking throughout the code, I take some breaks to also poke through VS Code issues others have filed, so I can keep in mind other areas I might be able to contribute to. This is where any and all confidence about inclusivity in this project starts to die.
I want to explain at this point, that my head and eyes are starting to hurt quite badly because github's text editor is too cramped and it bothers me. So I'm going to make this much shorter than the full extent of what I have found. I will only be citing a few of the over two dozen alarming issues I have come across. The change in my perceptions was not just a "oh look at this odd example I found".
There are numerous examples 1, 2, 3, and more, of accessibility complaints being immediately dismissed, because the existing design works appropriately for fully-abled individuals. One of the dismissive comments is, I beleive, extremely unselfware. Dismissing navigational difficulties involving notifications on the basis of "extensions are using them wrong" only holds logically if this project and the official Microsoft extensions are holding true to these principles. This is where the lack of selfawareness comes in. Simply navigate to source file for a language in which there is no extension installed, but is available in the marketplace. What comes up? A notification about the extension. A notification that a disabled person, depending on their input methods, will either have great difficulty navigating to, or be unable to navigate to. "But this is just a notice" right? No, it's a convenience, which is why this particular example is so interesting. Because no keyboard navigation methods exist for switching over to it, cursor movement is required, which is substantially more difficult for certain disabilities. This means that despite the convenience all fully-abled people are afforded, and some disabled people, that other disabled peoples will instead have to navigate to the extensions tab, type or speak (and hope its recognized) the extension name, and then still navigate over to install. I completely agree
tabshould not be used for this purpose. However, a keybinding for switching to a notifications context would be hugely beneficial for these people. And that's where we get into the other issue. How these were handled is unacceptable. Rather than explain why, I think it would be more constructive and better representative to explain roughly how I think things should have been handled. First, explain why things are in their current state. Second, explain the intended workflow. Third, ask the OP if the intended workflow is suitable, and if not, to elaborate on why it's not and what a possible solution might be. This is encouraged by the Microsoft Open Source Code of Conduct:And yet, this was not done on a substantial number of issues.
And unfortunantly, I can't even comment on the most serious issue, because I beleive it might cause myself to violate the CoC. So that's unpleasant and I'm not sure how to go about resolving this one.
From what I have seen, I do not at all feel like this project is inclusive in the way it intends to be. Certain types of inclusivity issues are given more priority than others, with disability/accessibility issues seeming to be the most dismissed. I do not feel comfortable contributing to this project. I hope these issues can be resolved.