Grace Hopper Open Source Day 2013: Mentoring Projects Application Period Open

Well, technically it has been open for awhile now, but you see how often I get around to updating this blog.

Grace Hopper Open Source Day will reprise for the 3rd time this year at the annual Grace Hopper Celebration of Women in Computing Conference. The Open Source Day Committee is currently accepting applications from any open source project that would like to increase diversity amongst their participants and work with the community of technical women attending Grace Hopper.

You can learn more about Grace Hopper Open Source Day 2013 by visiting the Event FAQ and the resources linked therein. If you’re a member of a mentoring project and you’d like to apply, we’re accepting applications through May 31, 2013.

I hope to see many of the projects I’ve been involved with in past lives, including Google Summer of Code, apply to be a part of Grace Hopper Open Source Day 2013. See you there!

Posted in conferences, open source, volunteer work, women in tech | Tagged , | 1 Comment

How To: Writing an Excellent Post-Event Wrap Up Report

Ed. Note: I originally composed this post as a resource for folks at my employer, Red Hat. Obviously, the Red Hat specific bits have been removed, e.g. my team can’t volunteer to help you edit your posts. I’d always planned to open source this guide for the good of FOSS marketing, but simply hadn’t gotten around to doing so. Fortunately, the stellar interns from the Sahana Software Foundation provided me with a good reason to get this done, as they’re looking at doing a SahanaCamp in Hyderabad, India and were wondering what sort of data to collect to report out after the event. Many thanks to Somay and S.P. for the motivation to publish this post and to my employer for being awesome and encouraging me to share my work for the community’s good.

Hackfest participants collaborating

Sharing the Meetup, Conference and Hackfest Love (Photo Credit: Flickr user 4nitsirk)

tl;dr

  • Schedule time to write and publish the report within 48 hours of the event. Block time on your calendar so it happens.
  • Along with your text about what you found most useful about the event, include photos and video or audio recordings, preferably embedded in the post. Linking to these resources is also OK.
  • Include important stats in your post that are relevant to the community attending the event, e.g. number of attendees, number of student attendees, number of committers, etc.
  • Make sure to thank the event organizers and sponsors in an appropriate fashion.
  • Once your post is published, make sure to share it via whatever social media channels you like to use. If you do not use social media, let the event organizers know about your post in case they’d like to use it in the post-event report outs or to add it to their event news page.

Good Sample Post-Event Reports

Preparing to Write a Great Event Wrap Up Report

Schedule Time to Write the Report

A post-event wrap up report is most useful within days of the event, and it’s best if you can publish your piece within 48 hours of the event’s conclusion. A wrap up report should be published no more than two weeks after the event. At two weeks out, the news is a bit stale so do your best to aim for 48 hours after the event, with a week or less time being OK but not optimal. Schedule time on your calendar for writing, as it’s easy for this task to be deprioritized in the face of other needed work. Set aside time for writing or you’ll likely find you don’t get the writing done.

Pro-Tip: Schedule time no more than 24 hours after the event to both write and publish your wrap up report. The fresher the news, the more readers you’ll have.

Take Good Notes

Writing up a great event wrap up report means gathering data while at the event. Take the time to write down a few notes about things that particularly impressed you during the conference or meet up. Don’t rely on your memory to keep track of the things that stood out to you, and write down as many take aways from the event as possible. You will not use all of your notes, but the more detail you can later provide, the better.

Pro-Tip: Most post-event wrap up reports include the following items, so take notes accordingly. You may not use all of these details, but it is good to have them.

  • Event overview, which you can likely harvest from the blog post announcing the event, the event “about” page on their website or from sites like lanyrd, meetup.com, etc. You don’t have to use the organizers’ description, but it is often a good starting point.
  • Location of event, including thanks to whoever provided the space in the case of a meet up, e.g. “Red Hat graciously hosted the Boston Python Users Group meeting last Wednesday.”
  • Number of attendees at the event. Some like to note the number of attendees from certain groups depending on the goals of the particular community hosting the event, e.g. “The organizers were excited to see 25% of our attendees were newcomers.” or “We had more than 50 women join us at the conference, a 15% increase over last year.” or “I was particularly proud of the efforts to reach out to the student community in Prague, with more than 40 students attending. Half of the students had not yet entered university.”
  • Thanks to the event sponsors. While you do not need to call out the names of all sponsors, it is best practice to give a shout out to your employer specifically if they were a sponsor. In the case of one or two sponsors, it is best practice to name them and link to their home page in your thanks. In the case of an event with many sponsors, a thank you to them with a link to the event’s sponsors page will suffice. If a sponsor did something truly memorable and appreciated, a specific thanks to that sponsor is always welcome.

