For folks on NVDA devlearning subgroup: consider this the “real” start of unit 5. For members of nvda-devel group, I’m skipping a fast intro to NVDA post for now.
Before getting into learning how to actually contribute code back to NVDA community, it is important for us to go over what exactly code contribution is (and is not).
Code contribution, in terms of NVDA, is more than just compliance with open-source philosophy of sharing code – it is one method for giving back to the NVDA community, and in extension, to the wider blindness and disability community. In short, you are effectively saying, “as a way of saying thank you, I’m donating my programming talent to a project that changes lives of thousands”.
First, code contribution is a way of saying thank you (for cultures that are sensitive to that). If you just use NVDA as a user with talent for programming, you’re just going to enjoy what NVDA has to offer on the surface. One way to go beyond a simple appreciation for what NVDA can do is thinking about giving back to your community, using the skills of a programmer or a code contributor.
Second, code contribution is a practical way to understand blindness and the associated reality indirectly through technology. For a blind computer user who uses NVDA, their reality is shaped by what the screen reader presents to them. If you want to understand how that “reality” is created, you must look at how the screen reader is coded (for those talented with it) and presents information. That way you can indirectly understand limitations of what blind people must face and possibilities out there.
Third, code contribution is a practical way of exercising your computer science education, at least with software that can give you immediate (or not so immediate) feedback. As some of you are kinetic learners (love the action), having a screen reader respond to you, especially respond to your code edits is a practical way of enriching your education.
Lastly, code contribution requires professional conduct and attitudes. NVDA is not just a volunteer project – we have professional programmers behind it alongside volunteer contributors (I myself fall into the latter category). In other words, the act of showing willingness to contribute code to NVDA project means you are ready to learn (and sometimes refresh yourself) about professional-level (or sort of equivalent) responsibilities in software engineering field.
Based on the above, you might think NVDA code contribution is easy, fun, and helpful, and in most cases, it is. But here are some things to think about, or rather, what code contribution is not:
First, the ability to contribute code is not an invitation to think you are very privileged i.e. above everyone else; rather, it is an invitation to think about understanding the humanity of NVDA community. Computer programs are human artifacts (or, in some cases, indirect human artifacts when AI was used to write code). As such, different people have different interpretations about how to use (and even write) the code you donate to NVDA community. As you begin (or continue) your journey as a code contributor for NVDA project, keep the humanity who will use your code in mind.
Second, do not think of NVDA code contribution as a one-time lab assignment; it is a lifelong process. If you think that fixing bugs is like a typical lab assignment, you are effectively saying, “NVDA GitHub issues and bug reports are yet another commodity”. Now I know for the fact that some of you are offended by it, and I apologize for coming across that way; but what I’m trying to say is that the experience of contributing back to NVDA community via code is a precious one that should be cherished.
Third, do not think you can show off your skills with massive (and sometimes, complicated) code changes. Often, changing one line resolves a host of bugs (the latest one being NVDA issue 9373 and associated pull request; the add-ons dialog inconsistency). My personal philosophy is to go with smallest changes that will have massive impact; in other words, the process of contributing code requires a lot of time spent thinking, not writing.
Fourth, speaking of writing, do not think you can get away with writing Python and C++ alone. As you learn more about code contribution (in subsequent posts), you will find that you’ll write more English and your native language (and others) than Python. This is because your source code change is just one aspect of being a competent code contributor – your other job is to being a competent and mindful communicator.
Take some time to think about what I outlined above, because the first (real) lesson in code contribution is examining one’s attitudes, not how to let NVDA say whatever you want. Only after thinking carefully about your attitudes will we get into our first lesson in code contribution: listening to users.