[this interview is available online at https://s.apache.org/InsideInfra-Andrew2 
]

The "Inside Infra" series continues with members of the ASF Infrastructure 
team. Andrew Wetmore shares his experience in Part II of his interview with 
Sally Khudairi, ASF VP Marketing & Publicity.

= = =

"The nice thing is that the Infrastructure team does so much so well and almost 
making it look easy that any project in Apache that's really got itself 
organized to do its work is going to find success, because there's going to be 
no roadblock or brick wall or power failure that will keep them from it. That 
makes me feel like I'm engaged in a very small way in a very large good thing."

= = =

- Let's talk about your background and your road to the ASF. How did you become 
a technical writer and editor? What sorts of projects were you working on?

Well, let's see. I spent 20 years as an ordained minister and I was working for 
the Episcopal Church in the US and the Anglican Church in Canada. I got to the 
point where I preached my many thousands of sermons and it was time to stop. It 
was about then I moved over into QA and documentation with a company building 
healthcare software in DOS. That tells you how far back we are. One of my first 
great excitements was helping that team through the Y2K tensions. I got myself 
a bit smarter and took courses and had a lot of hands-on experience. I became 
proficient as a tester as well as a documenter. I worked over the next 15 years 
for a number of companies, large corporations, startups, and nonprofits, and 
leading teams or participating in teams, both for documentation and testing, 
but also at one point, I was the director of user experience. It was designing 
the front-end for a big complex project.

I've built applications from end to end, usually using Flex which compiled to 
Flash in the days when we could trust it, when we hadFlash to play with, 
ColdFusion for munging things around and communicating with the database and a 
MySQL database.


 - … That's a blast from the past with ColdFusion.

It's still around. There's a new ColdFusion. It's even brighter and shinier, 
I'm sure. I was just looking at it and thinking, "Gosh, I really should take a 
look at the tutorial and see if I still recognize anything."


 - I'm curious, when you tell people what you do, how would you describe the 
ASF to the uninitiated?

I would say it is a benevolent community home for a whole bunch of highly 
focused teams who are trying to do good stuff. The benevolent community home 
provides the support features that let those teams do their things without 
crashing into each other. 


 - How do you explain what you do?

Do you know the movie Fifth Element?


 - … Yes. That's a cult film in the tech community. I've only seen parts of it 
superficially, I don't know it years after so I might have to watch it again.

You were very young. Your parents probably had to give you permission to go to 
it.


 - No. I'm older than you think.

In that movie, there's a sequence when a bad guy is explaining economics by 
knocking a drinking glass off his table and it breaks and there's a mess. Out 
from the baseboards of the wall come all these little robots, one robot with a 
broom, one robot with a dustpan and one robot with a vacuum cleaner and a 
duster and they go. They run around and they clean up the mess and they 
disappear back in the baseboard. That's me on the Infra team.

I'm the little guy with the dustpan.


 - … I love it. I understand that you are also very active with ApacheCon 
--were you involved in this past ApacheCon that we had in September?

I was. I thought Royale had some things to say that could be said and I looked 
around and nobody seemed to have the time or have paid attention to the fact 
that there should be a Royale track. I said, "Oh, there's going to be a Royale 
track and I guess I'll coordinate it." 


 - … You volunteered to do that, you decided to do it, you just rolled up 
sleeves and dove it?

Well, I said to the team, "If nobody else will do it, I'm going to do it."

I was sure, I was so hoping, that someone else would say, "Oh, no, I'll do 
that," and then I'd be in a support role, but that didn't happen. I also 
engaged with the team that Rich had to put ApacheCon together, but in a very 
minor way. I didn't help as much as I felt I should have helped just from a 
lack of time.


 - … You were on the Planners list; you were involved with that as well?

Yeah, in the regular meetings and so on and testing out things like the --


 - … Hopin platform.

