Skip to content

Instantly share code, notes, and snippets.

### Keybase proof
I hereby claim:
* I am rbowen on github.
* I am rbowen (https://keybase.io/rbowen) on keybase.
* I have a public key whose fingerprint is 4703 0EF3 1539 E7EB 17AF 7C75 5CFD 37FA CC78 C893
To claim this, I am signing this object:
ASF publishes long-overdue Code Of Conduct
We pride ourselves at the Apache Software Foundation on our principles of "community
over code" and "don't be a jerk", but, alas, we've been slow to codify some of these
things in public. Part of this, I'm sure, is that we all *just know* how we're
supposed to treat people, and so you shouldn't have to say, right?
But, of course, you do have to say. In part because some people don't know. In
part because everyone needs to know that we consider it important enough to stand
up and talk about it.
@rbowen
rbowen / gist:070da7e07e1506c30532
Last active August 29, 2015 14:10
ApacheCon Austin
= ApacheCon North America returns to Austin =
We just got done with ApacheCon Europe in Budapest last week - http://apachecon.eu/ - and it's time to start thinking about ApacheCon North America.
We'll be holding ApacheCon North America, April 13-17th, 2015, in Austin, Texas. The call for papers is already open, at http://apachecon.com/, and we are hoping that this event will represent the breadth of the Apache Software Foundation projects.
== Organize your community ==
The most important thing at this stage in the process is getting the Apache community involved in this event. ApacheCon exists to unite our community, get various projects to interact with one another, and bring new members into our community. The best way to accomplish these goals is to ensure that your project has representation at ApacheCon. Here are four specific areas where we need the help of Apache project communities:
@rbowen
rbowen / apachecon_austin.md
Last active August 29, 2015 14:10
ApacheCon Returns to Austin

ApacheCon North America returns to Austin

We just got done with ApacheCon Europe in Budapest last week - http://apachecon.eu/ - and it's time to start thinking about ApacheCon North America.

We'll be holding ApacheCon North America, April 13-17th, 2015, in Austin, Texas. The call for papers is already open, at http://apachecon.com/, and we are hoping that this event will represent the breadth of the Apache Software Foundation projects.

@rbowen
rbowen / alwaysdoneitthatway.md
Last active August 29, 2015 14:10
We've Always Done It That Way

We've Always Done It That Way

From a Lightning Talk at ApacheCon Budapest

As you know, the Apache Software Foundation has a number of mottos that we like to use. Like, "Community Over Code", and "No Jerks Allowed." Another popular motto recently has been "We've Always Done It That Way."

As you no doubt know, the ASF is an organization deeply rooted in tradition, which means that we never, ever change the way that we do anything. Those of you who have been around the ASF for a long time can verify this.

Here's a few of the things that have been the same at the ASF for all time.

@rbowen
rbowen / apachecon_budapest.md
Last active August 29, 2015 14:10
ApacheCon Budapest report

ApacheCon Budapest 2014

Last week, the Apache Software Foundation, with the help of the Linux Foundation event team, hosted ApacheCon Europe in lovely Budapest, Hungary at the gorgeous Corinthia hotel.

If my count is right, this was the 24th event to bear the name 'ApacheCon', and the 8th time we've done it in Europe. Also, we were celebrating the 15th anniversary of the Apache Software Foundation, which incorporated in June of 1999.

Every ApacheCon has its own set of memories, from Douglas Adams pacing the stage in London, to the ApacheCon Jam Sessions in Dublin, to the Segway tours in San Diego, to the funeral march in New Orleans. And Budapest was no different - a wonderful event with lots of great memories.

On Sunday night, I had dinner with the TAC'ers. The Apache Travel Assistance Committee is a program by which we get people to ApacheCon who could otherwise not afford to be there. This is critical to the mission of the ASF, because it builds th

@rbowen
rbowen / betterfm.md
Last active February 5, 2017 09:15
RTFM? Write a Better FM

RTFM? Write a Better FM.

Have you ever noticed that the communities where you’re told the most frequently to RTFM - Read The F* Manual - are the same ones where that manual is likely to be awful? I believe that this is, in fact, not merely correlation, but also causation - that is, the attitude results in the poor docs.

The Setup - Why we need a better manual

There’s a few commonly held beliefs about documentation for software, and in particular open source software: 1) It’s awful, 2) Nobody ever wants to write it. 3) That’s just the way things are, and we can’t do much about it.

The reality, however, is that there are lot of people that want to write documentation, and we, the gatekeepers of open source projects, just make it too hard for them to do it. We put up artificial social barriers. (For example, the myth that documentation is a somehow less important contribution than “real” code.) We put up strange workflows. (Get a checkout. Make your changes. Make a diff. Subscribe to a mailing list. Sen

To: rdo-list@redhat.com
In Paris, we talked about what we might do to get more of RDO testing/ci out into the open, and a great opportunity has arisen out of that conversation. You can read the full details on the centos-devel list, at http://lists.centos.org/pipermail/centos-devel/2014-December/012454.html
In short, this is an opportunity to move some or all of our testing/CI onto community infrastructure, and get more engagement from the CentOS community, as well as make it easier for you, the RDO community, to participate in things that have, up until now, been handled mostly by people inside Red Hat. This is what you told us, in Paris, you wanted to have more access to and visibility into.
If you're interested in participating in this effort, please have a look at http://wiki.centos.org/QaWiki/PubHardware , get subscribed to centos-devel - http://lists.centos.org/mailman/listinfo/centos-devel - and jump in.
--Rich
@rbowen
rbowen / mentoring.md
Last active August 29, 2015 14:10
Mentoring in Open Source

Mentoring in Open Source (And everywhere else)

I have been working on the Apache http server for almost 20 years now. I've written 9 books about httpd, and spoken at more than fifty conferences. I'm a member of the Apache Software Foundation, where I serve as a board member, and as the Executive Vice President. I am responsible for putting on ApacheCon, both in North America and Europe, which is the official conference of the ASF.

Each of these things, I do because someone encouraged me to do something that I knew, deep down, I was incapable of doing, and then cheered me on as I did it.

Direct, intentional mentoring is 100% of the reason that I am where I am today, professionally and personally. I very literally owe everything to the people who have mentored me over the last 20 years. And over the last 5 years, I've very intentionally mentored some other people, to pass the karma on. Whether they're all aware that I've been doing it or not isn't really important. I have specific reasons why I think that

@rbowen
rbowen / packaging.md
Last active August 29, 2015 14:11
RDO Packaging - blog post

When we started the RDO project back in April of 2013, the main focus was on producing a distribution of OpenStack that made it easy to deploy on CentOS, Fedora, and Red Hat Enterprise Linux. While we put time into making it easy for the community around that distribution to grow and support itself, most of the technical work was done inside Red Hat, and there were parts of it that weren't very visible to the community.

It's time to prioritize opening up the RDO development process, and making the technical governance of the project available to the entire community.

https://www.flickr.com/photos/rbowen/15981888051/

A month ago in Paris, at the OpenStack Summit, 40 or 50 RDO enthusiasts gathered to discuss the RDO community, and what we can do to make it more inclusive. The number one thing that was asked for was more documentation around the process, and transparency into the CI results, so that everyone can see what's going on, and know where they can jump in.

Our first step in this direction is to docu