Tag Archives: community

Writeup

One of the hardest things about speaking at a conference (beyond getting over anxiety, a fear of public speaking, and imposter syndrome) is doing a write up about the conference and, more specifically, your talk. You want to provide a useful summary of your thesis, some details, and maybe a joke or two to convince people that they should watch your talk. Post-conference video views are important: you can beat your friends by having more views or judge your self-worth by how many people responded positively to your presentation–or both!

I was talking with Spencer Krum (credit where credit is due) about these problems. Presented below is a slightly less late-night, post-dinner-lull inspired solution than the one we originally came up with.

I’ve found that when I’ve needed content from people, it was extremely effective to give out surveys or conduct interviews using a set of questions designed to touch on the major important points.

By the end of the conversation, we agreed that conferences should send you a post-talk survey (as opposed or in addition to a pre-conference interview). Filling out this survey would give you a basis for a blogpost, and the conference a little more content for their blog. In theory, you would get this along with a link for the video to your talk.

Here are some ideas I had about what would make some good questions.

  1. Talk Title
  2. Organization or project represented in the talk or at the event
  3. Conference presented at, including year and location
  4. What was the thesis of your talk?
  5. Why did you want to present this talk? Why this conference was a good venue, or why was it relevant to the audience?
  6. Do you have an outline of important points? What do you think are the most important takeaways–either big ideas or details–from this talk?
  7. What do you want people who attended the presentation to understand or walk away with, that they might not have known before?
  8. Did you get any great questions or valuable feedback?
  9. Did you learn anything in preparing or presenting?
  10. Would you be interested  in giving the same or a similar presentation at another event in the future?
  11. Is there anything else you think is super important to know about your talk?

Some of these questions are kind of similar (4, 6, and 7), but I think they can help you think about the content of your talk in different ways, in order to create a more in-depth understanding of what was important.

I’m going to try and go back to the talk Deb and I gave at HOPE and see what I can come up with using these questions.

(FS) Purpose

Emacs is a text editor used for everything from editing text to writing code to organizing one’s entire life. It’s an older piece of software–originally written in 1976. It’s strength comes from extensibility–you can make emacs do whatever you want if you have the patience, time, and skills. Another way to word this is that it’s super crunchy and hard to use. It’s hard to save files, it’s hard to copy and paste, and it’s hard to become involved. One emacs hacker/user I know said:

…for social and technical reasons contributing to the project is hard and some people view this as a good thing and that’s really shitty.

My criticisms of FLOSS projects have a lot to do with difficulties in install processes, usability, and accessibility (a11y). Inaccessible software is bad. Software that is hard to use is bad. Software that is hard to install is bad.

(I will note that, from this perspective, all text editors are bad.)

Thinking about free software development and usability from a business perspective begs up the question: What does the customer want? The customer for a community is a contributor–the customer for an application, operating system, package is the person installing it. Looking at emacs as a case study, I recently found myself asking if it needs to be accessible and easy. I am not the natural user for emacs. I don’t use it now. Why is it important for it to cater to my needs?

Being able to code is important. So is being able to change a flat tire, swim, sharpen a kitchen knife, unclog a toilet, and understand the basics of how your hot water heater works so that if the pilot light ever goes out, you know what to do or at least how to figure out why your shower is cold.

Initiatives like Hour of Code are important because computers need to be normalized. Not everyone needs to be a developer, but everyone does need to know the basics of how computers work. It is not–and should not–be acceptable to say (with pride even) that you don’t know how computers work, what code is like.

It is not the job of emacs and the community to make sure I can use it to code–or use it at all. However, it should be the imperative of the community to make sure I know and understand the fundamentals of technology–this includes the basics of how computers actually do things. From a perspective of self-preservation, keeping technology in a black box is useful to the technical. As long as computers are not only difficult, but also scary, I need them. But, the fact is, I am going to need them anyway because I do not want to become an expert. I’d rather be an expert at growing delicious peppers, making an asplenium flourish, and identifying trees by their smell.

Technologists and hackers have made their way to where they are, in some cases, through trials by fire. They have fought against communities, proven themselves, and hacked their way through impenetrable code and processes in order to become a member of the club. They should have the tools they want. They should be able to have fun and be kind of elitist in their in-group the same way I should be allowed to have fun and be kind of elitist about building a bike, knowing Hume, and having a favorite designer in any given season of Project Runway. But, none of those things should be scary. The mentality that a project being hard is a good thing is not just mean, but detrimental and dangerous.