I have my own Hopin account now because I found it quite useful.


 - Was that your first ApacheCon or have you gone to a face-to-face event 
before?

I've never been to an ApacheCon until this one. Obviously I've never been in a 
face-to-face one because there hasn't been one since. In fact, the Infra team 
was going to have one of its annual face-to-face meetings. We were all geared 
up to do that just when the lockdown happened this year. I haven't even met my 
colleagues.


 - … That was actually one of my questions, so we'll get to that later; that's 
interesting too. Just before we leave ApacheCon, Apache Royale, you mentioned, 
for them, "it's code once and run anywhere".

That's the theory.


 - The Project is popular with folks who are programming for mobile devices and 
other applications. Is this something you're considering with your work that 
you're doing on apache.org? Is there any cross-pollination or is it completely 
on a content basis only?

I've not got to the point of suggesting that Apache as a group or that the 
Infrastructure team use Royale. One reason is that Royale is at the 0.98 stage 
release. It's really darn good, but it has some weaknesses still. I'm thinking 
that the suggestion, "Hey, why don't we use the thing which is after all an 
Apache project to power our front-ends?" should better happen once we're at the 
1.0 version.


 - … I'm all about eating your own dog food, but when you're ready, right? 
Early on I'd always wondered why don't we require our projects to use Apache 
projects for everything and was constantly told, "That's not how we work. We 
don’t dictate what projects use --they’re free to use what they want." Very 
interesting position, compared to other groups. I was just curious, are you 
coming across things on the site and saying, "Oh, Royale will be a good fit for 
this."

One of the ways that Royale could be useful would be as the front-end for the 
Apache project pages. However, the Apache project landing pages are static. 
That's their primary thing. They're static HTML pages. Royale really shines 
when you're doing data-driven pages, when--


 - … You’re developing across platforms and devices

That's right. Sally logs in and Sally sees this, that and the other thing 
because of her role on the site. The Royale-built site dynamically knows what 
to show her. Andrew logs in and doesn't necessarily see what Sally sees.


 - … That's amazing.

It's cool. I've built apps like that using Flex that were serving people in 
many different roles, doing many different things on a common project without 
this huge massive duplicative pile of code to do it with. I could do my 
elevator pitch for Royale anytime, but that's not what this talk is about.


 - … No, but it's interesting because it's about site development. I was 
curious if it impacted what you're working on.

The main difference is that Royale has more power than a project site needs. 
Pushing them to use Royale because it's an Apache tool might be requiring 
people to use a shotgun to kill a fly.


 - With the expansion of the Web and how everyone's becoming a "publishing 
expert", many people want to break into technical writing and editing. They 
want to get their hands on site content and content development and don't know 
where to start. What do you think are some good entry points? Are there special 
considerations for Open Source, specifically Apache? Is there anything that 
people need to consider doing? Are you doing something that's very unique to 
you because you're doing that for the Foundation or is this a more common type 
of job that you could take anywhere?

I'm not a super expert on anything. I think that would be probably the theme of 
my life, but what I bring is curiosity and a willingness to try to see things, 
not just from my stance, but how would this look like to someone who doesn't 
have the same preexisting knowledge that I have. Any person who would like to 
become a documentation person for something really just needs to find something 
and say, "Hey, can I write about it?" Almost any project in the Apache galaxy 
would jump on a person who is willing to help with the documentation. 

There's not a project here … well, there are a few projects that are very, very 
thorough with their documentation, but there are a lot of them where this is 
the thing that you're asking a technical developer to turn over and use another 
part of their brain and become a writer about the result of the technical 
development. That's not the easiest thing for most developers. If somebody with 
writing skills shows up and says, "I really like this cool thing you're doing. 
Could I write about it, so I could understand it better and maybe others could 
understand it better?" I think any team in Apache would embrace that person.


 - Since Day One for us, the need has always been "documentation, 