Pro-Tip: Thanking event sponsors, particularly one’s own employer, can be difficult to do without looking disingenuous. The most important thing to remember is to disclose your relationship with your employer in the blog post to avoid accusations that you’re shilling. Consider the difference between these two thanks, both of which say basically the same thing, but will likely be received by your audience very differently:

  • I’m very pleased that my employer, Red Hat, treated everyone at the Foo Bar Meeting to coffee and treats. We’re glad we could share a meal with all of you and provide a small bit of thanks for all of your contributions to FLOSS.
  • Red Hat provided coffee and treats to everyone at the Foo Bar Meeting, which was totally awesome of them. Red Hat rules!

Take Photos

Of course, you want to ensure that you have permission to take photos at the event. Confirm with the organizers if there’s a photography policy and abide by it. Some FLOSS folks request that all photos taken during their events be published under a Creative Commons license, others forbid photos at their events entirely, others request that attendees make use of photographs taken by the conference photographer. Whatever the organizers request of you, honor those requests. Abiding by the conference photo policy makes it much easier to ask for an exception later should you need to do so, e.g. “I notice this photo is copyright $EVENT, may I use it in my forthcoming blog post provided I give proper attribution?”

Being a good FLOSS citizen also means obtaining permission from the subjects of your photos to capture their image. Some conferences provide pins or other garb to attendees who do not wish to be photographed – keep an eye out for these indicators. If you don’t see one, politely ask to take a photo of your fellow attendees and let them know you may use it on your blog or publish it on Flickr, etc.. If they decline, respect their request. It is also best practice to let folks take a look of the photo you have taken to make sure they are happy with their appearance in it, but this step is not required. It definitely helps build good rapport with your fellow community members, so why not do it?

In general, group photos that do not show faces in the audience are well received even in those communities that are “camera shy.” Get a good sense for your audience and photograph accordingly.

Pro-Tip: Capture or use the highest possible quality imagery. Suboptimal photos from your cell phone camera are better than no photos at all, but not by much. If you don’t have a high quality camera, check the conference’s photo pool for imagery that may be better or ask a colleague to snap a pic or two on your behalf. Ensure whatever content you use is licensed so that you may use it or that you obtain permission from the copyright holder to make use of it.

Session Audio and Video

If session(s) from the event are recorded, it is always good practice to at least link to those talk recordings. For a meet up or other event where only one talk was recorded, embed the recording in your post. For events where multiple sessions took place, choose your top N (3 maximum) and embed those recordings. Make sure that you introduce the recordings with sufficient text – which can be quite terse, but must be present – so that your readers understand why they ought to take the time to watch the content.

Pro-Tip: Some videos feature automatic closed captioning for the hearing impaired and still others provide text transcripts of the audio/video recording. When versions of the content exist that provide these extra vectors of entry for your audience, ensure that you embed them or link to them.

Know How to Tag Your Post and Photos

Most event organizers these days are pretty good about letting folks know what tag(s) to use when sharing photos, dents/Tweets, Facebook messages and blog posts. Make sure to note the tag(s) used and add to your photos and post.

Pro-Tip: If the hashtag for the event isn’t prominently mentioned in the event guide or at the start of the meet up, don’t hesitate to ask the question at the start of the festivities. You’re not the only one wondering what tag(s) to use. If it’s too difficult to ask this question up front, see if the event already has a photo pool or Tweet stream. Replicate the tags in use for the conference tweet stream or photo pool.

Pro-Tip: Consider using some sort of social bookmarking service to gather news and feedback from the event. It’s possible that the event organizers have already set something up, so ask them if they have done so. If not, offering to set up the resource for them is a kind and wonderful thing to do when you’re at an event run by community volunteers.

Gather Other Materials Needed

Perhaps you saw an outstanding network diagram in a particular presenter’s talk or you noticed that a speaker did not plan to publish her slides. It’s best to ask the speaker at the event for these resources, then follow up on your request by email. If you were not able to make the request in person, make sure to send your request by email quickly so you can include the materials in your post and get the post published in a timely fashion.

