Posts that are teaching open source-ish

RIT FOSS projects: midterm praxis reflection assignment (feedback welcome!)

As part of the RIT FOSS Projects course this year, we are having students write a substantial mid-term reflection on praxis. Here’s the current version of the assignment – feedback welcome, of course! (For Spring 2018 students: both this version of the assignment and any edited/updated versions are acceptable for submission – you can choose which you’d prefer to do.)

Your praxis reflection consists of answers to the following questions, submitted to MyCourses in English and/or ASL in any format readable by your instructors (.txt, .odt, .pdf, .doc, and links to signed videos are all safe; ask about other options and we’re likely to say yes).

This reflection should be several pages long and reflect substantial amounts of thinking; it has the same point value as a two-week project sprint. Only you and your instructors will see your answers to these questions. Grading is 5% for each of the 18 mandatory questions, plus 10% for spelling, grammar, clarity of writing, etc.

You will be scored on the quality of your reflection, not the behavior you are reflecting on (i.e. a thoughtful analysis of “in hindsight, I really messed up” will get a high grade, whereas simply saying “I did well” without explaining what you did well and why will get a low grade).

  1. In 1-3 sentences, summarize your overall project, as you currently understand it. This summary should reflect your evolving understanding of your project, FOSS contributions, and feedback from classmates/instructors so far.

  2. How has the summary above changed from the summary in your initial/simple project proposal (or, if you switched projects, the first time you summarized/presented it to the class)? Why/why not? What feedback and/or learning experiences have informed your writing of the current version? (minimum 3 sentences)

  3. What have you learned about your FOSS community and its culture and health, and/or individual contributors you’ve been interacting with so far this semester, and how does that affect your project plans for the rest of the semester? (minimum 3 sentences)

  4. What have you learned about your intended end-users so far this semester, and how does that affect your project plans for the rest of the semester? (minimum 3 sentences)

  5. Are your goals clearly defined (is it unambiguous whether you’ve achieved them or not), do you regularly measure your progress against them, and do you recalibrate them as new situations come up? Why or why not? (minimum 3 sentences)

  6. Are you using existing tools, libraries, and knowledge from others whenever possible, instead of reinventing the wheel? Why or why not? (minimum 3 sentences)

  7. How are you choosing tools? If some of them are new to you, are you giving yourself adequate time to learn them? Are you investing in tools and practices up-front that will make your life easier later on (i.e. automation of test/build infra, documenting as you go, etc.) Why or why not? (minimum 3 sentences)

  8. How are you getting feedback on your community contributions and/or development products, and from whom? Are these the right people? Why or why not? (minimum 3 sentences)

  9. How are you planning for the future in terms of making it possible for you and/or others to continue using or building on your work? Why or why not? (minimum 3 sentences)

  10. Rate yourself 0-5 on the following (0 = whoops, 5 = amazing), and give a 1-3 sentence explanation for each rating. Ratings are about you individually, not your team as a whole.

    1. Clarity of goals

    2. Technical progress towards goals

    3. Leaving a trail (code commenting, documentation, blogging, issue tracker usage, etc.)

    4. Engaging your users

    5. Engaging your FOSS community

    6. Adapting as things change

    7. Other (optional, please specify)

  11. What qualities does a good FOSS contributor and/or teammate have? List at least 3, with rationale for each. (Ex: “A good FOSS contributor/teammate is X, because Y.”) there is not a canonical right/wrong list; we are interested in seeing how you are thinking, not whether you guess the “correct” list of qualities.

  12. If you have teammates: how do you feel about the way your current team is working together? If you are working alone: who have you engaged with regarding your project so far, both within class and outside of it, and how do you think these engagements have been going? Be specific and give examples (ex: “we can resolve disagreements quickly; for example, last Tuesday we were debating whether to do X or Y…”) (minimum 5 sentences regardless of which option you choose.)

  13. What qualities do good development and/or learning goals have? List at least 3, with rationale for each. (Ex: “A good development/learning goal is X, because Y.”) Again, there is not a canonical right/wrong list.

  14. We acknowledge your goals can and should keep changing as your project progresses, but what are your current development and learning goals for:

    1. Sprint 3? (minimum 5 sentences or bullet points)

    2. Sprint 4? (minimum 2 sentences or bullet points)

    3. Sprint 5? (minimum 2 sentences or bullet points)

  15. What is the most unexpected or surprising thing you’ve learned about contributing to FOSS projects so far this semester? (minimum 3 sentences)

  16. What is the most unexpected or surprising thing you’ve learned about yourself so far this semester? (minimum 3 sentences)

  17. What is the one thing you could do this semester that would have the biggest impact on your approach to this course / your ability to contribute to a FOSS community / your development as a professional? (minimum 3 sentences)

  18. How will you approach the remaining sprints this semester differently than the sprints you have done so far, and why? (minimum 3 sentences)

  19. (Optional.) Any notes for us on how to run this class next year? We’re interested both in things we should keep/do again, and things we should do differently.

  20. (Optional.) Anything else we should know?