documentation, documentation", but that’s often lacking. It's a challenge 
because you want people to do what they're best at and most comfortable with 
and happiest doing … which … the majority of folks want to develop code and yet 
we have an uptick with contributors that are non-code contributors. It's an 
interesting thing to see, "Where can they find the talents?"

In the "real world", the world of a corporation trying to make a buck off their 
code, they'd have X number of testers anda build and release person and X 
number of documenters and a middle manager that would help to make all this 
stuff happen. We don't have that structure. Indeed, the poor developers are 
called upon to try to put into words what they're doing. It's just tremendous 
if we have more --I want to say code sympathetic writers, not people who don't 
have any clue what's going on, but people who have some idea. At least they can 
ask the right question and say, "How come I don't understand what you're saying 
here? I think I tried to do it and I can't do it." Then the developer can say, 
"Oh, that's because you need to be logged in here. We forgot to write that 
down."


 - … Right. The obvious missing element to it.

Well, it's so clear in front of you that you can't see it. I flew in a plane 
once, years ago. The guy sitting beside me had been on the quality assurance 
team for one of the Gemini missions, the space missions, and this was the early 
days of manned spaceflight. He told me about how they were testing the escape 
procedure if something went wrong on the launch pad and they had this 14-step 
procedure that was attached in front of the astronaut. They thought, "This 
looks pretty good. We'll go through it." Sat someone down inside the spacesuit 
in the chair and said, "There's your procedure. Do it. This is step one. Do 
this. Two, three, four, five." Step six is blow the explosive bolts to release 
the door. Boom, bang, bang, bang, bang, the bolts go. The door flies away. With 
it goes the list.


 - … Right. Forgot about that. Vacuum. There goes the astronaut too with it.

That's right.


 - … Wow: in the midst of it, you don't think about it?

Well, exactly. What I feel sad about is people who become excited in a software 
project and try to figure out how they can use it to solve their own problems 
or answer their own needs. They can't make it run or they can't make it do what 
they want and they can't figure out from the help docs how to even ask the 
question they want to ask and they give up and go away. That's a silent vote 
that we don't really hear.


 - … That is unfortunate. Unlike other Infra team members who have said to me; 
and I'm sure you read it --"everyone does everything".

I do nothing. I do nothing.


 - You're uniquely responsible for optimizing site content. Do you collaborate 
with any specific Infra team members? You said you talk to Greg. Is there 
someone you have to go to every time? Do you work with anyone else out of Infra?

I don't go to any one person because I really don't want to make that person 
roll his eyes when I contact them. It's a small team. First off, I usually lob 
out a question when I have an issue. I say, "I'm over here on page so-and-so. I 
haven't a clue what this thing relates to because it looks like it hasn't been 
touched in a few years. Who knows?" Sometimes, someone right away will say, 
"Oh, you do this and do that," or they'll say, "Oh, no. Drew knows about that 
or Gavin knows about that. Go ask him." Then I do that. And sometimes there's 
silence. Then I won't ask again on the list. I'll wait until the team meeting.

When we've got everyone on the call and it's my turn and say, "I'm stuck on 
this thing. Who can help me?" someone always steps up and says, "Yeah, put me 
down for that. I'll help you in a couple of days." All of these people can do 
everything. The codicil to that is that all day long they are doing everything. 
I don't want to be hauling on the same person's elbow all day long saying, 
"Help me with my little thing." I want to spread out my requests, so I don't 
pull away any one person too often from the essential tasks, the core tasks of 
keeping the Infrastructure running.


 - … Do you work with anyone outside of Infra or you only work within the Infra 
team to get your work done?

There are a number of people I consult, especially specifically with this 
migration off the CMS. I'm dealing with people on various projects. I probably 
have 25 conversations going on with people specific to their projects about 
what are the various pluses and minuses of the alternative technologies that 
are available or how do we even do step whatever in the list that's on the wiki 
page. Actually, I'm so proud of myself when I can actually answer one of those 
questions.


 - … How do you collaborate with everyone? Do you use certain tools or is it 