You will also likely find that other folks have written about the event and may have done write ups on sessions you missed. They also may have an alternate perspective on an aspect of the event you particularly enjoyed. Include links to other write ups and reports in the blog post – even a simple list of links is fine – and consider updating your post if you run across a particularly excellent write up of the event after you’ve published your report. Updating the blog post comments with additional details is a fine way to proceed, but folks are often less likely to read the comments section.

Pro-Tip: Before publishing your report, take a moment to search identi.ca and Twitter using the event hashtag. This quick search will likely produce other write ups that you may wish to link to in your own post. The conference news aggregator or press page is also an excellent source of such material.

Writing Your Post-Event Report

If you’re having trouble getting started, prepare an outline of your post. Start with the basics as mentioned in the “Take Good Notes” section in your introductory paragraph, then expand from there. If you just hate writing – and that’s ok, many do – get as many points out onto a page as possible, then ask for help from a friend or colleague to organize your thoughts and content. A blank page is a tough place to start, so don’t expect what you compose to be immediately perfect.

Pro-Tip: If you are having trouble writing and outlines are not the best way to organize your thoughts, try these approaches:

  • Just write. Don’t worry if it’s not perfect or even coherent at first. Structure, proper grammar, correct spelling, etc. can be taken care of later.
  • Consider writing down the ten second pitch for the event and then writing to address the high points that support that summary.
  • Talk about your experience at the event with a friend or colleague and ask them to jot down notes during your conversation. Let their notes become your outline. Alternatively, you may wish to use transcription software for this purpose.

Joe Ottinger, my colleague at Red Hat who also works on the Open Source and Standards Team, has penned some more tips on writing on his blog.

Publishing Your Post-Event Report

This document largely assumes that you’ll be publishing your event wrap up post on your personal blog, but there are many outlets for such reports. The conference organizers may need help with wrap up reports due to post-event fatigue, so offering to help them with your post-event write up can be a welcome way for your post to get even wider exposure and to do a good deed for the community. The fine folks at opensource.com also publish post-event reports, so check out their guidelines to submit content. You may also find that your wrap up report will be useful to other trade press outlets or blogs, so licensing your content so that folks can (re)use it increases the value of your creation. You may even find that said trade press outlet or blog would like to simply republish your post, which is a great thing to do if you’re open to it.

Pro-Tip: Once you have written your post, make sure to share it using whatever social networking services you prefer to use, e.g. identi.ca, Twitter, Facebook, Google+, etc. Make sure to also include the event tags when broadcasting via social media. If you’re not a social media user, the event organizers may want to help you share the write up more widely via their social media channels.

Sample Post-Event Wrap Up Reports

Here are a few examples of well written post-event wrap up reports, provided as a source of inspiration if you’re having trouble getting started or just want to get a sense of what a good post-event report contains. If you already read through them in the tl;dr section at the start of this post, you should skip this bit. :)

If folks have suggestions on how to improve this article, I welcome feedback in the comments section.

This post is licensed Creative Commons Attribution ShareAlike Unported 3.0. Please reuse, remix and share alike widely!

Posted in conferences, open source | Tagged , , , | Leave a comment

Berlin Buzzwords Conference Actively Recruiting Female Speakers

The fine folks organizing the Berlin Buzzwords Conference have opened their call for submissions, and they’ve reached out to me to ask for help in recruiting female speakers for the event. I gave a keynote address at the conference in 2012, and I’m honored to help them attract a more diverse speaker talent pool and serve on their program committee this year.

If you’re a woman technologist with interest in any of the following areas, I’d love to read a submission from you for Buzzwords 2013. From the conference call for papers:

The event will comprise presentations on scalable data processing. We invite you to submit talks on the topics:

  • IR / Search – Lucene, Solr, katta, ElasticSearch or comparable solutions
  • NoSQL – like CouchDB, MongoDB, Jackrabbit, HBase and other
  • Large Data Processing – MapReduce, Storm, Hadoop, Cascading or Pig and relatives

Related topics not explicitly listed above are more than welcome. We are looking for presentations on the implementation of the systems themselves, technical talks, real world applications and case studies. Please don’t hessitate to submit talks even if your solution is not open-source, general purpose or exotic, we are looking for interesting technical presentations from engineers for engineers.