Liveblogging RIT’s FOSS projects class: initial questions for community spelunking

Stephen Jacobs (SJ) and I are co-teaching “Project in FOSS Development” at RIT this semester, which basically means “hey students, want to get course credit for contributing to a FOSS project?” The class is centered around 5 project sprints of two weeks each. The first 3 weeks of class are preparing for the sprint periods; the week before spring break is a pause to reflect on how sprints are going. Otherwise, class efforts will be centered around executing project work… (aka “getting stuff done”).

From the syllabus (

This course is a studio-centric experience designed to immerse students in the praxis of FOSS (Free and Open Source Software) communities. Notice that we focus on praxis, which is a conscious enactment of practice deeply informed by theory. In other words, it’s important to be practitioners who can think about their shared practice.

Notice also that we talk about the praxis of FOSS communities, which includes but is not limited to software development — ways of communicating, collaborating, designing, testing, marketing, budgeting, meeting, etc. are just as much a part of FOSS (and software engineering) praxis as writing code. You will be creating FOSS software, and you will be engaging with the rhythms, relationships, and routines of an established FOSS community with a complex set of sociotechnical dynamics that exist independently of yours. It is our hope that this course will help you navigate the kinds of delightfully messy, large-scale, long-term projects that you will encounter out in the real world.

I’ll be liveblogging the class, as one does. Right now, students are working on their project proposals, which is a big messy task that involves spelunking into existing FOSS communities, figuring out what’s up, and thinking about what’s possible to accomplish during the course of the semester. During our last class, we collaboratively brainstormed a list of starter questions we want to find out while doing that initial community spelunking. I was impressed by how much the students were already thinking about sociotechnical dynamics (instead of just starting to myopically look at the code in isolation), which makes me super happy.

Here’s what we came up with, in thematic clusters.  You can think of these as guiding questions for a spelunking quickstart such as (basically, if you only had a few minutes to get a sense of whether you wanted to contribute to a FOSS project, what questions would be the highest-priority ones to ask)?

  1. What are we gathering around?
  2. What are the goals and the roadmap to get there?
  3. What’s the purpose of the project? Do they have use cases?
  4. Why should I want to contribute?
  5. How do I find people and information and ask for help?
  6. How do they communicate? Do they have forums, chatrooms, mailing lists, etc. and how can I start lurking?
  7. Who’s leading it and who’s working on it?
  8. What is the governance/leadership structure? How do decisions get made, and how fast?
  9. Do they have local meetups and/or online ones I could attend?
  10. How complete are the docs?  Where do I go and what do I Google if the thing I want isn’t in the docs?
  11. How thoughtful have people been about the contributor experience (and do I want to have that contributor experience?)
  12. Do they have a code of conduct? How good is it?
  13. Do they have contributor guidelines?
  14. How well do they Onboard?
  15. How can I help and what skills do I need? (Can these questions be answered easily?)
  16. What does the code activity look like?
  17. What’s the infrastructure?
  18. What is the license? (Make sure it’s actually a FOSS project.)
  19. What and when was the last commit to a core repo?
  20. What/when was the latest release and how is it working?

Want more inclusivity at your conference? Add childcare.

Providing conference childcare isn’t difficult or expensive, and it makes a huge difference for parents of young children who might want to come. If your community wants to (visibly!) support work-life balance and family obligations — which, by the way, still disproportionately impact women — I urge you to look into providing event childcare. I don’t have kids myself — but a lot of my friends do, and someday I might. I’ve seen too many talented colleagues silently drop out of the conference scene and fade out of the community because they needed to choose between logistics for the family they loved and logistics for the work they loved — and there are simple things we can do to make it easier for them to stay.

A good number of conferences have already started offering free or low-cost childcare on-site, and Above All Human is one of them. (Above All Human also used a Code of Conduct, another simple way to shift conference culture towards inclusivity and diversity.)

I talked with Scott Handsaker, one of the conference organizers, to ask how they set it up. It was easy. There was an existing daycare facility nearby, so trained staff, equipment, space, and insurance were all taken care of. All Scott had to do was negotiate the price, which ended up being $30 per child. Out of 1,000 people in attendance, roughly 10-15 used childcare, for a total price tag of $300-$450 per day.

The resulting slew of publicity was tremendous. Scott mentioned they were late in organizing childcare — too late to advertise it on the conference website — so they only had a little time to message via email and social media. Even so, childcare was the #1 thing people tweeted about leading up to the conference. (“This [twitter search] nowhere near captures the volume of tweets or the sentiment,” Scott wrote.) In fact, that’s how I found out about Above All Human in the first place — a former classmate raving about childcare on social media. This is the sort of exposure you want for your event, brand, and community. Financing conference childcare was snapped up by Slack as a low-cost, high-impact, high-visibility corporate sponsorship opportunity.

If your conference location doesn’t have childcare on-site, talk with nearby childcare providers or a local college with an education/teacher-training program. You’re looking for care providers with training in early childhood education or some similarly related field, medical knowledge (CPR/AED etc), and enough experience to take care of insurance and logistics, which often involves negotiating directly with the hotel or other conference location about space and setup.

Some conferences have written documentation on their childcare setup. GovHack wrote a behind the scenes look at childcare for their conference, and YOW stands as a good example of how to promote it.

Right now, determined conference committee members can pull something together for their own event by taking advantage of resources like these, as well as tapping into the informal network of conference organizers who’ve coordinated childcare in the past. However, that network can be hard to find — so as more and more events attempt to do this, we can share notes and work to make it easier. A great next step would be to compile more writeups about the childcare-at-conferences process and to list events that have had it and are willing to talk with other events who are interested. Eventually, we could create a series of templates and guides for how to email daycare providers, how to advertise, what insurance to secure, and so forth. If you know of existing resources or efforts, please let me know and I’ll add them to this post.

Edit: Reader-provided resources so far…

  • David Nelson Adamec noted that PyCon, a major programming language conference, provides childcare: “I like that they call out “Company X is our childcare sponsor”, making it a cool thing to be and encouraging others to follow suit,” says David. He also noted that has more general tips for organizers.
  • Sara Melnick noted that SIGCSE, a major CS education conference (academic) provides a kids’ camp, almost like a parallel conference for children:
  • Bonnie Tesch submitted MoMiCon, an academic gathering deliberately designed as a conference format experiment designed for mothers with young children. Some very cool design ideas here.
  • Anne Lucietto noted that childcare isn’t the only need — sometimes adult care is needed as well.
  • Peter Barszczewski noted that the same setup applies to hackathons.

Learning activities for when your students are exploring areas you don’t know (inspired by open source)

Preparing to teach a class where you “don’t know the material” is tricky, cardiology especially when the thing is so big and so vast that you can never truly be an “expert” in it. If you think about expertise as knowing all the things, that is. If you think of expertise as the ability to be productively lost, that changes the entire game — the trick is how to help your students get through the same sort of territory.

I don’t have an overarching framework of strategies, but we do have a few things to share from the Teaching Open Source world. I wish we had a better write-up of our overall philosophy, but it wasn’t sufficiently developed (that’s something I’d love to work on with others… later… after… thesis…) but you can infer a bunch from some of our artifacts, so here you go, in order of least interesting to most interesting in my heavily biased opinion.

1. We have generic project-helpful activities.

We have a number of learning activites that (1) are highly likely to be useful for students regardless of what project topic they are on and (2) have clear criteria for successful completion, aka they are assessable. Analogous college-type things might be stuff like “make a test plan for your object” or “determine the appropriate formulae for predicting the behavior of your material” (I’m obviously making these examples up in a domain — materials science — I don’t know much about).

2. We have specific tool walkthroughs.

We also have activities that are walkthroughs of specific skills/tools common to most projects, often on a known setup (in the case below, a dummy server). This would be things like “do this intro exercise to use the Instron for the first time with our pre-cut samples.”

3. We have activities about critiquing the work of others (not other students in the class — this is not about peer assessment).

Moving into more interesting stuff: we also have activities that are about looking at other people’s work — not making new things, but critiquing existing things, to start developing a sense of how experts see things. In college, that might be: “Look at these pages from 3 lab journals, compare/critique; what makes the good ones good, the bad ones suboptimally helpful?” The reason it’s not peer critique is that you want to curate the examples to be rich and to have a range of things you can pull out in the discussion. (For those of you with qualitative research backgrounds, you can think of this as artifact analysis.)

4. We have resources (not just live demos) that lay out expert thinking.

We have think-alouds, where (more) experienced people demo their thought process being “productively lost” and then unpack it to newcomers, so they can start comparing metacognitive strategies. Every time you think out loud to students with their project, you’re doing this — but sometimes making artifacts is helpful, too. Also, accessibility is super-important for this… if you’re making videos, caption them. If you’re including images, describe them, and so forth. (My images are screenshots of the linked webpages, so I didn’t put image descriptions.)

5. We frame their mindset explicitly.

We have documents that explain the state of mind / viewpoint / psychological priming we want students to take towards things.

On the relative openness of text/document formats: .txt and .csv

My friend and research colleague Todd Fernandez writes: I know the ODF (Open Document Format) is generally the preferred format from an open documents standpoint. My question is whether you [and other Free/Libre groups] would consider .txt files in Unicode and .csv (comma-separated value) data files considered equivalently open?

First of all, disinfection I can’t answer for FSF or other groups — so what you’re getting is the Mel answer to “are .txt and .csv files open?” This email reply is getting so long that I’ll turn it into a blog post.

The Mel answer is “yes.” I consider .txt files in Unicode and .csv to be “open.” In fact, remedy I personally prefer to use them over ODF, which I’m rarely able to open with the software pre-installed on most computers I encounter.

In the paragraphs that follow, I’ll get into more detail behind my reasoning. To define “open” and “free,” I’ll loosely use the Open Source Definition (OSD) and the Free Software Definition, noting that these were created for software and need to be adapted for a discussion on file formats.

In discussing these file formats, I’ll cover .txt first, since .csv builds on top of .txt. The file extension”.txt” can mean a lot of things, and each of those things has different levels of open-ness (from a more legal-ish open standards standpoint, see definitions above) and accessibility (from a “how many people are able to read/write them on their computers with their current software” standpoint). I personally care about both.


You asked specifically about Unicode, but “.txt” can also mean ASCII, which is/was an American-developed standard for text information. I’ll start here, since ASCII was where Unicode began (in fact, ASCII’s 128 characters are Unicode’s first 128 characters).

ANSI X3.4-1968 is the document describing this encoding. It is a standard that’s widely used and published, lots of programs can access it, and you can use it in your programs without too much effort and without licensing costs (as far as I can tell; I can’t easily find the exact legal status). Basically, if I translate the Open Source Definition from software to file formats, I can’t find evidence that ANSI X3.4-1968 itself contradicts any of its criteria. I know this is different than proving that it absolutely meets all these criteria, but this is good enough for me.


As an interesting side note: ASCII is an ANSI standard (American National Standards Institute, hence the ANSI- prefix on its standards document). ANSI’s definition of “open” is about “do stakeholders have access to the consensus decisionmaking process that forms the standards?” and “are licensing fees and getting permission to use the standard at a reasonable and not overly burdensome level?” rather than “are there no licensing fees and permissions needed at all?” The latter corresponds to part of the 4 requrements for “freedom” according to the FSF, so it’s possible for something to be “open” according to ANSI but not “free” according to the FSF.

It would be interesting to go through and do a more rigorous look on whether ASCII’s legal/licensing criteria meets the Four Freedoms. I’m not a lawyer, but I’d be interested in what a lawyer would say.


“.txt” can also mean UTF, or Unicode Transformation Format; this is what your email asked about. The “A” in ASCII stands for “American,” and “American” in this case meant “monolingual,” meaning that if you wanted to type something outside ASCII’s 128-character, heavily-biased-towards-American-English set, you were flat out of luck. Unicode took the first 128 characters of ASCII, then… kept on going. Unicode is a more internationally-savvy superset of and successor to ASCII.

UTF-8 and UTF-16 are two Unicode variants in common use. The numbers refer to the number of bits per character, which you can think of as “UTF-16 has more letters in its gigantic international meta-alphabet than UTF-8.” UTF standards are developed by the Unicode Consortium, which I keep mistakenly typing as the “Unicorn Consortium” (which would be kinda awesome).

Unicode’s copyright permissions language seem very, very similar to the 4 requirements of the FSF for freedom. Since ASCII is a subset of Unicode, this makes me even more comfortable saying that ASCII is also “open.” However, I am not a lawyer, nor am I using “open” in a legally rigorous sense here — remember, I am a non-legally-trained engineer going “yeah, I don’t see anything that contradicts the definitions made for Open and Free software, if we were to translate it to file-formats-land.”


CSV is a format that’s layered atop plaintext (ASCII, UTF, whatever). In other words, you use plaintext to write a CSV document. CSV itself is not formally specified, which means it’s a free-for-all, and… you can use it for whatever, because you’re pretty much making it up. It’s just that you’re just making it up in the same way lots of other people have made it up.

Then again, “official standards” are just a group of people who have made things up and have agreed to stamp the label of “official” on their work; it’s still a social construct that depends on how many other people agree with them. (I can make something an “official” standard according to Mel, but if nobody else agrees with me, my standard is useless.)

Anyway, I’m not sure if that qualifies CSV as “open,” but it’s certainly not “closed.” To me, CSV is just as open as whatever underlying plaintext (.txt) format it’s using. But again, I’m not a lawyer, don’t work for the FSF, etc. This is just one hacker’s opinion, and I’d love to hear what others think.

From Debbie Chachra: what I want to tell my future research students when they start

Debbie Chachra’s newsletter described what she told undergrad summer researchers in engineering education about their work today, weight loss and it struck me deep as someone who’s been an open source newbie and a perplexed undergrad researcher — and then grown into the sort of person that (terrifyingly!) is in the position to mentor both.

[Undergrad summer research] is not a job; the money they get is a stipend, pestilence not a salary. Its purpose is to carve out the space and time for them to participate in the program, surgeon not to pay them for the work they do… The reason why they get stipends and not salaries is twofold: one, because the summer is intended to be a learning experience above all, and two, because it’s basically impossible to do research to order. You can be directed to do specific research-related tasks, but actually exploring an area, being engaged, and coming up with insights is not something you can turn into a checklist, not least because if you could do that, it wouldn’t be research.

Research can pretty much only be done by people who are intrinsically motivated; that is, interested in and committed to what they’re doing, and not just doing it because they have to. Most of the students have had jobs and all of them are familiar with doing assignments for class; none of them have had an experience like this. So start by trying to get this across to the students: “You are not minions. You are not workers. You are not robots. You’re going to bring your whole heart and mind to what you do.”

This has been my failing — in both roles — many times. As a newcomer to open source and research, I showed up and expected… a job. That’s how you earned your stripes, right? That’s how you showed humility, and willingness to learn… you had to pay your dues. It’s what I had always been taught. And so I showed up in OLPC’s IRC channel and asked Jim Gettys to tell me what to do. I followed SJ Klein around the office like a puppy, beamed gratefully when Chris Ball gave me something to do. I sat in Cynthia Breazeal’s lab waiting for Cory Kidd to tell me… something. Waiting for orders.

It took a long time for me to realize that all these people were waiting for me. I didn’t know they wanted me — I thought they wanted my interchangeable labor-functionality. But no, they were waiting for an idea I didn’t know I was supposed to originate. How could I have known this was the culture, the expectation? I’d never been in a FOSS project before, never been in a lab — my family had never experienced these things. I’d never witnessed a student interacting with a hacker or a researcher. I had the “try things, make them happen!” paradigm, but only in my schools — I thought it was a thing you could do only in those special spaces like IMSA or Olin. I hadn’t been in schools like that quite long enough for that worldview to sink deeply enough into my marrow that it would transfer into all the spaces I would ever walk into.

Then I got a little older, a little more experienced. Failed a lot, learned from it — learned enough that others started seeing me as someone who could teach them. And I tried to impart this worldview shift of “you are not a robot,” but — as we often do when we are tired and under-resourced, I fell back into my habits. I would tell people what to do; I would scaffold a bit too tightly, I would… set expectations. When there’s no room to fail, there’s also no room to fly. I failed my way into becoming a better teacher, a better research supervisor, a better mentor of hackers, time and time again.

When we teachers think about the people who have taught us how to teach, we usually think about our own good teachers. I also think about the students who graciously allowed me to fail them, and stuck around long enough to keep loving me through learning how to be a better mentor to them. I am trying to make my learning worthy of the cost they had to pay for me to grow.

On the diversity-readiness of STEM environments: “It’s almost as if I could only enter the makerspace as a janitor.”

My thoughts from an online discussion with other female Olin engineers on this NYT article on “how to attract female enginers, women’s health “, edited for context. In particular, we brought up the (well-worn) claim that women don’t want to “just focus on the tech stuff” and want to “do sociotechnical/humanitarian work that makes a difference in the world.”

I’ve built my career as a “technical community person” who “thinks beyond the technology,” and as a teacher and researcher of learning environments — so this may come as a surprise to people who know and have worked with me. But if my teenage self had had her way, I would have VASTLY preferred to “just focus on the tech stuff.”

As a kid, I wanted to choose the privilege of being oblivious and keeping my head down and immersing myself into the beauty — the sheer beauty! — and joy of STEM for STEM’s sake. I didn’t become an ECE to work on educational computers or hearing aids or anything like that. As my friend (and former roommate) Kristen Dorsey said, “I just geek out about nerdy stuff, OK?”

But I couldn’t “just geek out about nerdy stuff.” The environments where I was trying to “learn about nerdy stuff” were sociotechnically 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 even start being part of the technical community, I had to start by fixing the technical community — patching the roof and fixing the plumbing, so to speak — before I could even walk inside and start to live there. And when I patched the leaking roof, I patched the roof for everyone, and other people who needed non-leaky roofs to be in the community could now… be in the community as well!

For instance, I got really, really good at facilitating meetings because it was the only way I had to make meetings accessible to me — when other people facilitated meetings, they’d often forget I need to lipread, so… I just quietly started leading them myself, and ended up making meetings work better for everyone. And I found that when I drifted towards “humanitarian” projects, the people there were much more conscious of sociotechnical things and more likely to have already-healthy environments, so I would have less leaky roofs to patch, and less resistance when I tried to patch the roofs — and people actually recognized and valued roof-patching labor instead of looking down on me for not writing code full-time.

After a while of patching roofs and unclogging toilets and plastering the rotten drywall, I got a reputation in industry for being really, really good at open-source software/hardware (technical) community facilitation. It’s almost as if I could only enter the makerspace as a janitor. And part of me resented that, but never said so. But, I told myself, at least I was in the building. And I saw that my “janitorial” work made it possible for other people to enter the building and do the things they wanted to do — which were often the things I wanted to do, too! — and so I thought: okay. That’s okay. At least somebody gets to do it. I can see my gift to the community doing so much good, that I will give up my desire to learn and do the technical things — so I let my own STEM learning slide. I am good at “community work,” and I did come to genuinely love it, over time.

But if I had the choice, I would have never gone into “community work.” I would have chosen — if I had the choice — to focus on “shiny tech stuff” that… didn’t save the world at all. If my teenage self had had her way, I would not do community-facilitation-anything, I would not be thoughtful about women or minorities or disabilities or any underprivileged group in engineering… I would be oblivious to all my privilege. I’d be a kernel hacker, or an embedded geek, or something “hardcore technical,” Because I could be.

But I didn’t have the wherewithal (or the desire) to shovel all the stuff out of the way that I would have to do in order to do that. If you think of “caring/environmental labor” as a sort of tax some people have to pay in order to get to “learning/doing technical things,” my tax rate has always just been too frickin’ high.

So I have been “the full-time community person who is ridiculously good at tech stuff that she no longer gets to do,” instead of “the technical person who understands and listens to and cares about inclusion and community.” Because I cannot not patch a leaky roof. But I have always wondered what I might have grown up into, if I had learned STEM in an environment that was ready for me — without me having to fix it first.

Unlock challenge: raise $1024 for The Ada Initiative, support women in open tech/culture, and unlock more open-licensed “programming learning styles” material!

Last year, shop I wrote a post asking people to donate to the Ada Initiative and support women in open technology and culture. I said:

We change the world with millions of tiny patches… our world of open technology and culture is built one patch, one line, one edit at a time — and that’s precisely why it’s powerful. It brings billions of tiny, ordinary moments together to transform the world. If we teach it for our code, we can preach it for our giving. If you’d buy me a drink, or treat an open source newcomer to dinner, send that $3-$20 to the Ada Initiative tonight. –August 30, 2013

Why do we need to do this? Well, being a woman in open technology and culture is like riding a bike on a street made for cars, where rain and dirt get kicked into your face, and you are constantly, painfully aware that if you have any sort of collision with a car… the car will win. Yes, this is happening in our world, to our friends and to our colleagues; it’s happened to me personally more times than I care to remember. The farther you are from the straight white male difficulty setting, the rougher the terrain becomes.

And quite honestly, we’re busy. I’m busy. You’re busy. This isn’t our job — we have so many other things to do. I mean, we’re all:

  • remixing music
  • playing with code
  • writing science fiction
  • co-authoring open content articles
  • redesigning user interfaces
  • <insert your favorite open technology and culture activity here>

And guess what? There are so many people who want to join us. So many people who want to help us do all this work, but don’t, because they know that work — the good work — is likely to come with a lot of really, really awful stuff, like this sampling of incidents since last year (trigger warning: EVERYTHING).

The less time women spend dealing with that stuff, the more time they have to help us with our work. And the more people will want to help us with our work. I mean, would you want to accept a job description that included the item “must put up with demeaning harassment and sexual jokes at any time, with no warning, up to 40+ hours per week”?

Making our world a good environment for all sorts of people is, in fact, our job — or at least part of it. The folks at the Ada Initiative have made supporting women in open tech/culture their entire job — supporting it, supporting people who support it, and basically being the equivalent of code maintainers… except instead of code, the patches they’re watching and pushing and nudging are about diversity, inclusion, hospitality, and just plain ol’ recognition of the dignity of human beings.

They want to support you. With better conference environments, training workshops and materials, and really awesome stickers, among many other things. (Did you know that the Ada Initiative was one of the first woman-focused tech organizations to actually say the word “feminism”?)

So please, donate and support them, so they can support you — and me, and all of us — in supporting women in open tech/culture.

Now, my own contribution is a bit… sparse, financially. I’m a grad student earning less than $800 a month, and I’m waiting for my paycheck to come in so I can contribute just a few dollars — but every little bit helps. And there’s another way I can help out: I can bribe you, dear readers, to donate.

Remember that “active vs reflective” learning styles post I wrote in August? Well, there are 3 more: sensing/intuitive, visual/verbal, and global/sequential. I’ve got them all transcribed here and ready to go. And if we reach $1024 in donations to the Ada Initiative under the Learning Styles campaign within the next week, I will release them under a creative-commons license.

What’s more: the first 3 people who donate $128 or more to this campaign and email me their receipt will get a free 1-hour Skype call with me to discuss their personal programming learning styles, and will be featured as case studies on one of those three posts (I’ll link to your website and everything).

Donate to the “learning styles” campaign for The Ada Initiative now!

Welcome to my dissertation: a poststructural perspective on engineering and technology faculty as learners

I’m going to gradually share my dissertation proposal here as I migrate it to github and into LaTeX – I’d love reactions, online comments, ask questions, buy more about etc! The title is “a poststructural perspective on engineering and technology faculty as learners,” which will hopefully make sense after the first 2 paragraphs.

Faculty are learners, too.

We often think of engineering and technology faculty as teachers. As facilitators of student learning, they hold certain philosophies about teaching and learning that shape their interactions in the classroom. However, faculty are also learners themselves, students of the practice of “teaching engineering and technology.” As engineering education researchers concerned with research-to-practice transfer, the ways we think about faculty-as-learners likewise shape the ways we try to impact their practice. Making this thinking more visible within the engineering/technology domain is of interest to engineering and technology faculty members, faculty development professionals, and adult learning researchers.

My dissertation draws on the traditions of cognitive apprenticeship and narrative within engineering education research to explore poststructuralism as one possible perspective on faculty-as-learners. Poststructuralism is a paradigm that constantly seeks a “making-strange” and unsettling of habitual narratives. A poststructural view challenges us to remain in the discomfort of liminal (in-between) spaces where everything is constantly troubled and nothing ever really settles. This study demonstrates a concrete method for engaging faculty members in that liminal space. Through it, I anticipate contributing to our ability to articulate and value faculty explorations in chaotic territories such as large-scale curriculum redesigns, new program formation, and other places where valuable growth occurs but is rarely put into words.

How can we think of faculty as learners?

I will briefly describe several qualities of faculty-as-learners, compare and contrast them to the qualities presented in existing literature, and explore why it may be valuable to make these qualities visible. Note that by comparing and contrasting my approach to other studies, I am not making statements about the relative quality or validity of their work. I am also not saying that these ways of viewing faculty-as-learners are not present in any existing literature. I am simply using differences and similarities to more clearly articulate certain assumptions about faculty-as-learners that are present in this project.

They are situated in the community of practice of teaching their discipline.

The first quality of faculty-as-learners is that they are situated in a community of practice (Wenger, 1999), that of teaching their discipline. By making sense of the activities of other practitioners around them, they develop the skill of reflection-in-action (Scho¨n, 1983) and use this metacognition and self-monitoring to improve their own practice. Existing engineering education change initiatives have used this cognitive apprenticeship (Collins, Brown, & Newman, 1987; Collins, Brown, & Holum, 1991) approach to build Faculty Learning Communities (Cox, 2004) and other communities of practice to encourage rigorous research in engineering education (Streveler, Smith, & Miller, 2005). Understanding faculty as situated and communal learners helps explain the limited success of an “information dissemination” approach (Siddiqui and Adams, 2013) to research-to-practice transfer. If faculty change their teaching practice primarily in response to direct interactions with colleagues (Fincher, Richards, Finlay, Sharp, & Falconer, 2012) and not print materials, it’s no surprise that journal papers continue to go unread (Borrego, Froyd, & Hall, 2010).

They are adult learners.

The second quality of faculty-as-learners is that they are adult learners. They have rich histories of experience to draw upon as well as expectations of agency (Vella, 1997). This quality allows us to portray faculty as narrators, highly capable and interdependent agents who both read and co-author the stories of “how things are done” within their culture. The Disciplinary Commons initiative (Tenenberg & Fincher, 2007), which scaffolds faculty through a dialogic process of creating teaching portfolios for their existing courses, is an exemplar of validating faculty as adult learners. Initiatives that treat faculty as mere empty “buckets” to be filled with “information about teaching,” such as information sessions dedicated to lecturing faculty about why they should not lecture, may have a limited impact because of this epistemological disjoint.

They learn by engaging in liminal experiences.

The third quality of faculty-as-learners is that they often learn by engaging in liminal experiences where their activities do not fall into a cleanly articulable structure, and can therefore be described as poststructural. In fact, the liminal experiences of faculty are often explicitly about dismantling old structures and remaking new ones, such as the founding of a new college (S. Kerns, Miller, & D. Kerns, 2005) or degree program (Katehi et. al., 2004), dramatic overhauls of an existing curriculum (Mentkowski, 2000), or the creation of experimental classes.

The trouble with liminal experiences is that they stand outside the realm of structure, including the structure of validation and reward. Our existing academic system rewards faculty for engaging in liminal spaces for their research, so long as they are able to publish papers about it afterwards. However, the examples listed all impact teaching, a form of scholarship that is underdeveloped and unrecognized (Shulman, 1998), with a correspondingly slow speed of change. Mann’s (1918) calls for engineering educators to improve student retention, make undergraduate workloads reasonable, and increase hands-on training still sound as relevant today as when he wrote his report nearly a century ago. Our calls for transforming engineering education (National Academy of Engineering, 2005; Institute of Medicine, National Academy of Sciences, & National Academy of Engineering, 2007; McKenna, 2011) will similarly go unheeded unless we find ways to understand and articulate the ways faculty learn and work in these liminal spaces.

Research question

By having engineering and technology faculty work with their stories of liminal experiences, this study addresses the following research question: How can the interacting narratives of engineering and technology faculty inform our understanding of faculty as learners?

Want to give Mel homework? Help me think of a visualization term project.

I’m taking my last (required) engineering course as a student this semester. It’s a course on visualization based taught by David Ebert and Abish Malik. Basically, dysentery  I’ll get credit for using my computer to make pretty pictures based on giant datasets. Shiny! It’s also my first-ever engineering course with an interpreter (Laurie), more about and I’m sucking up new technical ASL vocabulary like a sponge; this semester is unexpectedly full of opportunities to practice my signing. Double-shiny.

I’ve got to start thinking of a term project, and so far I have a few main ideas — but others are welcome, along with brainstorms on how to flesh them out. If I can get a firm idea before Sep 30, I can prototype an entry for the NSF visualization challenge. Project requirements are here, and my ideas so far are:

A dashboard for Hacker Schoolers which would track metrics of interest based on what people consider relevant to their “becoming a better programmer.” Particularly interesting, I think, might be a visualization for Hacker School facilitators – what ways can we use already public data to give them an overview of what many people are doing at once, with the ability to zoom in, compare, etc. as they want? However, I don’t have a clear vision as to what this might look like, so feature ideas/requests are welcome.

Visual ways to navigate intertwined narrative text for my dissertation, which involves people telling stories in response to other people’s stories (and then the original storytellers tell new stories in response to those responses… so they’re intricately tangled up).

Complex symphonic music as experienced with hearing loss, hearing aids, and cochlear implants. My interest in this area is pretty obvious, but this now seems like the most boring project of the three — I could be wrong, though!

Help me brainstorm, intarbrainz!

In other news: today’s class was mainly adminstrivia and an overview of visualization, which is one of many ways to (literally) “make things visible” — converting numerical, abstract data into a graphical representation. For visual learners (like myself), this is effectively translating into our native mental file format. For practically everyone, visualization frees up much of the cognition involved in processing massive amounts of numerical data, allowing us to use higher-level brain functions to ask and analyze interesting questions (I’d heard this before), and making us more confident in our decisions (I hadn’t heard this before). Some fun viz examples include Chris Harrison’s visualization of Biblical cross-references and a map of the US colored by distance to the nearest McDonald’s.

And with that, I’m off to my next meeting. It’s amazing how much more energetic and happy and just plain kind I am when I don’t pretend I’m hearing — telling people I’m deaf, having accessibility in my classes… even my brother noticed it (“You’re less grumpy with your hearing aids,” said Jason in the minivan last month).