New in June 2016

May. 30th, 2016 03:22 pm
[syndicated profile] kirkus_ya_feed
I’m going to go ahead and gloss right over how quickly summer has gotten here, and how quickly I suspect it’s going to go by. Let’s focus on more cheerful things, like some of the June releases I’m waiting for!
[syndicated profile] alaskanlibrarian_feed

Posted by Daniel Cornwall

“Throw them all out!” seems to be theme of this year, whether you’re speaking of the Alaska Legislature of Congress.  People of all political persuasions are upset with the pace and actions of our legislative bodies. And so in frustration cry out for a clean sweep.

There’s no way that we as a State or a Nation can do this. Legislators and members of the US House are elected by district. US Senators are elected by States. So there is no instrument at hand that “we” can throw “them” all out. It sounds good, but in the end, all we have voting influence over is OUR legislators, our US Representative and our US Senator.

I think we would be better served at placing our anger and frustration with legislative bodies aside and really have a laser focus on the people we can actually vote for and against. Two actions within our power are monitoring our representatives as best we can and ensuring there is always an alternative.

Monitoring your representatives

The most important reason for paying attention to your state and federal representatives is that you might find you actually support what they do. Or you can become more articulate about exactly what you’re opposing.

The first step in monitoring your elected representatives is to find out who they are. Here are some places to get you started:

To use me as an example, here are my elected representatives, compiled from the Alaska Legislature and the federal links above:

State Representative (House District 33) – Sam Kito III (D)

State Senator (Senate District Q) – Dennis Egan (D)

I knew who my state representatives were before writing this post. If you live in Alaska, you’ll need to go to the bottom of the Legislature’s home page and search the box labeled “Who Represents Me?”

US Representative – Don Young (R) (Alaska has so few people, we only have one US Rep for the whole state.)

US Senators – Dan Sullivan (R) and Lisa Murkowski (R)

Now that you know who they are, visit their pages. Check out their press releases. In Congress and in most states, you can get a list of bills they sponsored. Are you on social media? Many elected reps have Twitter and Facebook accounts. Follow them. With your US Representatives and Senators, you can use Congress.gov to sign up for alerts of their activities.

Do you like what you see? Keep them and tell them. Don’t like? Tell them. In private and in social media. Be respectful – few people listen when they’re insulted. If they don’t listen (and some won’t), explore alternatives. If you can’t picture yourself voting for the other party, find who’s challenging your rep or senator in the primaries. If there’s no one, consider running even though you’d be a long shot. Uncontested means automatic victory.

One last thought is to treat candidates as individuals rather than as party avatars. Maybe that Republican is a bit more liberal than you thought – or you agree on an important issue. Maybe that Democrat is actually an NRA member. Look beyond the label to the person and see if you can support that person. You can always vote against them in the next election.

Ensuring there is always an alternative

Were you aware that many Alaska House and Senate seats go uncontested? Some US House and Senate seats go uncontested as well. What I mean by this is that the incumbent faces no one in their party primary. Then they win the general election by default because the other party did not run a candidate.

While having an alternative in either the primary or general election is no guarantee that your member will be turned out of office, not having anyone run is a guarantee their incumbency will continue. If you can’t find someone else to run, consider running yourself.

The requirements to file as a candidate vary by state. You should find your local election office and go from there. If you are looking for a party home, check out this list of parties from politics1 or google your favorite party name. If you have the inclination and time, consider joining your local party organization.

 

References

Ballotpedia, Alaska Senate – https://ballotpedia.org/Alaska_State_Senate_elections,_2016

Ballotpedia, Alaska House – https://ballotpedia.org/Alaska_House_of_Representatives_elections,_2016

 


Filed under: politics

Reading Aloud in the Classroom

May. 27th, 2016 05:10 am
[syndicated profile] kirkus_kidlit_feed
It’s the end of the school year here in the South. My children came home this week with a stack of folders, as they do annually at this time. My youngest, who just wrapped up fourth grade, showed me her writing folder. As I was looking through it, I saw an essay she was assigned earlier this year, “My Favorite Teacher.” She chose to write about a teacher she had last year, and here’s part of what she wrote:

Taking Flight with Faith Ringgold

May. 26th, 2016 05:16 am
[syndicated profile] kirkus_kidlit_feed
Twenty-five years ago, Faith Ringgold brought readers her debut picture book, Tar Beach, which won a 1992 Caldecott Honor and the Coretta Scott King Award for illustration. Tar Beach was originally a story quilt Ringgold had created, one that combined autobiography with fiction and transcended art forms—storytelling, quilting, and painting, all in one. (You can see the quilt here at the Guggenheim’s site.)7 Imp_Tar Beach
[syndicated profile] w3c_dpub_ig_feed

Posted by Ivan Herman

See minutes online for a more detailed record of the discussions. (The headers below link into the relevant sections of the minutes.)

IDPF/W3C Plans

There was an announcement on the exploration of W3C and IDPF joining forces; this was discussed a bit on the call. Nick reported on a mailing list discussion, and the main question there was what the impact would be on publishing. There were some concerns around the messaging, on how these things have been decided, etc. Karen also reported on an article on CNET.

Ivan raised the issue that the current messaging does not emphasize enough the importance of the use case document that the IG is planning, and also emphasizing that the current PWP document is not necessarily a done deal as it is; the use case evolution may modify it greatly. Finally, Dave raised the issue that there were many discussions leading up to the announcement that was done in closed fora, and the final decision process should be made more in the public. The group also wondered about the possibility for further public discussions around this, including a possible Webinar.

Web Platform WG topics

Charles McCathieNeville (“chaals”), co-chair of the Web Platform WG at W3C, was the guest of the call to discuss some areas of common interest.

Packaging/Manifests

There is a work item in the WPWG on packaging but, at this moment, there are no real takers. Packaging is obviously of interest for the publishing community, and the question arose whether this community wants to push the current approach. The fact is that most browsers have an extension that uses zip and a manifest; i.e., that approach would get some traction, as opposed to the current proposal.