If you’re looking for help preparing your abstract, learning more about the conference or are looking for advice on making your speaking engagements more effective, feel free to reach out to me. A number of other resources exist to address these same topics, including the Speak Up! project, which offers mentorship for speakers in an effort to “empower… and educat[e]… speakers of all genders, races or experience levels, connecting them with mentors and other resources needed to help them through what can be a difficult, daunting and discouraging experience.”

I’ll cover other, similar resources in a later post.

Posted in conferences, women in tech | Tagged , , | 2 Comments

Join Us for Open Source Day at Grace Hopper 2012

This post is lightly adapted from the original, which appeared on the Best of Systers Blog.

Systers is the world’s largest email community of technical women in computing. It was founded by Anita Borg in 1987 as a small electronic mailing list for women in systems. Today, Systers broadly promotes the interests of women in the computing and technology fields. The community celebrates its 25th anniversary this year.

As most folks likely already know, registration for Grace Hopper 2012 has opened, and I’m looking forward to seeing many of you at the conference! In addition to all the amazing keynotes, technical sessions and workshops, I’m particularly looking forward to participating in Grace Hopper Open Source Day. Now in its second year, Grace Hopper Open Source Day introduces conference attendees to the wonderful world of open source software through a variety of activities. Grace Hopper Open Source Day takes place on Saturday, 6 October 2012, though we’ll have several related activities taking place during the rest of the conference.

Participants coding at Grace Hopper Open Source Day 2011 (photo credit: Anita Borg Institute)

So, what is Open Source Day?

Open Source Day is your opportunity to collaborate with your fellow attendees to write software for one of ten open source software projects, all of which have a humanitarian or social good focus. Attendees of all skill and experience levels are welcome and encouraged to attend. Even if you’ve never contributed to an open source project before, you will end the day having created something valuable for the public good!

We have ten projects who’d like your help, including two local Baltimore, Maryland organizations, GoodSpeaks and the Baltimore Neighborhood Indicators Alliance. GoodSpeaks works “to help all charitable organizations – especially smaller organizations working at the grassroots level – self-report through video to increase visibility and support” and the Baltimore Neighborhood Indicators Alliance promotes, supports, and helps people make better decisions using accurate, reliable, and accessible data and indicators to improve the quality of life in Baltimore City neighborhoods. In true open source style, we’re giving Systers the opportunity to scratch their own itch by working on Mailman, the software that powers the Systers mailing list. We’ll also be working with projects devoted to accessibility, disaster relief, education and free culture. You can find the full list of participating projects on the Grace Hopper site.

So, interested in Open Source Day but wondering what you can do to be better prepared for the festivities? Excellent!

Once again, we’ll be hanging out at the Free and Open Source Software projects booth in the expo hall. If you’re completely new to open source software, please stop by and visit us. We’ll have several folks on hand to answer your questions and to tell you more about open source project communities you may want to join. If you’re an old hand at open source and want to volunteer to staff the booth, we’d love to hear from you! You can also sign up for booth duty shift directly on the Systers wiki.

Members of the Open Source Day committee have also organized a series of talks designed to help folks participate in Open Source Day and beyond, including a Wikipedia article edit-a-thon. We’ve also scheduled two panels discussions on participating in open source projects that are geared for newer contributors. We hope that Systers who have participated in open source software projects will join us for these panel discussions to share their experiences with others. (And who doesn’t want to learn how to edit Wikipedia articles?)

You must be registered for the Grace Hopper Conference in order to attend. For full details on registration, visit the Grace Hopper Open Source Day page. We hope to see you there!

Posted in conferences, open source, volunteer work, women in tech | Tagged , , , , , , , | Leave a comment

An Inside Look at Hiring Processes: Some Thoughts for Women Seeking Employment in IT

A recent article in The Register caught my eye and inspired me to share some of my past experiences as a corporate recruiter for two tech firms. (I also asked a few of my colleagues who are currently working in recruiting to take a look and share their thoughts.) Titled “Why women won’t apply for IT jobs,” the article cites findings from the Australian Computer Society Foundation Trust Fund, with their executive director noting, “Women won’t apply for IT jobs unless they are certain they meet every single criterion for the gig.”

Readers of Clay Shirky’s A Rant About Women will recognize similar points made in this Register article, and no doubt many a useful article and research paper has been written on this same topic. (In fact, I’d like to read them—please share in the comments on this post.) I’m not here to explore this field of study, rather to give folks an inside look at corporate hiring processes with a view to helping women feel more confidence in their searches for tech jobs, regardless of whether their skills exactly match those in a particular job description.