just email or Slack? How do you work with those folks?

Primarily Slack. Well, there are two things. Slack conversation is going on all 
the time. I also keep my eye out for whenever a page is updated on the 
confluence wiki Infra area. As soon as it is, like that little robot with the 
dustpan and the broom, I go and look at the page. I just scroll down it and 
maybe fix a little punctuation, change this word and that word to make it a 
little bit more cleare. Usually, I save it in such a way that they know I've 
been there. Sometimes if I'm just being really, really finicky, I turn off the 
thing that says, "Tell the team that you've done it." I'll just stealth in and 
change that run-on sentence into something more legible, but I don't want to 
draw attention to it.


 - … Is that more common than not, or …?

I'm not going to say.


 - … The "non-intrusive" thing. Describe your typical workday.

I get up around 5:00 or 5:30 and get on the Slack channel and see what's 
happening. The nice thing about my part of this work is that almost never do I 
check in and they say, "Andrew, you got to fix this." There's usually not a 
hanging message about an urgent issue. Then if there is no such hanging 
message, if I know that I have an ongoing project, like the top-level 
apache.org pages, I go and tackle the next one. That will keep me busy for many 
days to come. I keep the Slack channel going partly because, as I said before, 
I like to monitor what's on people's minds because I may say before they think 
of it, "Oh, do we need a page about that?" 

I'm only working part time, so I only have basically a half of every day 
available for Apache. I tend to do a couple hours in the morning and another in 
the afternoon and another at the end of the day. I have another job with a 
small publishing house. As I'm working on that, I have one eye on the Apache 
Slack channel to make sure there isn't anything that requires me to jump over 
there really quick.


 - How do you keep your workload organized? It sounds like you're super 
immersed in everything.

Well, I've got, as I mentioned, a job jar page. Basically, it's a long, long 
list, a checklist of things that need to be done. It's divided into sections. 
There's a section of things that need to be done for which I need input from 
other team members. Then there's basically another section where it's just 
stuff I need to get around to doing. Then if the team comes up with something 
that they think I should be doing, they're not above adding an item to my list.


 - We are familiar with that. It's like, "Oh, I left many, many, many more 
items." How do you stay motivated? What are your challenges?

This is fun. It's partly fun because the ... Let me turn this around: I worked 
for a corporation at one point. This is fairly early in my career in software 
and I realized I didn't like what they were selling. I didn't like the way they 
were selling it. I didn't like what they hoped would happen with the stuff they 
were selling. It made it harder and harder to go into work. I was very happy 
when that relationship ended. Here, I am playing around at the edges of a very 
exciting machine shop or toy workshop with complicated gears and sliders and 
rheostats and bubbling things that I barely understand, but that I can be 
helpful with.

Really, I can't see any trouble with motivation. I don't have to say, "Oh, 
really, you have to go put in your hours." It's more like, "I know, I also have 
to do this thing outside, my editing job, but I really wanted to do this thing 
for Apache."


 - … That's awesome.

The nice thing is that the Infrastructure team does so much so well and almost 
making it look easy that any project in Apache that's really got itself 
organized to do its work is going to find success, because there's going to be 
no roadblock or brick wall or power failure that will keep them from it. That 
makes me feel like I'm engaged in a very small way in a very large good thing.


 - With regard to the Infra team, you're looking at it as an "inside outsider", 
right? You're someone who's working with Infrastructure, but you're not a 
sysadmin or not a DevOps person. Is this the first time ...

My camouflage is that we all have beards. I fit in that way.


 - [laughing] … is this the first time you've been part of an Infra team, 
because usually folks with your profile are usually part of a content team or 
marketing or PR or sales engineering or some other division that's more again 
outwardly facing from an acting standpoint. Is this the first time you're 
dealing with the underbelly?

