My dear friend Mel Chua is, as of this year, Dr. Mel Chua, as they have now deposited the doctoral dissertation that they successfully defended several years ago. Yay Dr. Chua!!!

There's been a bit of a problem with the open access availability of their dissertation, so, with their permission, I've uploaded it to my site - here you go. Faculty Roles in Curricular Change: Postmodern Narrative Ontologies, by Mel Chua, a dissertation submitted to the Faculty of Purdue University in partial fulfillment of the requirements for the degree of Doctor of Philosophy, School of Engineering Education, West Lafayette, Indiana, May 2023.

The slides for Mel's dissertation defense also include, in the speaker notes, a full transcript of that talk including the questions and answers afterwards; that defense is a helpful summary that's more accessible to non-academics than the text of the dissertation itself (Mel's notes on how to use it).

Mel is currently coping with metastatic bladder cancer, which is a reason they haven't been blogging as much lately as they used to. In case you're inclined, you can contribute to their GoFundMe fundraiser, "Get Mel Out Of Oncology and Back to Pedagogy".

Dr. Chua has studied a few different fields, and finds interdisciplinary relationships among them; they're "an electrical engineer who turned into an education geek and open source hacker". Their doctorate is in engineering education, and they have also done Deaf and disability studies, signal processing and audio engineering work, dancing and choreography, comic books, linguistics I think, I'm probably forgetting a lot.

Mel has been a huge influence on me since we met sometime (approx. 2006). In open source practice, as a teacher and learner, as an Asian-American negotiating family stuff, as a colleague to disabled people, as a friend -- I cannot really imagine who I would be or what lenses I would use for so many parts of my life if I hadn't gotten so many chances to interact with their work. They're just utterly brilliant and I am writing this post partly to point to their dissertation and GoFundMe but also just to celebrate my friend.

They keep noticing and poking at topics that would richly reward exploration, but they're so ahead of the curve that this means they often have to build their supporting intellectual infrastructure in order to investigate things! From their post "Cognitive dissonance: welcome to academia":

I'm a novice in the academic world. Context eludes me. Descriptions of methods are swarming like abstract, unapplied flies around my head. I came here because the open source world hasn't yet been translated into the world of scholarly learning -- these dynamic communities of practice for ridiculous amounts of learning remain unstudied, unrecognized, despite addressing so many of the things that engineering and computing educators have been crying out for for as long as I've been hearing them: authentic learning experiences! mentorship, peer teaching! global communication, teamwork, self-efficacy... onwards, onwards. Yes! I thought. New ground to blaze!
And then I got to grad school and spent most of my first month disoriented and fervently wishing for something that someone had done before, please don't let me be the first one out here, please don't let me be the only one out here. The irony is thick, I know; isn't this what I asked for? It is, and it's uncomfortable, and I will feel quite lost for quite a while (possibly forever), and that's something that I need to remind myself to be okay with. The trouble with doing something new is that you can't really hunt for validation for it until after you do it. It's like a startup. You need to take a risk that you'll put in all of this effort and then nobody will care.

If you are interested in how we learn and teach engineering skills, especially outside of traditional institutions, in my opinion you should care about Mel's work, as I do. Even when it's hard work to keep up with the depth of their thinking!

In addition to the incredible wealth of thought they've published on their blog, Mel's published quite a lot in scholarly sources, both formal research and more personal reflections such as "The Privilege of Being Oblivious" (ASEE Prism, Vol. 25, Iss. 1 (Sep 2015), p. 23).

I couldn’t “just geek out.” The environments where I was trying to learn and do “nerdy stuff” were socio-technically broken in a way that made it hard for me (as a disabled minority woman, among other things) to join in. If I wanted to become part of the technical community, I had to start by fixing the technical community.

For more, peruse Dr. Chua's Google Scholar, academia.edu, and ResearchGate profiles; quite a lot of that work is unfortunately behind paywalls, so I suppose I gotta say, go Sci-Hub them. I recently enjoyed their conversation with their coauthors in "Engineering and Engineering Education as Spiritual Vocations" (2014) which you can read for free online. These days they've also been posting frequently on Twitter, which is where their community of disabled academics and cancer patients has mostly cohered.

A few years ago I got to collaborate with Mel, and with Shauna Gordon-McKeon, on the Digital Infrastructure Research project "Conceptual Mismatches: What FOSS At-Large might learn from the study of PyPI" funded by the Ford and Sloan foundations (one-page summary, final report). The core research question: How do mismatched conceptualizations between maintainers and users of a FOSS digital infrastructure project interact to affect the community health, and thus sustainability, of such projects? Their findings include this intriguing list of tensions, such as:

Expectations of whether communication from upstream to downstream should happen: the expectation that users should be able to maintain an uninterrupted focus on their own work (encapsulation) vs. the expectation that users should have an ongoing awareness of happenings upstream (non-encapsulation)

Finally. some of my favorite blog posts of Mel's:

"Integrity, not reliability":

In engineering (especially with software system), we work with subsystems and components that are inherently unreliable. We have ways to hook them together to make the system as a whole okay, even with the component-level unreliability. Backups, notifications, and so forth. How can I be part of a larger system that’s reliable, even if components of myself are unpredictable?

"Holding the cup": "It's one of the best things I know, watching people pour our their stories in that hushed and sacred space." "#possesa Fri: 5 minutes of improvisation" (POSSE here is Professors' Open Source Software Experience):

Tayo asked me during a coffee break how I (as an experienced contributor) would get started with an unfamiliar project. We called the now-caffeinated professors together, threw my laptop on the projector, had Grant set a countdown timer for 5 minutes, and called out for a random project. "Sakai!" called Boniface. "That's... an open source project somehow related to education, and... that's... all I know about it!" I responded, and we all agreed these waters were sufficiently unfamiliar to me to be a fair test.
Grant hit the timer, and off I went.

(This exercise later turned into the instructional "introducing yourself to unfamiliar open source projects" how-to from Mel's time as a resident at Hacker School, later the Recurse Center.)

I could go on and on and on about Mel, about my memories of our Coast-to-Coast Walk together across England 11 years ago, about how I absurdly feel like my memories of them project backwards into my teen years ages before I actually met them?!, about the deep tender feeling I have knowing that I get to be in the same universe as them. I love you, Mel.