Please note that this is a summary of some of my experiences, experiences I’ve heard about from friends, and general hiring horror stories shared by colleagues over cocktails at HR functions. Your mileage may vary. Greatly.

Hiring Managers Do Not Know Exactly What They are Looking For

Anyone who has ever managed people will tell you that hiring well is challenging at best, particularly when many managers in the technical field are engineers first, social creatures second. Just because someone is gifted technically does not somehow make them equally gifted with the power to recognize exactly what skill set is required in a new hire to make their team most successful. In fact, managers often know that their team requires many disparate skills, and they create job descriptions that are a laundry list of these many different attributes, knowing full well that such a candidate likely does not exist. Worse yet, that laundry list of skills is usually a list of every possible skill a future employee might need over a period of several years, rather than a reasonable assessment of what any given individual would do on a day-to-day basis.

The reason this approach persists is simple: cast the widest possible net, catch more fish, and hope that one of them is the closest possible approximation of the person you need. Another reason is the bare facts of being at any rapidly moving organization: what you need today, you may not need in a week, a month or a year, so you ask for someone who can do every possible thing in the hope that they can be agile enough to switch their focus more or less seamlessly. It’s a nice thought, but it’s never going to happen that way in real life; no matter how talented someone may be, there’s always going to be a context switch cost when changing priorities, product line, or programming language.

Recruiters Are Often Trying to Channel What a Hiring Manager Wants

Speaking from experience, the creation of most job descriptions goes a little bit something like this:

Recruiter: Hello, Hiring Manager, so great I could get a meeting with you this week!

Hiring Manager: Yes, great to see you. I was due in the War Room 15 minutes ago, so we need to make this quick.

Recruiter: You got it. I know you have three open reqs to fill. How can I help?

Hiring Manager: I need a senior [programming language] person, a senior [application type] developer, and a junior [programming language] person.

Recruiter: Ok, great. We hired a senior [programming language] person last year, will the same job description work?

Hiring Manager: No, I need to update that text—can you send it to me?

Chances that the hiring manager will get around to updating the job description are 50/50 at best. The manager is oversubscribed and short-staffed, so the outdated description will likely be posted in hopes that the right candidate will somehow be found in the pile of resumes that come in. Even if the job description is updated, see above: “Hiring Managers Don’t Know Exactly What They’re Looking For.”

Recruiter: Sure, will do. Now for the senior [application type] person….

Hiring Manager: I need someone really good for that role, I’m dying here.

Recruiter: Got it, got it. What skills do you need?

Hiring Manager: I don’t have time to think about this much right now, but I think So-and-So in recruiting put one together for me a little while ago. Can you track that down?

“So-and-So in recruiting” likely did not create one a little while ago, and the recruiter may simply look for a similar job description on the Internet to have something to present to the hiring manager. Chances that the oversubscribed hiring manager will critically read it are low, as they may be assuming this is the same thing they thought they created just a bit ago and, even if it isn’t perfect, they just need someone good, right now.

Recruiter: No problem. Now for your junior person…..

Hiring Manager: I really need to go. Can you crib the req for the entry level Java dev and just replace Java with Python? I’ll clean it up from there.

You get the general idea.

Many of the Figures in Job Descriptions Have Little to Nothing to Do with What is Required for the Role

Most of the “numbers” in these bullet point lists of job requirements are mapped to salary matrices for an organization, allowing folks in Human Resources to know what they ought to pay you and what job title you ought to be given. When reading a job description that asks for 10+ years of Android programming, what you’re seeing is someone having heard that their hiring manager needs a “senior Android application programmer,” and in this organization, “senior engineers” have 10+ years experience in their field. The fact that no one on this planet has 10+ years of Android application programming experience isn’t considered. You’ll often see job descriptions that ask for 7+ years of Java, etc., and, once again, you’re in the same boat; 7+ years of experience at that organization equates to a particular job grade, e.g. senior software engineer, with the requisite salary range. Many job descriptions are created by starting first from the headcount budget approved for a particular hiring manager for a particular job role, so if a senior software engineer gets paid 100K per annum, and that’s the headcount budget, the call goes out for a senior software engineer.