Not purely. The very first software company I worked for, within a few weeks, I 
was in charge of build and release. That was as far down into the bowels of the 
code as I was. I wanted to go with that point, but it was certainly not outward 
facing or documentation related. At another company, I was in charge of 
localization across 17 languages. Although of course, there's words involved, 
it was very much words in terms of, "Will the German for this thing fit on the 
button we have for it?" I've been the inside-outside guy in other situations 
before.


 - Cool. Website administration, as we've been talking about, running Websites 
in general changed so much over the years. What has been the biggest change or 
hurdle that you've experienced?

Purely in Website administration or in dev?


 - ... Anything for documentation, what you're doing now, and what it relates 
to administrating site content.

Gosh, I think the disappearance of paper for me as a writer is one of the big 
changes. Almost everything I do now I can do digitally. One of the companies I 
worked with, I helped supervise the transition from printed user guides. There 
was a great big room full of boxes of spiral-bound user manuals that we stopped 
doing. We moved over to a product which we could dynamically create, so we 
could create a manual for Sally and her role and a manual for Andrew and his 
role that would come off the same text source but would have different chapters 
with the stuff relevant to what they were doing. Getting away from the physical 
artifacts to me has been the biggest change in the writing world.

Remember, I work in a publishing company, when I'm not at Apache and what we 
turn out as books are very much in the physical world. I was just working with 
an author this past week where I'd send her a PDF of the very final, final, 
final, "This is the final version of the book before we go to press." She said, 
"I need a physical copy. Send me one."

We printed off this endless book and drove it to her house. Then she found two 
tiny little things that way and we fixed those and everybody was happy.


 - … That's good. When I teach media training, I require everyone to put their 
laptops away and write, even if it's on the tiny little hotel notepad, but 
write it down because your brain processes things differently when writing.

Absolutely.


 - … Some people say, "I feel like I don't know how to write anymore." That's 
such a sad situation, but it’s our reality.

When I'm doing my own writing, first drafts are always physical. Pretty much 
always. Then the nice thing then is when you move it over to digital form, even 
if you try not to, you see ways you can improve it. You're already into version 
two with a better document because you wrote the thing first by hand and then 
you write it again on the keyboard.


 - You've seen a lot of transition in this space. How do you close your skills 
gaps in order to stay ahead of everything? How do you do that?

Boy, my skills gaps are larger than my skills. I'm wonderfully good at Apache 
Flex but it's not a skill much in demand now ... If I had known three years ago 
that I would be on the Infra team now, I would have learned Python, become very 
comfortable with it, because it's a Python shop. I'm learning Python on the 
side, not in order to become a coder, but just so I know what the others are 
talking about.


 - Got it. But that's not required for you to actually do your editing work?

No. Nowadays, the writing tools are good enough and versatile enough that 
they're almost transparent. If you learn how to write in Word or on Apple pages 
and it turns out you have to write using Markdown language in Git pages, 
that'll take you 90 seconds to figure it out and then you can do it.


 - Great, so that's not a problem. Earlier we're talking about you not having 
actually met the team: the offsite was cancelled, and you haven’t been to a 
previous ApacheCon. A huge advantage for the ASF is, as you know, especially 
during the pandemic, is that we've been virtual since Day One. We literally 
didn't have to change anything in order to maintain our day-to-day operations: 
it's just business as usual. Just keep going. For you, have there been any 
advantages or disadvantages of working remotely from the team? Do you think 
your work could be improved in any way or is it no big deal?

Because that's how the team works and because the expectation is asynchronous, 
that is you ask a question and you may not get your answer until the person 
four time zones away wakes up, it's not been a big impediment to me. If I need 
to have a private conversation with someone, I know how to ping them on Slack 
and we can open a private conversation. I will say I was working remotely from 
2013, I guess. I moved from Boston up here to Nova Scotia holding on to the 
same job I had with the company I was working for. I was into working remotely 
from then and have continued pretty much without too much disruption.