During the discussion it came to the fore that publishers currently use zip+manifest, although the current formats for manifests, as well as the specificities on zip usage, are not very Web friendly. But there is already work going on (in the IDPF EPUB WG) to update the manifest, a JSON approach, which is the current line at W3C (see the Web App Manifest, is probably o.k. for the Publishing Industry on long term. That being said, it is not clear how the current Web App Manifest can be extended for a particular community.

It has been agreed that the DPUB IG would submit issues or comments on the manifest as well as the packaging work to make its position clear.

Service Workers

The current work on PWP relies on concepts that calls for a tool like Service Workers. Dave has already experimented with this, but questions arose about the longevity of the Service Worker spec, and whether it is really something the community can rely on. It seems that Service Workers are indeed here to say, although the first implementations will probably not be optimal. But it is a safe bet to use them. (See also caniuse entries on it: Mozilla and Chrome already ship it, Microsoft has expressed interest. Not clear about Safari.)

HTML Extensions, Custom Elements (eg, the element)

Lately there were lots of discussion on the re-introduction of the element, that would certainly be of interest for the Publishing Community. What is needed today is to have clear usage data through an implementation. It was emphasized that “implementation” does not necessarily mean one of the browsers; if an EPUB reading system implemented it and used it, this would constitute a good proof of usage.

On a more general level, the issue of HTML Extensions, in particular Custom Elements, came to the fore, as well as the general approach for extensions. For Custom Elements, although it is only supported in Chrome/Opera at this point, the plan is to go ahead and others will also implement it; more generally, the approach using discussions in the HTML Incubator was emphasized as a means to bring new features into HTML.

It was agreed to have these types of meetings with the WPWG more often…

Genderbent Sherlock Holmes

May. 23rd, 2016 03:35 pm
[syndicated profile] kirkus_ya_feed
True to my usual always-on-the-cutting-edge form, four years after it launched, I have finally started watching Elementary. I’d been putting it off because I enjoy Sherlock so much and mistakenly assumed that there was only room for one version of Holmes and Watson in my heart at once. After watching the first five episodes in one sitting, I can admit that, yes, I was entirely, without a doubt, wrong!*
[syndicated profile] sumana_feed
Conversation the last night of OSCON, reconstructed from memory:
"So, Neil Young --"
"The singer-songwriter?"
"Yeah."
"Man, what a white guy name."
"Are you impugning Neil Young? That man sells organic eggs at the farmer's market in my hometown!"
"Are you sure they're organic? You sure he doesn't just get them from Sysco?"
"Sysco doesn't even sell organic eggs."
"Uh, actually Sysco does sell organic eggs."
"Yeah right. I bet it's, like, orgänic, with an umlaut, so it can get around the FDA rules on calling things 'organic'."
"Yeah, and that's also how they get around the rules on Appellation Contrôlée."
"Anyway, Neil Young has a son who really likes model trains, and so he does model train stuff, and he actually has multiple patents related to model trains."
"Patents? Is he part of the Open Invention Network? Is this a defensive patent portfolio against Big Train?"
"You mean Supertrain?"











picture of Sumana in front of a steam train in Melbourne, AustraliaIn honor of late-night wackiness, I have not actually fact-checked whether Neil Young has any model train patents, or whether he or Sysco sell organic eggs. Caveat lector et caveat emptor.

My last visit to OSCON was in 2011, when I had worked for the Wikimedia Foundation for under a year, and wanted to build and strengthen relationships with the MediaWiki and PHP communities. I remember not feeling very successful, and thinking that this was a conference where executives and engineers (who in many cases are not terribly emotionally passionate about open source) meet to hire, get hired, and sell each other things.

These days, it turns out, OSCON is basically aimed at me! Because I am an executive trying to sell my services (e.g. get hired on an as-needed basis) to engineers and executives who make or depend on open source -- including the passionate ideologues, the burned-out used-to-be-passionate folks, the pragmatists, and all manner of other types. Changeset Consulting was novel, relevant, and interesting to approximately everyone I spoke with. Also, in the intervening five years, I've grown in skill, stature, reputation, and network. So I had something interesting to say, and O'Reilly accepted a talk proposal of mine for the first time. I saw scores of acquaintances, friends, peers, and colleagues in the halls and session rooms this year; I know and am known, which helps me feel at home.

I'm grateful to Audra Montenegro at O'Reilly Media for her speaker support. She worked with O'Reilly to cover my flight plus two hotel nights in Austin, making it possible for me to attend OSCON. She and other O'Reilly folks paid and worked with White Coat Captioning to provide CART (live captions) for my talk, at my request. And I was concerned that talking about inessential weirdnesses and inclusivity in open source upped my risk of harassment, so she arranged for some extra security for me. I'm also grateful to Andy Oram, my session chair, for his careful pre-conference prep (including checking on my pronouns -- she/her, thanks!), and for running a written Q&A session at my request.

I shall carry with me several memories of this OSCON, such as:

  • Breaking the no-electronics rule of the quiet room/relaxation lounge (since I was the only one using it) to finish revising my talk and blog about good code review
  • Staying with some lovely relatives in the suburbs for a few days and drinking spinach juice with them each morning (my uncle is in charge of making it, and sometimes he adds grape or orange juice, and sometimes something else, and sometimes it's just spinach. It's a surprise. "Every day's a new day," he said to me)
  • Helping my high schooler cousin revise a skit, and deploying my stand-up comedy wisdom, e.g., use over-the-top worshipful admiration as a kinder substitute for straight-up mockery
  • Being the only person in the pool at the Software Freedom Conservancy party (foolish choice on my part; it was pretty cold)
  • Meditating on a loved one during an exercise in Cate Huston's talk on technical interviewing, and feeling the lovingkindness throughout the whole room
  • Listening to an enthralling performance by rapper Sammus
  • Discussing pull request workflow, Contributor Licensing Agreements, the engagement funnel, the future of OpenHatch and of Apache Zookeeper, the failings of Google Summer of Code, whether GitHub should allow no-license repositories, how Facebook/Amazon/Google's idiosyncrasies come out in their open source work, performing femininity in the workplace, productivity and routines, effectively signalling to one's employees that they should not work on weekends, what maintainership is, JavaScript and data binding, and BLESS
  • Becoming increasingly convinced that continuous integration/continuous delivery is hitting an inflection point that source control hit several years ago, i.e., soon it will be a must-have for software-making communities and not having it will be embarrassing
  • Chatting with OSCON acquaintances in an Austin hotel lobby and being interrupted by a drunk white woman who called me "Mindy Lahiri" (a fictional character from The Mindy Project)
  • Opting out of the millimeter-wave scanner at the Austin airport and witnessing a person wearing an EFF shirt not opt out!

But here's a conversation that I particularly find stays with me. I was on the expo floor, talking with an acquaintance, and a stranger joined our conversation. I'll anonymize this recollection and call him Cyclopes.

He heard about the consulting services I offer, which focus on short-term project management and release management for open source projects and for companies that depend on them -- maintainership-as-a-service, in short.

Cyclopes: "Can you come to my company and tell us that the way we're doing deployments is all wrong, and tell them we should do it my way?"
Sumana: "Well, if your company hires me, and I assess how you're doing deployments and I think it's wrong, and I agree with the approach you want, then yes."
Cyclopes: "Great!" [explains his preferred deployment workflow, with justification, and says that it's like bashing his head against a brick wall for him to try to convince the rest of his company to do it]
Sumana: [lightheartedly] "So it sounds like what you really want is more a sockpuppet or an actor! Which might be cheaper!"
Cyclopes: "Hmmmm! You know, that is kind of what I want!"
[we three jest about this]
Sumana: "But, in all seriousness, like, you could go aboveboard with this. You know, you have options -- fraud and deception, or actually trying to persuade the other people in your org .... or, this is a wild guess, have you kind of burned bridges by being really abrasive, and now they won't listen to you?"
Cyclopes: "Yeaaaaaaaaah that might be what's happened."
Sumana: "OK! That totally happens and you weren't the first and you won't be the last."
Cyclopes: "Like, I've sent some pretty flame-y emails."
[acquaintance nods in sad agreement; we are all sinners here]
Sumana: "Oh man, the emails I've sent. I am so embarrassed when I look back. But you can come back from this. You really can. If you demonstrate to those people in your org that you really want to repair those relationships with them, they will respond. Like, if you say to them, 'I know I burned bridges before, I'm sorry about it, can we talk about this problem,' and you actually try to listen to them about what they need and what their context is, what they're worried about and what problems they're trying to solve, they will work with you, so you can figure out something that works for everybody. There's a book about this, about negotiation, that's a really short, quick read, it helped me a lot: Getting to Yes by Fisher and Ury."
Cyclopes: "Let me write this down." [notes book title and author on the back of my business card]
Sumana: "There you go, some free consulting for you. It's totally possible."
Cyclopes: "I think I could use that, I'm ripe for that kind of personal transformation in my life."
Sumana: "Great! Please, seriously, let me know how it works out."














Memory is unreliable, but I cannot forget the speed of my diagnosis, nor that this guy literally said that he was ripe for the kind of personal transformation I was prescribing. It's no model train patent but I think I'm happy anyway.

[syndicated profile] sumana_feed
"Inessential Weirdnesses in Open Source Software": written version of a speech I delivered at the OSCON conference, Wednesday, 18 May, 2016, Austin, Texas. O'Reilly will be posting the video behind a paywall sometime in June 2016.

Introduction

me smiling at cameraHi there. I'm Sumana Harihareswara and I'm going to speak with you about "inessential weirdnesses in open source software".

You can't be all things to all people. [pause]

We would be making more and better software, and empowering more people, if we got and kept more people, who have different strengths. [pause]

This is a contradiction. It is. The ways we do things right now, in open source, are really good at some things and bad at others. We are good at using some people's strengths and bad at using others. And if we want to get better at that, we need to reduce the barriers to entry, and I'm going to talk about how to do that. But we also need to watch out, so we don't accidentally get rid of the values and the habits we're really uniquely good at, the things we care about, that we should keep. There are people who really love open source culture the way it is now, who feel safe and loved and comfortable here, and that is great. We absolutely deserve to feel safe and loved. But I think there are some changes we can make so that even more people can also feel safe and loved here -- it's additive, it's not about replacement, it's saying, let's invite these people to the party too, and make sure they can have a good time once they get here. We can all work together, and complement each other's strengths.

That's the heart of what I'm going to talk about today, so you can look at your own project and think about where you want to add another interface to your community, so you can be more hospitable to new potential colleagues.

Housekeeping

Just some housekeeping to start: I am not using any slides today; instead we have CART, Computer-Assisted Realtime Translation. A person is transcribing the words I'm saying. Stacey. Thank you, Stacey. I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk. I'll be posting my notes online later today.

And there are other good talks happening right now, so to help you decide whether to stay in this room: this talk is going to be more interesting to people who already have been participants in open source software for a few years, who can use tools we commonly use in our community, like version control, IRC, mailing lists, bug trackers, and wikis, and who are already familiar with general open source software trends and arguments. And this talk is going to be most interesting to people who regularly spend time working to help reach out to new people and get them to use open source software and participate in our communities. So if that is not you then right now, check out the other talks, like "Making awesome things accessible", "I am your user. Why do you hate me?" or "Managing while Black".

"Inessential Weirdness"

OSCON 2016 So the title of this talk is "inessential weirdnesses in open source" -- and this phrase comes from the article "It's not 'them' -- it's us!" by activist Betsy Leondar-Wright. There'll be a link to this article in the notes I put online. The basic idea is, if you look at your own community with the eyes of an outsider, look at it from the perspective of a specific group of people you'd like to recruit, what do you think might discourage them or make them uncomfortable? Those are what we'll call "weirdnesses." And you get to decide, your community gets to decide, which weirdnesses are essential, and which ones, in Betsy Leondar-Wright's words, are inessential, meaning you should offer a workaround for them, or even try to change them.

Leondar-Wright suggests that there are a few classes of essential weirdnesses. There are weirdnesses that come out of our shared core values -- as she puts it, they "couldn't be eliminated without doing a deep injustice to someone". So, for us, that would include stuff like releasing our code in public. There are people who have a hard time with that. There was one coder I tried to help, because she wanted to get into open source, and she just choked, and could not start contributing to our community, because no matter how much handholding or guidance I gave, she was just too afraid to make commits in public. But that's inherent to open source. We can't make that one chunk of the codebase private so people can never see it, that would be against our values and also just logistically it wouldn't work.

Leondar-Wright also points out that some essential weirdnesses are "personal differences that may seem weird to others but are very important to the individual" (for example, choosing not to drink alcohol even though everyone around you is). I would argue that this is also a reflection of our values. We respect people's choice to abstain from alcohol because we value personal autonomy and bodily consent.

But "it's rarely essential to impose one's personal choices on others".

I've run into trouble using this term, because the word "inessential", to some people, implies that something has no value, or that it's harmful and we should get rid of it. No. It's more like a heads-up, that here's a place where you could build out some new API client libraries, in more languages, have more interfaces, so more people can interoperate with you.

I'm going to quote an anecdote from Betsy Leondar-Wright's article:

A few years ago, I listened to week-by-week reports from a radical working-class friend who tried to join a [group fighting corporate globalization]. He told me of snide comments about his fast food; elaborate group process that took hours and hours; insistence that everyone "perform" by answering a certain question at the beginning of the meeting; uniformly scruffy clothes that made his pressed shirts stand out; potlucks that were all tofu and whole grains; long ideological debates over side issues; and an impenetrable fog of acronyms and jargon. He soon quit in disgust. I wonder if the group members understood why he left.

For professional-middle-class progressive activists like myself, it's easy to understand why working-class people would be alienated by the mainstream culture of well-off people. After all, we tend to be alienated by it ourselves, because it represents values we've rejected, like greed and materialism. But the idea that working-class people would have any negative reactions to our own subculture, in particular our values-based 'alternative' norms, tends not to occur to us.

I read that and I thought about times I've seen new people in open source having a bad time, because of something that has nothing to do with our core values, nothing to do with transparency and freedom and helping your neighbor. But because someone was mean to them because they use Windows, or they feel pretty alone and isolated because of our communication norms, or they had a tough time getting started with Git, because it's really hard to get started with Git.

And am I saying "let's get rid of Git"? No! I'm saying, if someone wants to get started in open source, maybe Git isn't the very first thing I want to teach them. Maybe I accept that right now they're on Windows. You gotta meet people where they're at.

That progressive activist group that Betsy Leondar-Wright's friend tried to join -- it sounds like they were basically a working group full of experts who had process and jargon and habits that worked well for them. And we have specialized process and jargon and habits that work well for us, when it's all experts together. I think one of the hardest things to do is for experts to look at a culture that's working for us and figure out what scaffolding we can offer so new people can come in and become experts too. Researchers Stuart and Hubert Dreyfus actually talked about this problem in 1980, in their Dreyfus Model of Skill Acquisition -- when you go from novice to expert, you don't just learn a bunch of new facts. The way you look at the world changes, you're making decisions on a new analytical level, you have a whole new perspective. And it's really hard for you to empathize with people who don't have this skill, who haven't learned the judgment and the reflexes that you have. [See Mel Chua's talk slides on education psychology for more on this.] This is one reason writing documentation is so hard. [Here, despite the bright lights, I saw one audience member nod, and that made me happy.]

So today I'll be talking about some few examples, bits of our subculture, the open source software subculture, that routinely alienate new people. And I'll give my thoughts on how to discern the bits that are important, that we shouldn't ever give up because they're key to our values, from stuff where we can offer workarounds when we're doing outreach events and creating online spaces for newcomers -- those are the bits that Betsy Leondar-Wright calls "inessential weirdnesses". Then I'll explain how you can better recognize and fix these kinds of snags in your own outreach work. My hope is that after today's talk you'll be more effective and you'll help make outreach experiences more hospitable and thus more effective.

[Now: three stories.]

Contempt

My first story today is Aurynn Shaw's story about realizing that hating on Windows and PHP has real costs. She writes in "Contempt Culture":

...when I started programming in 2001, it was du jour in the communities I participated in to be highly critical of other languages. Other languages sucked, the people using them were losers or stupid, if they would just use a real language, such as the one we used, everything would just be better.

Right?

This sort of culturally-encoded language was really prevalent around condemning PHP and Java. Developers in these languages were actively referred to as less competent than developers in the other, more blessed languages.

I do recommend that you read Shaw's essay. She goes into some really worthwhile insights on what this dynamic achieves for the people who participate in it, and whom it excludes.

She writes:

It's 2015, and I saw a presenter at a Python conference make fun of Java. How would that feel to people trying to move from Java into something else? I wouldn't feel welcome, and I'd have learned that the idea that the Python community is welcoming wasn't true.

I'm tired of calling people out again and again for dumping on PHP.

I'm tired of people dumping on Windows, that most popular operating system, because it's not what we choose to use, tired of the fact that we don't make it easy to use our tools and teach them how to move, when they're ready.

As I experienced in most of my community management work in open source software, over and over, I saw how few of our tools and applications make it easy for Windows users to try out open source software. On Windows, installing, for instance, an open source application that depends on Ruby is a big hassle, and might mess up other stuff you're doing that depends on Ruby.

So what is essential here and what is inessential?

Do you yourself have to go get a Windows machine and start writing PHP? No. Of course not. Remember, personal autonomy and choice is essential!

It's essential that we encourage people to move off of proprietary systems, giving them support in the short term with training and help, and in the long term with kick-ass operating systems and applications, and a culture and a political environment that encourages open source software. It's inessential to make people feel bad that they haven't done a really hard transition yet. Activists have known for a long time that if you ask a new potential ally to change their entire life and lifestyle at once, you don't get as many new followers as if you get more doable, with short-term goals that give them immediate benefits.

Syntax

Here's my next example, and it's about language. Now, if you were teaching someone a skill they didn't know before, like woodworking or omelet-making or choral singing, it would make sense for you to teach it in the language they already speak. If they only speak English, teach it to them in English.

Well, every day, we do the opposite of that. We tell people that they have to learn a new language along with the new topic. The topic, the skill, is using open source software, and the language is the command line.

Gus Andrews, who's a usability expert and a Fellow at Simply Secure, has a provocatively titled blog post, "Why the command line is not usable". She discusses how the command line is an environment that requires tremendous cognitive load of new users. She reminds us that recognition is far easier than recall.

Command lines demand that users remember the correct phrase to make the system run, rather than giving them prompts which might help them guess what the system needs them to do next. The overwhelming majority of people alive today have never had the opportunity to learn those commands. Making them look them up and learn them themselves would make them very, very frustrated -- they don't have time for that. GUIs aren't just "shiny": they are tools which help us remember what is possible.

Some users absolutely find the command line a lot more usable and accessible! And I don't discount their experience! But over and over we see that a lot of new users find it really frustrating to get started on the command line.

And this is not just about uneducated users, or users who don't spend that much time with computers. As an example, computer science professor Philip Guo has an essay on his site called "Command Line Bullshittery" where he talks about all the little commands his research students, CS researchers, have to learn in order to get their research done. Stuff like

nohup tar -jxvf giant.tar.bz2 2> cmd.errs &

And he says that as an advisor, one of the things he has to do to keep his students from getting super demoralized is to teach them how to install and configure and use open source software on the command line, which is a really deeply unfriendly experience, and to reassure them that it's "just a necessary upfront tax required to enable them to do the actual interesting research".

And in that piece he distinguishes between incidental and intrinsic complexity.

The fact that it's hard to learn the command line "arises simply because modern research software development is a messy jumble of open-source tools tied together by the duct tape of command-line scripts." It's incidental complexity. It has nothing to do with the intrinsic complexity of CS research, the hard problems that these researchers are trying to investigate.

This underscores that it is just hard to install open source software, often, and get it to a state where it's properly configured and secured, and you can do work with it and import and export data. Recently Bret Davidson and Jason Casden wrote a piece in the code4lib journal, "Beyond Open Source: Evaluating the Community Availability of Software". Their suggestion was: What if you just took a stopwatch and saw how long it took a representative user to install software and do something useful with it? I think for a lot of us, we are aware that this number, for our projects, would be dismally high.

Similarly, when I was at the Wikimedia Foundation, we started the Visual Editor project, which makes it easier to edit Wikipedia articles. Before we started this, we often saw that skilled writers with useful content to contribute would get discouraged, because they knew English, they were web-savvy, they sometimes even knew HTML, but they didn't know this wacky weird markup language, wiki syntax, that no one else in the world used. In fact, sometimes this made them think that they were not allowed to edit -- people would click the Edit link, see this jumble of what looked like source code, and then Back-button right on out of there, for fear that they'd broken something, or that they were about to break something.

And what's worse, when we started introducing the what-you-see-is-what-you-get editor, the Visual Editor, some of the experienced editors pushed back with the argument that the syntax was a gatekeeping measure, that the ability to master this syntax was a really good proxy for whether someone was going to be a good writer and contributor in general. This is pretty nonsensical and has not been borne out as far as I can tell.

So, what is essential here? what is not?

With wikis, it's essential that everyone can edit an article -- that is part of the freedom of free culture. MediaWiki is meant to make it easy to edit. By default, when you set up a new MediaWiki installation, every user can edit every article. We aren't going to add a bunch of different permission and access control layers so that there are fifteen layers of privileges to determine who can edit what page. There's other wiki engines that'll do that, that have different core values, but it's inherent to MediaWiki that we default to freedom.

And that everyone can see every article's history, because that transparency makes everyone a more informed consumer. And there's more, I'm sure. But using the syntax is inessential. It's incidental complexity.

And I would argue that the most essential aspect of the command line is that people are empowered to control their machines and use them the way they want. It's a tool. And it's important that all users have the command line on GNU/Linux available, so they can chain together operations and learn to do development work, if they want, and because there are people who find it a much more accessible experience. But the command line is such a difficult, alienating experience to new users, it's like it gives them unusable freedom. (Hashtag #unusablefreedom .) So, making new users learn the command line in order to use open source software is an inessential weirdness. Having alternatives available, like the rich desktop environments that GNOME and KDE have made and Ubuntu helped make available, is great. As long as all the GUIs are also accessible to screenreaders.

REMINDER: I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk.

Religion

Now another story, and it's actually about a rare failure by one of my favorite conferences. PyCon North America is a yearly community conference about Python. In scheduling PyCon 2014 and 2015, the organizers accidentally scheduled it over Passover, both times. And this means that a nontrivial number of observant Jews couldn't come.

And beyond that, consider how many of our conferences happen over Fridays, Saturdays, and Sundays. If going to a weekly Muslim, Jewish, or Christian religious service is important to somebody, then a weekend conference schedule is going to really crimp their style.

(Now, this is important to balance against the fact that some people can't miss that much work in order to attend a conference. Maybe the best approach is to be aware of who seems to be consistently catered to, what demographics aren't having any trouble showing up, and try to change it up a bit so you have some events, some communication channels, and so on that cater to the people you haven't had as much success in reaching. You can see an example of how I'm doing that in this talk -- I'm using written questions instead of oral Q&A, because it's a way to make some people comfortable who usually don't get to ask questions. And instead of using slides, I suggested we have the live captions, to help people who usually have trouble following a spoken talk.)

I'm not here to try to persuade anyone to join or leave any religion -- I'm a Hindu myself and I'm really grateful that we do not do that here, that in my nearly 20 years in the free software movement no one has tried to convert me. I'm glad our spaces are secular. That is essential to us being open for everyone. But in our aggressive ignorance of religion, and sometimes when we stand by and let anti-religion comments stand without challenging them, we sometimes cause snags for people who want to engage with us.

Sometimes this is in missing opportunities, like partnering with churches, temples, and mosques. Hey, they have communities full of people with free time who are interested in making the world a better place! A lot of them care about privacy from government surveillance, for very good reason! And they have free venues for meetings!

But, again, it's essential to respect people's personal autonomy and freedom. There are people in our communities who have been hurt by religion, been traumatized by religion, who currently face discrimination from religious communities. So of course we have to be mindful of that. So, for instance, if someone in your community isn't going to feel comfortable in a religious space then there's no reason to try to persuade them to do that bit of outreach.

In any case, I'd say that it's an inessential weirdness for us to stand by and allow anti-religious comments in our public spaces. One person who ran an online technical forum mentioned that, in its "off-topic" section, sometimes people said things that were casually sexist or Islamophobic. He said,

"I just kind of rolled my eyes and ignored them. About three years in to running the forum, I incidentally discovered that we had a few closeted women and Muslims in our membership. Suddenly those jokes that were white noise before made me acutely ashamed and I had to update the rules and enforcement to stop those posts going forward. If you had asked me the year before what I thought the community's most serious issues were in expanding and increasing engagement, a 'casual hostility to certain demographics' wasn't even on my radar." -- Matt, Crooked Timber comment thread

More things I wish I could have talked about

I wanted to go into these in depth, so there are topics I mentioned in my abstract that I do think contain inessential weirdnesses but that I don't have time to discuss in depth in this time slot, like open source communication norms, and how our community acts regarding pop music, patriotism, small talk, professional sports, and the primacy of in-person conferences, and the user interface of Git specifically, and assumptions about bandwidth & personal computer quality. I'm happy to discuss any of those during the Q&A or afterwards. This is an incomplete list of examples.

REMINDER: I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk.

Takeaways

me in conversation in speaker's lounge - photo by O'Reilly MediaSo what does this imply for open source software advocates? Now I'm going to talk about some ways to watch out for these problems and reduce the harm they cause.

1. Look for code smells

These are some really rough heuristics to try to find snags that other people are hitting.

Take the same approach that a Software Reliability Engineer would take, and say, any time a user gets hassled or tripped up, that's a symptom of a problem that needs fixing. You treat every downtime, every pager call, as a bug report.

Look out for any advice your project is giving newcomers that has the word "just" in it. I think Greg Wilson calls this the passive-dismissive adverb.

Watch out for any place in your workflow where newcomers have to deal with simultaneous newness on multiple dimensions. Mako Hill has observed that Wikipedia was founded at the same time as a lot of other innovative free knowledge projects, but Wikipedia's the one that thrived and that's still around, because yeah, it was super weird and disorienting and innovative on the workflow level, but the thing it was aiming at, an encyclopedia, that was a vision all the participants understood. ["Almost Wikipedia: What eight early online collaborative encyclopedia projects reveal about the mechanisms of collective action."] You can only innovate on so many levels at the same time. This goes back to that woodworking example at the beginning. People will have a hard time learning a new language while they're also learning to do an entirely new kind of thing.

If you make an application you want people to use, use the Simply Secure guides on doing qualitative UX (user experience) research, such as seeing how users are using your product/application.

And another possibility -- I know this is a wacky idea -- but you can ask. You can reach out to individual people who attended one event and drifted away, and ask them what you could fix to be less unappealing. That doesn't always scale, it's artisanal data, but still, it'll give you some thoughts to work off of.

And having those thoughts, a list of some things to look at, helps with the next step.

2. Realistically assess yourself & your goals

Once you have an inventory of some things about your community that are putting off newcomers, you have some choices to make. What are you really committed to keeping in absolutely all your activities, and what do you think you could stand to tone down when you're trying to talk to newbies?

Discerning essential from inessential means being honest about what your real values are.

So, what are your goals? What are your values? You care about the Four Freedoms and about treating everyone with respect; beyond that, what are you particularly attached to? Who are you trying to reach out to, & what are the gaps between your culture & theirs? I haven't even gone into international, inter-language, and other differences you might want to traverse, but I can recommend classism.org to get some representative thoughts.

"Observe the cultural norms of people you'd like to work with, watch for signs of discomfort, and study what conveys respect and disrespect in their subculture." -- Leondar-Wright

This isn't about completely changing the entire core of your work. If you have a strong cultural practice and you're committed to it, own it but be nonjudgmental -- say "if you want [other approach] consider [other project]".

Acknowledge that different people want different things. And acknowledge that when you negotiate that with people who are different from you, that will probably require conversations, not just writing FAQs that live forever. [See this explanation of the success of the English Wikipedia's "Teahouse" for more on this.]

3. Find easy ways to build bridges

Sometimes you're going to find easy wins, which is great! There are easy add-ons you can do that overcome a barrier.

Some old-school people like Mailman mailing lists. Some new contributors really like web forums. If you upgrade to Mailman 3, you get one thing that acts like both, so everyone's happy!

If you have an IRC channel, you can do what OpenHatch did and have an automated welcome bot. It greets new people and gives them a couple tips, including the names of a few people they could reach out to for help who have been active recently. If you have a Slack, you can make a bot with the Howdy.ai botkit framework to do something similar.

You can use pre-existing playbooks to run events like SpinachCon, so that new folks don't have to learn git or the command line to make their first contribution.

But usually those kinds of easy wins are not the whole story. If you are serious about building coalitions with people who are not like you, you will probably want to:

4. Build and maintain differentiated but connected spaces

Your project can support both experts-only spaces (where jargon and in-group practices are welcome, like really concise speech and Douglas Adams jokes) and mixed-experience spaces (where hospitality is emphasized and legitimate peripheral participation opportunities are available for learning). [Also see Mark Guzdial's and Greg Wilson's posts on this.]

These newcomer-friendly spaces are like tidepools, connected to the ocean, but calmer, where things can germinate in a gentler environment. For you, a tidepool might be a community that publicizes beginner-friendly events, where Windows users who prefer GUIs to command lines are welcome, where new people can make relationships through small talk, where there's an occasional installfest at a church.

This means that you would have to learn to be comfortable explaining, nonjudgmentally, that there are high-jargon spaces and low-jargon spaces, and helping steer conversations to where they ought to be.

These newcomer-friendly events and online spaces probably ought to have agreed-upon rules. Example: the Recurse Center rules (manual) to help everyone feel comfortable saying "I don't understand." And it's probably a good idea to regularly revisit and revise those rules to see if they've lost touch with any of the essential values and weirdnesses that the community needs to preserve.

And this isn't meant to suggest that we should condescend to newer contributors -- just listen to them, and do what it takes to support and encourage them in their open source software journey. Everybody's got something to learn from us and everybody's got something to teach us. So while teaching new learners, yeah, we should err on the side of clarity and listening, and call things by their proper names while also collaborating among people with different perspectives to build a common language -- and a common movement.

5. Acknowledge the costs

"Don't expect you can remain exactly as you are and be a bridge person" -- Leondar-Wright

Engineering is a game of tradeoffs. And yeah, there's a tradeoff here. You are going to reduce the amount of time that the outreach-centric folks spend in the pre-existing expert communities. Let's acknowledge that different spaces are genuinely, irreconcilably different.

Whenever you try out a kind of funnel or ladder that you hope will get you new users, new participants, new collaborators, not all of those people are going to work out. And every one of them who drops out is going to feel like a failure of the new plan. Like, "we spent all this time on making a GUI and negotiating with the local mosque to host a meetup and actually making smalltalk with people, and it's still a grind!" You're going to have demoralizing moments and it's going to feel even harder because you're trying something new that you're not good at yet. Which is where the learning happens.

Leondar-Wright says: "Figure out which of your weirdnesses are essential to you, and drop the inessential ones when you're doing cross-class outreach or coalition building. Be thoughtful about who your group sends to be the emissary to a culturally different group." So, that means that some of the people in your community who are not very good at adapting to other people's cultures should not be doing this work. And if they're trying to do this work and they're not good at it, they need to hear that, and that's a hard conversation to have.

Another cost is the cost of the weirdnesses you decide to keep.

If you decide to hold onto a weirdness, then acknowledge that in your outreach, you'll need to pay the cost of making new people comfortable with it. Develop good explanations and metaphors and help people understand why you've made the choices you've made.

Figure out what needs teaching in a standalone class. For instance: the nonprofit Software Carpentry teaches researchers and scientists of all kinds -- physicists, biologists, sociologists, anybody who has to manage and sort through data to do research -- they teach them basic research computing skills, like version control, the Unix command line, and better programming skills. And the Software Carpentry folks have created these workshops and boot camps, sort of as a coping mechanism for the weirdnesses of Git and the command line.

As a community, it looks like we are sort of doing this with Git by creating learning materials, and by making some workarounds. Look at the GitHub web UI as sort of a costly, unfree mitigation of the horribleness of Git's command-line UI. As with wikis: it's essential, with Git, that everyone can suggest improvements, everyone has access to the whole history, it's possible to search for specific changes or classes of changes. But learning to use the command line and the syntax is just not as essential as a first step.

Conclusion

So here's the tiny plug, which is that, through my firm, Changeset Consulting, I can help you with this -- with contributor outreach and with auditing and assessing and improving your current intake and onboarding process. But no matter whether you hire somebody or ask for volunteer help or do all this work yourself, this is going to be tough, but necessary work, for us to build a mass movement.

As Betsy Leondar-Wright says:

None of this is easy. It's one thing to briefly change ourselves for a job interview or for dinner with the in-laws, but it's painful to have to change ourselves in our own activist groups. But as civil rights activist and Sweet Honey in the Rock founder Bernice Johnson Reagan said about coalitions, "If you're comfortable, you ain't doing no coalescing."

I am asking you to stay safe and loved but to try installing discomfort. Everyone deserves safety. Safety is what makes it possible for us to function. But maybe we could take turns being uncomfortable, so the same people don't always have to be uncomfortable all the time. If you are recruiting for new Google Summer of Code interns, or you're on a newbies-friendly mailing list, and you see a barrier to entry, check whether you're acting like those old-school Wikipedians who thought the Visual Editor was keeping out the riffraff. Ask yourself: "Is this essential to our values, or is it more like adding another way in would make us uncomfortable?"

Just give it a spin. As the Open Source and Feelings Diversity Statement says:

"Sometimes we will need to step out of our comfort zones to make everyone feel welcome. We recognize that privilege is real and that the privileged have more bandwidth to be uncomfortable and help make our space more welcoming."

Thanks to Amy Hanlon, Anne DeCusatis, Leonard Richardson, Denver Gingerich, Betsy Leondar-Wright, Naomi Barrettara, Darius Kazemi, Brendan Adkins, Nick Murphy, Roan Kattouw, Meredith Patterson, Andromeda Yelton, and Kaitlin Thaney for their comments on drafts of this talk, and thank you to Mary Gardiner and Camille Acey for earlier comments on this topic.

Question & Answer

And I'm now ready to answer your written questions. [I received one question.]

Q: Does jargon exist for matters that cannot be understood with preexisting vocabulary?
A: I think the word there is jargon. I think that it's useful to remember that there are -- jargon isn't just about synonyms. It isn't just, you know, we say "quit" or "exit" where somebody else says "end." Jargon isn't just about different words for the same thing. Often one function of jargon is an encapsulated compressed thought that does have dependencies. You can think of trying to reach newbies as a dependency management exercise. How many new concepts and skills are you making them install in order to get to the point where they can do something useful and collaborate with you? And so, I could, you know, if you want some metaphors, I think that's a reasonable one to talk to other coders with. The chunk of thought that this questioner asks about, ideas that cannot be easily expressed or understood with the person's preexisting vocabulary until they learn new words and thoughts, I think "jargon" is a reasonable thing to start there.

Additional note: Thank you to White Coat Captioning for working with O'Reilly Media to provide CART services for this session. I've checked the transcript they provided and improved this post to reflect the question-and-answer session, as well as places where I said something better live than I had scripted for myself to say, and I've included in this post parts of the speech that I did not have time to deliver during my OSCON slot.

This talk is a revision of an earlier talk I delivered at LibrePlanet 2016; in particular, I cut the "small talk" section due to ableism concerns, and may someday expand that chunk of thought into another talk or essay.

[syndicated profile] sumana_feed
"Inessential Weirdnesses in Open Source Software": written version of a speech I delivered at the OSCON conference, Wednesday, 18 May, 2016, Austin, Texas. O'Reilly will be posting the video behind a paywall sometime in June 2016.

Introduction

me smiling at cameraHi there. I'm Sumana Harihareswara and I'm going to speak with you about "inessential weirdnesses in open source software".

You can't be all things to all people. [pause]

We would be making more and better software, and empowering more people, if we got and kept more people, who have different strengths. [pause]

This is a contradiction. It is. The ways we do things right now, in open source, are really good at some things and bad at others. We are good at using some people's strengths and bad at using others. And if we want to get better at that, we need to reduce the barriers to entry, and I'm going to talk about how to do that. But we also need to watch out, so we don't accidentally get rid of the values and the habits we're really uniquely good at, the things we care about, that we should keep. There are people who really love open source culture the way it is now, who feel safe and loved and comfortable here, and that is great. We absolutely deserve to feel safe and loved. But I think there are some changes we can make so that even more people can also feel safe and loved here -- it's additive, it's not about replacement, it's saying, let's invite these people to the party too, and make sure they can have a good time once they get here. We can all work together, and complement each other's strengths.

That's the heart of what I'm going to talk about today, so you can look at your own project and think about where you want to add another interface to your community, so you can be more hospitable to new potential colleagues.

Housekeeping

Just some housekeeping to start: I am not using any slides today; instead we have CART, Computer-Assisted Realtime Translation. A person is transcribing the words I'm saying. Stacey. Thank you, Stacey. I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk. I'll be posting my notes online later today.

And there are other good talks happening right now, so to help you decide whether to stay in this room: this talk is going to be more interesting to people who already have been participants in open source software for a few years, who can use tools we commonly use in our community, like version control, IRC, mailing lists, bug trackers, and wikis, and who are already familiar with general open source software trends and arguments. And this talk is going to be most interesting to people who regularly spend time working to help reach out to new people and get them to use open source software and participate in our communities. So if that is not you then right now, check out the other talks, like "Making awesome things accessible", "I am your user. Why do you hate me?" or "Managing while Black".

"Inessential Weirdness"

OSCON 2016 So the title of this talk is "inessential weirdnesses in open source" -- and this phrase comes from the article "It's not 'them' -- it's us!" by activist Betsy Leondar-Wright. There'll be a link to this article in the notes I put online. The basic idea is, if you look at your own community with the eyes of an outsider, look at it from the perspective of a specific group of people you'd like to recruit, what do you think might discourage them or make them uncomfortable? Those are what we'll call "weirdnesses." And you get to decide, your community gets to decide, which weirdnesses are essential, and which ones, in Betsy Leondar-Wright's words, are inessential, meaning you should offer a workaround for them, or even try to change them.

Leondar-Wright suggests that there are a few classes of essential weirdnesses. There are weirdnesses that come out of our shared core values -- as she puts it, they "couldn't be eliminated without doing a deep injustice to someone". So, for us, that would include stuff like releasing our code in public. There are people who have a hard time with that. There was one coder I tried to help, because she wanted to get into open source, and she just choked, and could not start contributing to our community, because no matter how much handholding or guidance I gave, she was just too afraid to make commits in public. But that's inherent to open source. We can't make that one chunk of the codebase private so people can never see it, that would be against our values and also just logistically it wouldn't work.

Leondar-Wright also points out that some essential weirdnesses are "personal differences that may seem weird to others but are very important to the individual" (for example, choosing not to drink alcohol even though everyone around you is). I would argue that this is also a reflection of our values. We respect people's choice to abstain from alcohol because we value personal autonomy and bodily consent.

But "it's rarely essential to impose one's personal choices on others".

I've run into trouble using this term, because the word "inessential", to some people, implies that something has no value, or that it's harmful and we should get rid of it. No. It's more like a heads-up, that here's a place where you could build out some new API client libraries, in more languages, have more interfaces, so more people can interoperate with you.

I'm going to quote an anecdote from Betsy Leondar-Wright's article:

A few years ago, I listened to week-by-week reports from a radical working-class friend who tried to join a [group fighting corporate globalization]. He told me of snide comments about his fast food; elaborate group process that took hours and hours; insistence that everyone "perform" by answering a certain question at the beginning of the meeting; uniformly scruffy clothes that made his pressed shirts stand out; potlucks that were all tofu and whole grains; long ideological debates over side issues; and an impenetrable fog of acronyms and jargon. He soon quit in disgust. I wonder if the group members understood why he left.

For professional-middle-class progressive activists like myself, it's easy to understand why working-class people would be alienated by the mainstream culture of well-off people. After all, we tend to be alienated by it ourselves, because it represents values we've rejected, like greed and materialism. But the idea that working-class people would have any negative reactions to our own subculture, in particular our values-based 'alternative' norms, tends not to occur to us.

I read that and I thought about times I've seen new people in open source having a bad time, because of something that has nothing to do with our core values, nothing to do with transparency and freedom and helping your neighbor. But because someone was mean to them because they use Windows, or they feel pretty alone and isolated because of our communication norms, or they had a tough time getting started with Git, because it's really hard to get started with Git.

And am I saying "let's get rid of Git"? No! I'm saying, if someone wants to get started in open source, maybe Git isn't the very first thing I want to teach them. Maybe I accept that right now they're on Windows. You gotta meet people where they're at.

That progressive activist group that Betsy Leondar-Wright's friend tried to join -- it sounds like they were basically a working group full of experts who had process and jargon and habits that worked well for them. And we have specialized process and jargon and habits that work well for us, when it's all experts together. I think one of the hardest things to do is for experts to look at a culture that's working for us and figure out what scaffolding we can offer so new people can come in and become experts too. Researchers Stuart and Hubert Dreyfus actually talked about this problem in 1980, in their Dreyfus Model of Skill Acquisition -- when you go from novice to expert, you don't just learn a bunch of new facts. The way you look at the world changes, you're making decisions on a new analytical level, you have a whole new perspective. And it's really hard for you to empathize with people who don't have this skill, who haven't learned the judgment and the reflexes that you have. [See Mel Chua's talk slides on education psychology for more on this.] This is one reason writing documentation is so hard. [Here, despite the bright lights, I saw one audience member nod, and that made me happy.]

So today I'll be talking about some few examples, bits of our subculture, the open source software subculture, that routinely alienate new people. And I'll give my thoughts on how to discern the bits that are important, that we shouldn't ever give up because they're key to our values, from stuff where we can offer workarounds when we're doing outreach events and creating online spaces for newcomers -- those are the bits that Betsy Leondar-Wright calls "inessential weirdnesses". Then I'll explain how you can better recognize and fix these kinds of snags in your own outreach work. My hope is that after today's talk you'll be more effective and you'll help make outreach experiences more hospitable and thus more effective.

[Now: three stories.]

Contempt

My first story today is Aurynn Shaw's story about realizing that hating on Windows and PHP has real costs. She writes in "Contempt Culture":

...when I started programming in 2001, it was du jour in the communities I participated in to be highly critical of other languages. Other languages sucked, the people using them were losers or stupid, if they would just use a real language, such as the one we used, everything would just be better.

Right?

This sort of culturally-encoded language was really prevalent around condemning PHP and Java. Developers in these languages were actively referred to as less competent than developers in the other, more blessed languages.

I do recommend that you read Shaw's essay. She goes into some really worthwhile insights on what this dynamic achieves for the people who participate in it, and whom it excludes.

She writes:

It's 2015, and I saw a presenter at a Python conference make fun of Java. How would that feel to people trying to move from Java into something else? I wouldn't feel welcome, and I'd have learned that the idea that the Python community is welcoming wasn't true.

I'm tired of calling people out again and again for dumping on PHP.

I'm tired of people dumping on Windows, that most popular operating system, because it's not what we choose to use, tired of the fact that we don't make it easy to use our tools and teach them how to move, when they're ready.

As I experienced in most of my community management work in open source software, over and over, I saw how few of our tools and applications make it easy for Windows users to try out open source software. On Windows, installing, for instance, an open source application that depends on Ruby is a big hassle, and might mess up other stuff you're doing that depends on Ruby.

So what is essential here and what is inessential?

Do you yourself have to go get a Windows machine and start writing PHP? No. Of course not. Remember, personal autonomy and choice is essential!

It's essential that we encourage people to move off of proprietary systems, giving them support in the short term with training and help, and in the long term with kick-ass operating systems and applications, and a culture and a political environment that encourages open source software. It's inessential to make people feel bad that they haven't done a really hard transition yet. Activists have known for a long time that if you ask a new potential ally to change their entire life and lifestyle at once, you don't get as many new followers as if you get more doable, with short-term goals that give them immediate benefits.

Syntax

Here's my next example, and it's about language. Now, if you were teaching someone a skill they didn't know before, like woodworking or omelet-making or choral singing, it would make sense for you to teach it in the language they already speak. If they only speak English, teach it to them in English.

Well, every day, we do the opposite of that. We tell people that they have to learn a new language along with the new topic. The topic, the skill, is using open source software, and the language is the command line.

Gus Andrews, who's a usability expert and a Fellow at Simply Secure, has a provocatively titled blog post, "Why the command line is not usable". She discusses how the command line is an environment that requires tremendous cognitive load of new users. She reminds us that recognition is far easier than recall.

Command lines demand that users remember the correct phrase to make the system run, rather than giving them prompts which might help them guess what the system needs them to do next. The overwhelming majority of people alive today have never had the opportunity to learn those commands. Making them look them up and learn them themselves would make them very, very frustrated -- they don't have time for that. GUIs aren't just "shiny": they are tools which help us remember what is possible.

Some users absolutely find the command line a lot more usable and accessible! And I don't discount their experience! But over and over we see that a lot of new users find it really frustrating to get started on the command line.

And this is not just about uneducated users, or users who don't spend that much time with computers. As an example, computer science professor Philip Guo has an essay on his site called "Command Line Bullshittery" where he talks about all the little commands his research students, CS researchers, have to learn in order to get their research done. Stuff like

nohup tar -jxvf giant.tar.bz2 2> cmd.errs &

And he says that as an advisor, one of the things he has to do to keep his students from getting super demoralized is to teach them how to install and configure and use open source software on the command line, which is a really deeply unfriendly experience, and to reassure them that it's "just a necessary upfront tax required to enable them to do the actual interesting research".

And in that piece he distinguishes between incidental and intrinsic complexity.

The fact that it's hard to learn the command line "arises simply because modern research software development is a messy jumble of open-source tools tied together by the duct tape of command-line scripts." It's incidental complexity. It has nothing to do with the intrinsic complexity of CS research, the hard problems that these researchers are trying to investigate.

This underscores that it is just hard to install open source software, often, and get it to a state where it's properly configured and secured, and you can do work with it and import and export data. Recently Bret Davidson and Jason Casden wrote a piece in the code4lib journal, "Beyond Open Source: Evaluating the Community Availability of Software". Their suggestion was: What if you just took a stopwatch and saw how long it took a representative user to install software and do something useful with it? I think for a lot of us, we are aware that this number, for our projects, would be dismally high.

Similarly, when I was at the Wikimedia Foundation, we started the Visual Editor project, which makes it easier to edit Wikipedia articles. Before we started this, we often saw that skilled writers with useful content to contribute would get discouraged, because they knew English, they were web-savvy, they sometimes even knew HTML, but they didn't know this wacky weird markup language, wiki syntax, that no one else in the world used. In fact, sometimes this made them think that they were not allowed to edit -- people would click the Edit link, see this jumble of what looked like source code, and then

Fall Picture Book Preview

May. 20th, 2016 06:23 am
[syndicated profile] kirkus_kidlit_feed
Forgive me for doing that thing where I skip ahead a whole book season (Summer 2016) to talk about what follows it, but this is the time of year when—if you write about picture books, as I do—you start to get a lot of Fall and Winter picture book galleys (called F&Gs, which I also sometimes mutter under my breath as a curse word, because don’t you think it sounds like one?). It’s more than a little bit thrilling, when you like to keep up with picture books in any given year, to get a sneak peek at what your favorite illustrators will be releasing. Before we know it, summer will be over, and these will be some of the new offerings on bookshelves. Let’s take a peek at some of them.
[syndicated profile] tufts_dca_feed

Posted by Pamela Hopkins

By Katie Anderson

This summer, the Class of 1991 returns to the Tufts campus 25 years after their graduation. This exhibit, “The World According to Tufts,” aims to capture some of the elements that shaped student experiences.

Some obvious parallels emerged between this class and the other two profiled this year (Class of 1966, Class of 2006). War is an all too common theme. The Class of 1966 responded to the Vietnam War, while ’91 and ’06 both debated and protested conflicts in the Middle East. Women’s issues shared the limelight. “Take Back the Night” hit college campuses across the country, and a dialog around sexual harassment, consent, and safety coalesced. The Class of ’91 also navigated the AIDS crisis and LGB rights (transgender would not be added to the acronym until 1998). The Tufts LBG Resource Center would be established in 1992, shortly after the Class of ’91 departed.

In highlighting some Jumbo experiences, I didn’t want to exclusively focus on conflict and unrest. Luckily, the yearbook’s student staff compiled a fantastic yearbook in 1991, with page after page of quality photographs and thoughtful text. I looked upon the faces of these Jumbos twenty years my senior. So many smiles. So much silliness. I didn’t know any of these people, yet thumbing through one year of their lives felt deeply cathartic. Reunions are rooted in that catharsis, the tug of nostalgia and the unearthing of memories. Or perhaps just some sweet, satisfying revenge.

The Top Ten Favorite Tufts Traditions had some particular resonance. It seemed like an effective way to tailor the content to reflect the Tufts Class of ‘91, rather than the entire age group or the country at large. Whether you participate or not, you probably know your school traditions. By their very nature, they necessitate widespread recognition and easy transference from one class to the next. Furthermore, traditions are started and shaped by students, and that sense of ownership gives them more power than anything originating from the institution.

The Tufts Jumbo – Volume 66, 138.

The Tufts Jumbo – Volume 66, 138.

The most popular Tufts tradition perfectly illustrates this. No administrator dreamed up the West Hall Naked Quad Run (NQR). The chilly trot through campus took place every December as a way to relieve stress before finals. The NQR’s origins are admittedly a bit obscure. It had existed in a semi-organized form since at least 1981, and some Tufts alumni recall various groups streaking in the 1970s. In 1987, freshman year for the Class of ’91, West Hall became a co-ed dorm, and subsequently the NQR’s popularity grew immensely. Though the NQR eventually got the axe from the administration in 2011 amid safety concerns, it had been alive and well during the Class of ‘91’s tenure.

Another popular Tufts tradition, painting the cannon, is still thriving. The cannon, perched next to Goddard Chapel, arrived at Tufts in 1956 as a gift from the city of Medford and the Medford Historical Society.

A Jackson College student poses with the cannon, ca. 1960s.  http://hdl.handle.net/10427/1930

A Jackson College student poses with the cannon, ca. 1960s. http://hdl.handle.net/10427/1930

The cannon was believed to be an original from the deck of the USS Constitution until 1987, when it was discovered to be a replica while it was being moved. Since 1977, the cannon has been painted to raise awareness for campus and global events, and sometimes as a personal billboard.

The Tufts Jumbo – Volume 66, 139.

The Tufts Jumbo – Volume 66, 139.

Another Tufts “tradition” further down the list employs some undisguised sarcasm to illuminate student grievances. At #15, the “10% tuition increase per year” was certainly unwelcome. Indeed, from 1987 to 1991, undergraduate tuition jumped 32 percent.

Reunion exhibits are not merely educational; we seek to evoke memories. It is challenging, and perhaps blasé, to attempt to capture an entire age group’s experiences, particularly one that began college before I was born. The Class of 1991 certainly did not arrive as freshmen with the same goals. Not everyone was politically engaged or participated in the same social events. Not everyone will remember the same activities, or as fondly. Our goal here was to recall a few key aspects of Jumbo life, and the viewer’s memories can take it from there, contextualizing these threads within their own personal experiences.

Sources:

“The Naked Truth: NQR’s History Marred in Rumor and Conjecture.” The Tufts Daily, 8 January, 2008.

The Tufts Jumbo – Volume 66. Medford, MA: Tufts University, 1991.

Sauer, Anne et al. Concise Encyclopedia of Tufts History. “The Cannon, 1956.” Tufts University. Digital Collections and Archives. Medford ,MA. http://hdl.handle.net/10427/14829 (accessed 28 March 2016).

Tufts LGBT Center. “Tufts Queer History Project Timeline: 1990’s.” http://ase.tufts.edu/lgbt/about/TQHP/1990s.asp (accessed 28 March 2016).

Tufts University Fact Book 1990-1991. Medford, MA: Tufts University, 1990.

Katie Anderson is a second year Master of Arts Candidate in History and Museum Studies at Tufts University.

Letters to the President

May. 19th, 2016 04:34 pm
[syndicated profile] aotus_feed

Posted by davidferriero

One of the most rewarding parts of my work is sharing the treasures of the National Archives with kids and their families.

Through the support of the National Archives Foundation, we continue to host sleepovers in the Rotunda of the National Archives. These events give kids the chance to spend the night next to America’s most precious treasures: the Declaration of Independence, the Constitution, and the Bill of Rights, while engaging them in activities that help them learn about our nation’s history, and explain the important role of the National Archives.

One of the activities during our sleepovers provides an opportunity for kids to write letters, as I did, to the President of the United States, which are then delivered to the White House.

25000660461_8898dcd0a6_h

Kids at the National Archives sleepover write letters to the President of the United States. February 6, 2016. Photo by Jeffrey Reed.

Our latest delivery received a response directly from the President!

President Obama Letter page 1

President Obama Letter page 2

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It is a privilege to continue to host these events for kids and their families, and encourage them to become more involved in their government. For more information, please visit archivesfoundation.org/sleepover.

The Stories We Tell

May. 19th, 2016 06:20 am
[syndicated profile] kirkus_ya_feed
Mary knew that young women in nineteen-fifties England were supposed to be modest, self-deprecating, and demure. They should not have too much self-confidence, not assert their sexuality or independence, and never express their appetite or desire. They should be restrained, make sacrifices, and put others first.
Page generated May. 31st, 2016 01:54 am
Powered by Dreamwidth Studios