In reality, the hiring manager likely does not give two hoots about the number of years of experience someone has in a particular area, they just want someone really good, now. Since you can’t post a job description that says “Wanted: Highly Talented, Learns Quickly”—though some companies are doing that these days, largely start-ups—years of experience stands in as an “objective” metric for “highly talented.”

What this Means for Women Seeking Employment

Simply put, if you know that you have one-third to half of the skills listed as required for a particular role, you love the company and its products and are thrilled at the idea of working there, apply. I cannot stress this enough—the worst the organization can do is never contact you or send you a rejection email immediately. Not getting what you want hurts, but it’s more than worth trying for roles that you know you’d be wonderful at if they’d just give you a chance to prove yourself, to get up to speed on that one language out of five that you don’t know, or to take a training course or two to round out areas where you need a little more help.

Bottom line, ladies—we do ourselves a great disservice by assuming that we cannot instead of that we can. I know I do the same in many areas of my professional life, and it’s high time we all gave ourselves the kind of credit and encouragement we give to our friends, colleagues, and families. And even if a hundred pep talks won’t help our Impostor Syndrome, perhaps this inside look at how hiring gets done will help some women realize just how little they actually need to meet “every single criterion” to get the jobs of their dreams.

Was This Post Useful?

If you found this post useful, I’m very pleased. If you have other general questions about the IT hiring process, e.g. regarding negotiating benefits, etc., please note them in the comments. If I cannot answer them, I’ll do my best to find someone who can.

Thank you to Ruth Suehle for her assistance with editing this post.

Posted in Hiring | Tagged , | 3 Comments

My Feminism Isn’t Good Enough for You

Or “Why We Can’t Have Nice Things….”

Nice Girl (warning: this blog contains NSFW matters, as you can likely tell from the URL) has penned a post about her experience at OSCON this year and last, and I’m really glad she brought her experiences to the fore. I’ve been watching the women and tech and women in FOSS debate rage for awhile now, and I’m so pleased someone has brought the spotlight around to a concept that I’ll call “My Feminism Isn’t Good Enough for You.”

I’ve heard from women in the FOSS community have been told that they are “traitors to the feminist cause” for wearing pink. Or that they ought not to have changed their last name upon getting married. Or that they were doing all women a disservice at FOSS conferences by wearing provocative clothing.

I think provocative clothing is in the eye of the beholder, but on the one occasion that I’ve observed this behavior personally rather than hearing about it through the grapevine, said provocative clothing consisted of spiky heels, a skirt that cut off at the knee, a professional top with a lower neckline and a suit jacket. I didn’t think it was provocative, and I was raised in a no skirts above the knee and preferably not above the ankle household. Again, eye of the beholder.

I also hate pink. However, dear sisters in FOSS and beyond, if you want to rock the pink, I celebrate you. Go for it. Enjoy it. I will enjoy your enjoyment of it, just not partake.

Here’s my take on feminism – all people, women included, are allowed to make choices for themselves and are not prevented from doing the things they’d like to do due to sexism or other forms of discrimination or harassment. Period. That simple. Telling women to lie about how they ended up at a conference is unacceptable, telling them how to dress is unacceptable, etc. All one does by telling folks how they ought to act for the good of feminism or the good of women in tech is simply buying in to the same crap that demands that one woman somehow represent all women, because we are not to be regarded as individuals, with individual choices and individual responsibility for the consequences of those choices. If someone chooses to dismiss you because you’re wearing “sexy” clothes at a conference, so be it. Your choice to do so, your responsibility to accept that some people will think less of you for doing so, and your choice to measure your desire to dress a certain way against potentially negative outcomes.

Until we live in a world where we don’t judge people over superfluous matters or have their judgement affected by socialized and personal biases – and that time is a long way off, my friends – can we all just agree that we’re adults and that folks can live with the consequences of their actions.

And if you send me something pink as a gift, you’re off my non-existent Christmas card list.

Posted in open source, Why We Can't Have Nice Things | Tagged , | 23 Comments

Keynoting Berlin Buzzwords Conference

I’ll be giving the Opening Keynote at the Berlin Buzzwords Conference in June, and I am incredibly excited about giving this talk and the opportunity to meet up with so many of my colleagues. For a brief teaser on the content of the keynote, check out the speaker interview that the organizing team has posted.

So, gentle readers, what topics would you like to see covered in a keynote on community? Anything in particular that you think I can speak very well to or that you think many communities could use help with? I look forward to your suggestions.

Posted in conferences, open source | Tagged | 1 Comment