When that job came to an end, I went primarily freelance. I was working with 
clients in Japan and Laos, Germany, all over the United States, South America 
and so on. Of course, I never met any of them face-to-face. This Apache 
experience ac,tually, I feel closer to this team because we're on Slack all the 
time than I had felt with many of the other teams I've worked with over the 
past decade.


 - … I love that. That's great.

We share cooking recipes. That's really important.


 - … I hear a lot about that: Infra’s cooking, drinking, and eating. I ask 
everyone this question and it tends to make folks pause, but what do you think 
people would be surprised to learn about ASF Infra?

I think ASF Infra is like the person who's not the main act in Cirque du 
Soleil. This is a big thing happening on Cirque du Soleil. Over in the corner 
is a person who's throwing two chainsaws and an apple, an egg and a baby, 
juggling those all at the same time and just doing that. It just happens and 
somehow it's essential to make it possible for everything else to happen, but 
that juggler is good enough to just make it happen and make it look easy. I 
watch what my team colleagues are doing. I'm just in awe of all the things they 
managed to do. The Apache teams are doing their things and something goes crazy 
on a server somewhere. We get an alert about it. Whoever is awake at that hour 
from the team jumps on it and maybe they call in another person. Then they 
realize it's because of this third thing over on this other server that's gone 
wrong and they fix that. All the individual project team might notice is that 
their email is delayed for a few minutes.


 - … Right. Everything else is being juggled in the background. They're not 
aware.

Juggling without dropping an egg or a baby.


 - … Incredible. If you had a magic wand, what would you see happen with what 
you're handling within Infra, with your role specifically because you're the 
only one doing that? What would you like to see change?

I don't know that I have a wish at this point. It's pretty straightforward. I 
guess I wish I could time travel back and learn Python and come back here and 
be at this point knowing Python, rather than trying to pick it up on the side.


 - What's your favorite part of the job?

My favorite part is when I hear back from people, "Oh, now I get it. I read 
that page again now that you've edited it and now I get the thing."

When something we've changed, something we've provided makes it possible for 
people to do what they need to do.


 - What was your biggest challenge when you came into the role, when you 
started? Was it a wall of, "Oh, my God"? What was it like?

I guess it was grandma's attic, trying to figure out what box to pick up first 
and feeling in the first weeks that I was working, I was afraid. I was very, 
very preoccupied with not offending anybody, with not implying that they were 
... Not correcting their writing in such a way that I insulted them. It took me 
a little while to realize of course, they are perfectly happy to have their 
typo corrected, but it was a matter of ... In the first few weeks, I was still 
feeling out my colleagues and understanding how much they were going to 
appreciate some documentation help, how much they would find it as an intrusion 
or a waste of time.


 - What is your greatest piece of advice for aspiring technical writers and 
editors coming into this type of role? What advice would you give them?

I would say ask more questions. When you're stuck, don't presume it's your 
fault. Ask a question. Someone may say, "Oh, that's because X and we never said 
X."


 - What are you most proud of in your Infra career to date?

I haven't broken a single damn thing, except one thing and I'm not telling you 
what it is.


 - All right. How would your coworkers describe you?

I think the robot with the broom and dustpan. I think they bought that one. I 
suggested it.


 - What else do we need to know that I haven't asked?

I'm a playwright. I play the banjo. For $10, I won't play the banjo. At this 
point in my career, f you hand me a banjo and a cup of coffee, I'll be happy.

= = = 
Andrew is based in Nova Scotia on UTC -4. His favorite thing to drink during 
the workday is countless cups of black tea, accompanied by homemade 
pumpkin-seed-flour bread served hot with butter.

= = =

NOTE: you are receiving this message because you are subscribed to the 
announce@apache.org distribution list. To unsubscribe, send email from the 
recipient account to announce-unsubscr...@apache.org with the word 
"Unsubscribe" in the subject line.

Reply via email to