Yeah, we on boss talk one-on-one. Yeah, we gonna talk I want to talk about your the comedy I want to talk about How you came up with doing the skits the way you do how you and and what because you've driven the numbers up You got over how many subscribers on YouTube? 320,000 and then also Just how do you like I know the people change the girls that do the skits with you the guys that do the skits with People changes this relationship driven. I'm just trying to understand where did a sense of humor come? Yeah, just give it give us a spell man. Give it up like how I got into yeah How you got into it and then we're going to the other side of our doing music videos for people I started doing music videos for people so I would do music videos for Courage shows are IP course me and his brothers just on here. We gave him a war.  I moved from The overton side to Woodtown.  I was a meek meek meal. Yeah, and then uh, I used the Tupac and Biggie um From the movie scene where he was like your boy tripping Yeah, he's like who and now instead of making him say pock I made him say Drake and then he got in the car and he put the tape in but instead of having hit him up I had two of the fingers turn And then I had him like oh, here's no no like like, you know, yeah Yeah, and then it just took off then everybody start following me and I was sensation on Facebook at the time me and Roy Lee. Yeah, both sensations on Facebook at the time RIP Roy Lee and um That's how it happened like that's how I start, you know getting off into the video Well, so how would you did you already know how to monetize and all that? I didn't know none of that's what I was thinking so you were losing money So I was losing money damn sure was how long does it take you took to edit and do all that video? The voiceovers and all of that. How long does that take so like if I was to do like a Video like of something or I edited probably take me like 15 minutes And I have it up like the same like if I take this all this right that I had it's up So quick like it'd be just that quick with the editing cuz it's just like I know what I know how I filmed it So I know how everything goes. I could just drop it and maybe it'd be done Yeah, but the dope part is that you able to understand the algorithm now most people don't Still don't understand it how it's a machine you're not gonna never fool Yeah, damn thing. Yeah, cuz it's like I was I was viral on Facebook at one point of time and now On YouTube like like so it's like how did it switch over? I don't even know how I switched over I know one time I had the option of going live on I put my videos on YouTube because Facebook would do things like People will hack you. Yeah, so I said, man, I could end up losing my videos Yeah, I know anybody you hacking on YouTube and then like that, you know, like it's a different type of count like so I said, let me just take everything and put it on YouTube. Mm-hmm. I put everything on YouTube and Like a few months went by I looked at my YouTube and I say this video look like you got a million views like that I said I Said baby come out dating this other chick at the time like we was like YouTube Love co-stars.  I said, no, it's no way to this video I ain't just not I just not did this video not too long ago. It's no it must be some type of mistake I kept doing it saying it's a mistake. Are you monetized at that time? No, he's losing money. I'm telling you I didn't know I went down and I started like Scrolling and I started going into the settings and stuff like that And I'm like, bro, this thing really then it said hey, you are eligible for like money. Yeah, it started telling me Everything start telling me like like I'm like it told me his own self. So I'm like, that's crazy. Like what is this? I don't even know what month I'm like, what is this? So I click on it I signed up for it and everything like that and I started getting checks and stuff like that I'm like, wow, like I made like but since the biggest check you got During that time the biggest check I ever got period Like in one check probably like 50,000 like in one check stop playing niggas better stop playing Better get your camera. You hear the niggas say 50,000 in one month. Yeah, we on boss talk one-on-one Yeah, we gonna


So, our speaker for today is Anne Marshall and she has 11 years of experience as an academic librarian and was most recently the subject liaison to the political science department at the University of Rochester. She has provided computer training and support to upstate rural public libraries as a part of the Gates Foundation grant. She is co-author of what an experience library staff participation in ethnographic research and is a former chair of LPSS. So, Anne, thank you very much for joining us today. And I'm going to hand it over to you. Thanks, Linda. Welcome. Thank you all for being here today. So, there are a couple of resources available associated with this presentation today. First the slides and also a resource list. And I've broken down this presentation into four parts. And then as time allows, there's some more resources at the end of the presentation. The place we're going to start is with some interactive tool, some math, which seems very apropos for environmental resources. And in this first section, you know, kind of my thinking is, well, you know, I've got an undergraduate who wants to do a project and doesn't know where to start. So, that's kind of my pitch for this first part. And then for the second part, I'm really going to focus on the data sets, how can I identify and download some environmental data sets. Thirdly, I'm going to take a look at a couple examples from the scholarly literature. And, essentially, that's the way I tend to find data most of the time and look at who's published on the topic and find the data that way. And then finally, I have some resources that are more about kind of things that are going on on campus and some curriculum ideas. And then finally, I'm going to focus on the interactive tools. So, the one that I spent the most time with was the EnviroMapper, which comes from this EnviroFac data warehouse. And to get started with this, it's brilliantly simple. The zip code, or other geographic information, and I did that, and I was given this very nice map. The zip code I chose just to show you the sense of what you're looking at here is Mount Morris area, which is about 30, 40 minutes south of Rochester, New York. I wanted to point out this basemath link, which gives you a full variety of different views to consider. The way that I found was most useful to get into the information and to get a nice kind of visualization of it is to search EnviroFac and specifically to search by program. And if you do that, you'll get this nice graphic at the left-hand side that lists the various programs. And you can see we've already got some very basic kind of statistical information here. This is telling us that in this mapped area, there are 140 sites that are connected with hazardous waste, 16 sites for toxic releases, and so on and so forth. Then the next thing I tried in here was to add data. So you can sort of add supplementary layers. And you've got a variety of options, places, transportation, water features, and so on. I went ahead and added school. And then I also took a look at the water feature. I found that if I added water bodies and streams, I would get a bit overwhelmed. So I chose impaired waterways. And so now you can see with that graphic pool and also for the impaired waterways. So what I did next, let me go back, is as you can see, we've got all of these blue eyes in circle for really every single indicator on this map. And so if you click on those, you're going to get a lot more information. I did that for impaired water bodies. So just let us know that impaired water bodies are those that have excess fluidity and are not clean enough to support recreational use. So then the next thing I did is I went back to this left-hand program data. And I chose just one of them, the hazardous waste sites. Those were added, and you can see they're now indicated on the map in green. And if you hover over, you will, at least for some of them, for the ones with numbers, one here that I chose, Kelly Logan. And so the idea here, kind of from an undergraduate perspective, is to kind of think, well, what kinds of questions might this be generating? And why does the EPA collect data from Kelly Motors? And here I have, I just Googled them. And so maybe for an undergraduate this may kind of provoke some ideas. Then I also went into the eye for hazardous waste. I thought this was useful in that, you know, we can kind of get connected to the policy dimension of this issue. And it's helpful to think about why the EPA is collecting the data that it is collecting. And so this is telling us that this particular information that is collected has been done so under the Resource Conservation and Recovery Act. So specifically that legislation or that regulation requires data to be collected in connection with those that generate and support treats for and dispose of hazardous waste. On that previous page, there was a link where you could go look up by facilities. And that worked. I personally found this website to be a little bit more intuitive and that there was more information. So here we can search again by this code. So I went ahead and did that. You can see we get the same visual information. And here at the right-hand side, we're now getting information about the extent to which these various entities are in compliance or not in compliance with the regulations. In fact, you can see that we've got two facilities here with violations in the last three years.  So here, for example, we have the Mount Morris Dairy Farm, which had an issue with not being in compliance. And you can go into these reports and take a look at what some of the issues potentially are. So I went back and searched by Kelly Motors. And this certainly has this experience as well, where you may not get a lot of information, but you find, as it's listed here at the bottom of the screen, that there was no violations. So it looks like Kelly Motors is doing or has done what the EPA has asked them to do. And so I throw in a slide here, LiI, which many of you may know about, but just again to make that connection between the data and the legislation. And the reminder that when you encounter things that, you know, what the heck does this mean, that a resource like this can be very, very useful to put the data in context. This next tool, EPA and my environment, works in a similar way. You can put in locations. And as an example for this one, I searched this time by county. This is a little comparative analysis I did. I searched by Monroe County, which is where we are in Rochester, New York. And then I, for comparison, I searched by Los Angeles County. And you can see just visually here with the green and the yellow, that we've got some differences between the two locations. I've just blown up some of the data here so that it's a little bit easier to read. So Los Angeles County has over 2,000 hectic releases in Monroe County. We've got about 188. You can see the big differences between the ozone level between the particulates about three times as much. It's possible to just very quickly do some kind of interesting comparisons by location. They also have a My Health tool here. And so again, I did a comparison between Monroe County and Los Angeles County. I thought it was interesting that in Monroe County, even though with all those differentials, we actually had a double the level of benzene as compared to Los Angeles benzene. So that was, I thought that was kind of interesting. And then I threw in this slide from the census because it kind of has been, again, providing context to undergraduates. It's not, it's likely that one of the reasons for these big differences is check it out the population density. Not surprisingly, it's much, much higher in Los Angeles County. So it may be that in Los Angeles County that their ecological footprint is much smaller in Monroe County, that would take a bit more research to figure out. The other screen I wanted to, or a resource I wanted to point out was that the EPA has a number of apps for smartphones on their site. Here is a portal to 290 apps about the environment. So there's lots of stuff to experiment with here. That is the end of that first section. It's actually getting into the data. In the environmental tool, there is a download option. What was going on? And we had a question about my health tool feed. Is my health tool allow you to collect health data in the environmental section? The first thing I wanted to show you is just to take a look at some of the reports that are posted. And so they have one that they recommended right up front here. You know, I'm trying to kind of do some comparable data stuff to what we looked at from the map. So here we're given both Excel file at the top. And then we're also given PDF at the bottom of the page. I took a look at the one focus on where you live. Just a quick tip I wanted to point out for these Excel files. It turned out when you open this up, the default page is the note page. At first I was like, is this all there is? But if you go down to the, you know, this is an Excel thing. You know, I've got a bunch of other tables in here that you get to buy the options at the bottom of the Excel screen. That was important in this instance to take a look at. The next thing that I looked at, which I think is useful for this particular example, but will be useful for other examples as well, is that the EPA does let you create your own customized data set. You know, I'm familiar with like the IMF and World Bank tools. Maybe not quite as sophisticated and powerful as those tools, but there's still explaining data in here that you can compile into your own customized table. So this first one is FRS data. And that is focused on facilities. So like we were looking at for the hazardous waste sites. For step one, the first thing to say or ask you to do here is to look through. And you have to choose between one of these types of information. You can see we've got things organized by SIT codes, SIT codes, program coordinates. I tried a couple of these. I personally found that one at the top to just seem like it had a bunch of variables in it. So I tried that one. So after choosing your options, which of the tables you want to look at, then it comes up and gives you all of your variables. I thought this indicator at the top for not, you can see in red, do not select the column located directly above if you select this column. I think what they're telling us here is this is just querying, this was maybe an access database. So if we want the count feature, we shouldn't also select this other feature. And so I just, what I did here was search some kind of basic location and facility information. And then if you scroll down, you can see there's a number of other variables as well. I'll just draw your attention to one here at the bottom. Because they seem the most kind of meaty in terms of being in a substantive variable. There's one here about the ozone. I chose one about particulate matters, how much stuff is in the air. They tell you here it comes from the air green book. And so now we're on to step three. So I chose my general area, broad category that I wanted. And I chose my specific variable. And now I'm able to narrow it down. At first I chose here, you can see I just chose New York. And then I chose to output to CSV file. However, when I did that, I went above their maximum result list of 100,000 rows. So then I had to go back. So I just to keep it simple, I narrowed it down to this code. I got a very manageable table when I did that. And you can see that for this particular set of locations, I didn't actually have data. For this EM25 2006 area name. So it looks to me like that means we didn't have... This was not a location where there was that particular issue. Okay, so having gone through those three steps, it looked to me like that kind of customized search is available for a variety of different types of data that the EPA offers. Under the air category, we could do a customized search for greenhouse gas data. Same for water discharge permits, toxins, and also radiation. It is a kind of option and process that seems at least somewhat similar across these different types of data. Also, if you scroll down from this introductory information, you get an annotation about the data itself and what you'll find in that section. Another thing that seems potentially useful from the EPA's website was the data finder. I should also mention here that there are options to search across. You can see here that there's lots. Kind of the scenario I was considering was, let's say I don't know what I'm looking for. And so one could certainly search if you've got a particular specific topic or collection of types of things that you're interested in finding. I will say that as I start to play around with some of these links in here, it looks like some of the links may be the one I tried. It looks like either it was a glitch or a couple of links may mean updating. In other words, that was my experience. So the next way I tried to get into some of this data was data.gov. Some of you may be quite familiar with this. I believe this website went live in 2009 and then got a new interface in 2010. So it's still somewhat new and it's really grown exponentially in terms of the number of data sets that are here. The one that I experimented with was ecosystem. And you can see they recommend some data sets to take a look at. The one I tried was the Biodiversity Resource Hub. And again, we're taking to a map. To make sense, we're looking at environmental data. We're given a map as a way to get into the data. There's a lot one could spend time with here. I just gave you a URL to a PowerPoint that I thought did. And I seem to do a nice kind of overview of how to navigate through this particular site. They also tell you in that PowerPoint much of the data for that project you can find from this source. They recommend, as you can see, there's 14,000 data sets here. So that's another resource to know about. So then I came back to data.gov and I said, okay, let's take a look at energy. We'll also then take you to a variety of options, including data. And there are 413 data sets that you can get to through the Department of Energy's Data Catalog. Okay, let's jump into searching the scholarly literature. Like I said earlier, this is the way that I typically look for data. So I'll give you a couple examples about how I've gone about that. So I just, you know, here's a search from an EBSCO database doing academic search premier here. You know, I think even faculty and graduate students don't often search like this. You know, as librarians, we're able to do these sophisticated searches, which can lead us to some excellent data resources. I threw in the state keyword there because I was trying to think about, well, how can we come up with some comparative data across data? So here's one that was good to me, scaling, you know, two emissions in U.S. urban areas. And of course, if we just flip through the pages of the article until we get to the methods section, they tell us here right in the first sentence where their dataset comes from. It comes from this thing called Project Vulkan. And of course, if we just Google Project Vulkan, up comes the dataset. And I thought it was kind of interesting here to see this is a project that is constituted on Arizona State University's website. But in some respects, it's government data in that it's not created by government entities, but it's funded by both, in this example, by both NASA and DOE. So that's one example. I also did a Google Star example. I actually searched in this one for the name of the agency. One of my little tricks I like to use is to actually search for the term table. I figure, you know, if I pull up an article with that 20 tables in it, or the table is mentioned in the text of the article, maybe I'm a bit more likely to get some really nice data-rich articles. I picked out one about greenhouse gas emissions. And for this one, I just went straight to the bibliography. There's the annual energy outlook, how available that data is online. If we Google for it, the 2015 report is available, both in PDF and Excel. If we look around a little bit more, we can see that they also have a PDF archive. A couple of tips about remembering. We get a lot of information just researching scholarly articles. And next, I wanted to show you some resources focused on college and university campuses. As a way of thinking about, you know, what's happening on our own campus, where as librarians, might we do outreach or target our services around government information and data?  And how might we make connections to build upon our own programming and offering? The first resource, some of you may be familiar with this, is that the Princeton Review has a guide to green colleges. They have, this is just one example, nice write-up about each institution listed within the guide. And also has just some, you know, information that is in all of the existing guides. And then they add in some information, the physical information that is specifically on environmental issues on campus. So this is, there's a lot of really nice rich information in this guide. You know, another way kind of into this topic is to actually, you know, look at what the NSF is funding and an entire environmental sustainability program within the NSF. You know, of course this is useful for us to know about for our faculty and also, you know, a way to figure out what projects are going on now that it's both using available data and also will be generating data. I also just pulled up a couple examples related to specific things that are going on various campuses. So this is an example of a syllabus. And I thought this one was particularly useful in that it's a class that you can see focused on research and focused on environmental research.  And then this other, this next slide, I really enjoyed looking at this guide, how you can see through this guide that there's a connection between the assignments and then between the resources that we put together around the class. So I thought this was just another nice example for thinking about, you know, how to make the connection between the curriculum, between what we do as librarians and all of the resources. And that is the end of the formal presentation. So are there any other questions at this point? An international resource that has been recommended and is quite impressive. Is this the World Resources Institute? What I liked about their offerings is, again, they have a very rich collection of data visualization tools that are then also paired with data sets. This is just an example of one of them where you can visually see coral reefs that are considered at threat. I can just very quickly show you how that works. You can see that they've coded different areas by color. And then here you can see in this visual at the right-hand side of the screen that when you've got the blue, the clear color that's considered at low risk. But then as you move up to the more intensely red or black colors that's considered at most risk. And so the area that I chose to look at was south of Florida. You get a very nice visual here to get a sense of what some of the issues might be. And then you can go back in and you have data in various formats that you can then use in Google Earth and other applications. One of the things about environmental issues, China comes to mind. I thought this site was also rich and useful in terms of this offering. And it's just one example. And I thought what was interesting about this is that you see the same kind of issue about trying to get a sense of what collecting the data, what is the potential oversight with what they call supervision records. Even in a very politically different environment than in the U.S. I thought that that was a useful comparison. And here's just, this link is on your list of resources that give some background about this particular data set. Here's an example from the European Environment Agency. They have a number of data sets. The one that I looked at was nitrates and riverings. The question earlier in the presentation was about more regional data. And actually in this, for this data, that's exactly what they've done here. They've given signs of broader categories to the data. And in terms of looking at the specific zip codes, again, there's a data set that goes along with the math. One can keep going and going with these resources. Some others that I thought were particularly interesting intellectually, but also to make a really clear connection to everyday life is the soil survey. There are interactive features of this. So I haven't done it here, but you can see at the bottom of the screen there's four basic steps you can go to. Many of you are probably familiar with the National Conference of State Legislatures. I just wanted to point out that this also is an excellent place to go to see the environmental status of various legislation across the country on a state-by-state level. So I've just shown you here 2013 Efficient Building Legislation as just one example. A number of resources focused on water, unsurprisingly. So here's the website about Watershed, the USGS. What's so great about this site is that you can get real-time data, flood data, drought data. There's lots of things one can do there. We have just the end of the slide. Are there questions?


All right, we're getting started. Hi, everyone. My name is Jared. Welcome to Valencia. It's really nice to be here. The last time I was at a KubeCon was in Copenhagen. So it's so good to see so many faces here. I'm here to talk about sharing knowledge, writing good docs for quick review. And for folks who are following along, I posted a Bitly link. It's public. It's Bitly slash KC-EU. Let me see if I can remember this. KC-EU-Docs, if you'd like to follow along, just for your own reference or for accessibility. But just to introduce myself and my passion for documentation, I'm a software engineer by training. But I've been a technical writer for almost 20 years now. And the majority of that has been at Google. My focus primarily has been on open source documentation with a pretty heavy emphasis on Kubernetes. So I helped lead the initial Kubernetes docs team. I was one of the first docs chairs as part of SIG docs in Kubernetes. And I helped lead that group for about five years up till about 2020. So I have a lot of knowledge about documentation. And I have just a deep passion for great docs that are accessible, that are easy to write. So a bit about the importance of documentation, if I can convey to you some of my passion about the subject and why it's so important to me, it's that the vast majority of developers want great documentation. They want it to be accessible. They want it to be inclusive. They want there to be clear processes and policies for documentation. And it's a key decision-making factor when people are choosing which open source or even closed source project they're going to go with. Most people, most developers prefer documentation to contacting supports or talking to an actual person. They want content that they can search, that they can understand on their own and approach at their own pace. And most developers see documentation and its incompleteness or its lack of existence to be a huge problem in the community. So I want to talk a little bit about a story that's pretty common to my experience when it comes to reviewing PRs from the community for Kubernetes and from various other open source projects that I've worked on. And this is a story that's about speed. It's about how quickly can you get a PR in for documentation? Because this is what most of us are focused on when it comes to writing. We've already written the code. We want to get the documentation in. We want it reviewed as quickly as possible and we want to be done with it. So I'm going to introduce you to two characters who are working on documentation together on an open source project. Our first character is Tony. Tony has just finished writing a feature for an open source project and he is about to crank out a docs PR. And our other person is Maria. And Maria is a docs reviewer who is here to, she's a senior developer on the project and she's reviewing both docs and code PRs for this project. So starting out, Tony's written this code. He has some docs that he wants to write up, send it out as a PR, and his goal is to do this as quickly as possible, like I said. So what does he do? What do most developers do? Well, we copy and paste, right? We find a good document that we like, we grab it, throw it, the mark down into a new file, pull out some of the content that exists there, write up some new ones, create a new PR, fire it off. Now, Tony might not be thinking much about what his audience needs at this moment because his focus is on speed. So he might write this PR as something that he focused on in the creation of his own code. And this is something that I think we all do. So Tony might write this PR of I created this new feature. This new feature had these difficult design decisions that I made. Here are some of the things that I decided when I wrote this and the code for it. And this is a really interesting technical challenge that this code solves.  And Maria now, well, Tony and then waits. Tony waits and waits and waits and waits for a response from whoever's going to review this PR because he might not know who's going to review it. He might not have read any of the review processes. He might not know anybody in this project. So he sits and he waits. And Maria then takes a look at the PR and she might not know who Tony is. And so she starts reading the PR and she thinks, what am I supposed to do with this? Who is this person? What are they writing about? Maybe the documentation PR is separate from the code PR that Tony filed. So she doesn't know that this code already exists, what it relates to. There's no context. She doesn't know what she's supposed to be reviewing and why beyond the PR that she's received. So she suddenly has a ton of questions. And those questions she sends to Tony. And it's a barrage of questions. What is this? Why are you writing it? What's the specific focus? Why did you use this template for your documentation? And Tony takes a step back. He says, whoa, why do you have all these questions for me? I thought it was pretty clear from what I wrote based on my knowledge of the feature that I created. So churn happens here. And this churn can take weeks, sometimes months to solve where you have back and forth between the PR creator and the PR reviewer. What feature is like, wait, what are all the questions that you have about this PR? How can they all be answered? And my goal in this presentation is to give you some tips on how to stop this from happening. How to set context at the very beginning and how to prevent yourself from getting caught into weeks and weeks and weeks of PR churn where you as a PR submitter think that you were creating all the context for your reviewer and your reviewer is confused and sending you back tons and tons and tons of feedback that might not be appropriate or might not be useful for you.  This is actually a story about collaboration and empathy and planning, which in turn leads to speed. So with a few tips and tricks in your back pocket that you go into writing a docs PR with or reviewing a docs PR with, you can make this process much faster. Change weeks of review into just a few hours. So let's start this story over again. Tony finishes writing his code for his feature. He wants to do the right thing. He wants to write a docs PR with associated content so that users can use what he's written. So he takes a step back and he looks for some documentation about how to submit this docs PR. Now hopefully your projects have some of this documentation, but if not, there's a link for Kubernetes process which you can borrow from, scale down to whatever you need. And if you need to scale it up to pass to what Kubernetes does, just grab me after this talk and we'll chat. I'd be really interested in what you're building. In this process, your project should have documented how to submit a docs PR, what flavor of markdown you're using. Are you applying any specific style guide? Are you using the CNCF style guide? Are you using somebody else's? Are there any templates that you're using? Any tooling? You can write maybe half a page, even less if it's just a small project or read me, just hey, docs go in the same repo as the code, here's where they go. But if you have a larger site that you're using, then having a document that lists some of your process be incredibly useful for people who are writing docs PRs. This is just a pet peeve of mine so I'm just gonna toss this out there. But Tony signs the CLA. So this is something that holds up a tremendous number of PRs. Both code and docs, I see it a lot more on the docs side where somebody comes in, they make a docs change, they don't sign the CLA and then suddenly we have to chase them down. Go find them on Twitter or Slack or wherever. It's hey, please sign the CLA so we can merge your PR. And sometimes it's really hard. Sometimes we don't find people. So PRs will just language without the CLA sign. So please, please, please sign the CLA. If you have a similar process for your project, make sure it's clear that people do that. Next step, create an issue. I like issues because they help track the documentation that we're creating, especially if it's a larger documentation set or a larger doc that you need to write. But the importance of the issue is that it creates context for your reviewer and for the public at large, why you're writing this documentation, who it's for. So when you write, when you create an issue, it's important to start with who your audience is. And this might seem daunting, but really you should spend maybe 15 minutes on this. Like, just take a step back, and this is what Tony's doing, is taking a step back saying, who is my audience? What do they already know? Maybe this is a new feature for something that a new user of the project is going to use. So it's like, okay, you might not have a lot of context for this project. So let me start with your developer, you're coming in the door, here's the project, here's my new feature. But understand what your audience already knows and what they're going to learn from your document. And just write that in your issue, maybe two sentences. In addition, if you're writing more than one document, you're gonna be writing an extensive set of documentation, make a plan, just make a checklist of here's some of the docs I'm going to create. I'm going to create a procedural guide for using this new feature, step by step, one, two, three, how to use it. And create a conceptual guide that's like, here's what this feature is, here's how it works. Here's some of the considerations you should have when using it. Maybe you split that up, maybe there's an additional reference. Regardless, it's useful to just list a few bullet points of what you're going to build in this issue. And last, it's a good place to CC your potential reviewers. So maybe that's somebody in zig docs like myself, or maybe it's a reviewer on the project. Give them a tap on the shoulder. Hey, there's some documentation coming your way. I'd like you to review it. This is just a way for you to sort of start that initial conversation.  Now there's a ton of books. I've written a book myself on documentation and how to write it well and how to focus your content. And I'm not gonna go into all of that here, but let me give you one golden rule for writing great documentation for your audience. And that is simply to write it in second person. And this sounds maybe too easy, but if you take a step back from what you're writing, like what Tony was writing with, we built this feature because we made these design decisions, that's not very useful for your users. What's better is this feature was created for you to do X, whatever it is. State it from their perspective, write it to them, write it to you. The other points in here are very useful as well. I'm just gonna gloss over those, but that writing in second person is the most useful thing you can do. Keeping it in present tense, don't focus on past decisions or future decisions that you're going to make. Like your user documentation is not a great place to put in your roadmap. So just like, don't talk about your next feature release in six months. Like, mm, keep it focused on what the user can do right now in this moment with what you've created. And of course, you can break out chunks, keep it readable, keep it skimmable and focus on like existing templates and style guides. So give a quick example. This is a very, very, very, very, very old paragraph from the nodes page in Kubernetes. And I'm not gonna read the whole thing, but just that first sentence. We built Kubernetes with the concept of nodes which run pods, which in turn hold containers. So this paragraph is trying to do a lot, but it's also written in a way that describes the person doing the coding not the person using Kubernetes. So just to call out a few specific things in this paragraph that you can apply to your writing. Look for places where you say we. Try to get rid of them. If you're introducing your concept like nodes, maybe you should call it out in some way. If you're starting to list, like this whole paragraph is trying to both introduce the concept of nodes and say everything inside of a node. Maybe that should be another paragraph or another page. Like look at places where you can simplify, but start with looking at places where you're not speaking directly to the user. So here's it rewritten. Kubernetes runs your workloads by placing containers into pods which run on nodes. Like, ah, doesn't that feel so much better? Like write it to your users. Start with you. And I encourage you to just use you in your writing all the time when you're writing developer documentation. It will improve your writing quality 100% overnight. So when you send your PR out for review, the most important thing you can do is to specify what kind of review you want. Tell your reviewer what you want from them. Set some context. In addition to the issue that you created that tracks your document, let your reviewer know, hey, maybe Tony knows this feature incredibly well. He wrote it himself. He doesn't need a technical review. But maybe he's uncertain about his documentation and would like a review for editing content and clarity and consistency. So it's important that he specifies that when he sends out the PR. Like, hey, I would like you to review this just for documentation clarity. In Kubernetes, we use tags to track this. So let's say you wrote a networking feature and you want somebody from networking to review it. You would tag it with SIG networking or SIG network. And somebody from that group, from that SIG group would jump in and review the documentation, make sure it's accurate from a networking perspective. It's what we call a technical review. Now, if you want a docs review and you just want somebody from the docs team or somebody who's knowledgeable about content to review, give you a peer edit, copy edit, what you've written, then you might tag it just SIG docs. All of our docs go through docs review. Not all of our docs PRs go through technical review. But most of them do. And we focus it on specific teams because we set the context of what kind of review we want from all of our PRs that come in. And from the reviewer's perspective, it's important that you have a rotation for reviewing. Let people know how often you're going to be reviewing your content. As docs PRs come in, are you doing it on a weekly basis? Are you doing it on a daily basis? Is there somebody on the hook for doing that? Creates a rotation to make sure that these PRs are reviewed on a regular cadence.  You end up with a lot of duplicate issues that people are trying to address. It's best to just nail those out as quickly as possible and have it on a regular cadence. And when you give feedback, make sure it's actionable. Documentation is not as clear and consistent as what's good and what's not. So if you give feedback, say like, hey, this sentence is unclear, here's a way to improve it. Specify exactly what you want. And if you're unsure or it's just a nitpick, call that out as a nitpick. Hey, this sentence is a little clumsy. Just a nitpick, you might wanna consider fixing it. Doesn't have to be perfect. The goal is good docs, good enough docs. The goal is not perfect documentation. And it's important that good enough documentation gets published on a regular basis and updated rather than you hold something back and wait for all the perfect changes to be made to this PR before you allow it to be merged. We do, it's okay to write a reviewer guide. We have one for Kubernetes. I highly recommend people apply it to their own projects if they wanna borrow it, but it basically says, here's what we look for when we review a docs PR. And there's a link to it in this presentation. If you grab the presentation, please have a look. And then last, as feedback goes back and forth, it doesn't need to be confrontational. Like feedback should be a conversation. When your reviewer, if Tony sends out a PR and Maria reviews it, Maria might not have all the contacts that Tony has and might ask for things that Tony is like, you know, I could reward it that way, but that's not as accurate as what I originally wrote. And it's fine to say that. Just keep it conversational and keep it professional, keep it constructive. And of course, like once you're done, celebrate, merge your PR, there's any cleanup that you need to do, do it, close your issue, easy. Give yourself a pat on the back, you're done. Now, throughout this process, this might sound like a lot, but these steps shouldn't take you very long to do. So I just wanna emphasize that. Like taking half an hour before you write a docs PR to jot down an issue, make a plan, ping the reviewer, CC them on the issue, before you start writing, will save you weeks of time in the review cycle. And it will make for better documentation and a better review experience. So some items just to take away for doc writers out there. Let's do, you know, research the doc writing process first. Like take a look at what is available for you to write your docs PR before you start writing. Write things, create an issue to track your audience and what they need and any plans that you're making for your content. You have signed the CLA, of course, but understand like what your audience needs and write to them. Write in second person, use you when you're writing. Avoid we, avoid I, avoid talking about the design decisions that you made and speak directly to your user and what they need. And specify the specific kind of review that you want from your reviewers. Do you want a technical review? Do you want a content review? Do you want both? You might want both. It's totally fine to ask for. Might come from two different people. You might add two people to your review. Totally fine. But it's important that you be explicit about what you want from your reviewer so they know what to provide you. As a reviewer, you want to make sure that your process for making docs emissions is clear to people who are writing content for your project. Write a process for people to follow. Doesn't have to be long, but be explicit about what you expect. Templates that you use, any style guide that you use, any sort of conventions that you use, your flavor of markdown, can be literally half a page. But it will save people a tremendous amount of time and frustration when it comes to contributing content to your project. Give actionable feedback, have a rotation for reviews, and avoid perfection. Call out nitpicks, specify that they're nitpicks, but don't make it about perfect documentation. Make it about good documentation for your users. Here's some additional resources for folks. I know I mentioned a lot, like templates. If you don't, you have templates for your current project or you're debating on what templates to use. I highly recommend trying Doxy, which is a set of open source templates that are used by the Kubernetes team that are based in Hugo. There are many, many, many other sets of templates out there that you can use. Feel free to grab those as well. There's also the good docs project, which is an open source project with many, many, many doc templates that you could borrow as well as principles for how to apply them to your project. Feel free to take a look at those. If you're looking for a community to tap into, let's say you have documentation and you're looking to make the next step, and maybe hire somebody like me to work on documentation for you, or you have questions about, say, doc versioning or localization, translation, any work like that, that might be significantly advanced from your expertise. Then I would suggest reaching out to the Kubernetes community and say docs, which is the easiest way to get ahold of us is on Slack, or trying to write the docs, which is an open community of technical writers and documentarians like myself who focus on this. And last, I wrote a book along with several other people here in the open source community called Docs for Developers, a engineers field guide to technical writing which covers a lot of these processes in depth of how to write content, how to create a documentation culture within your project, and how to effectively review and measure the quality of documentation. So thank you. I wanna call out a few people. I wanna call out a few people. Zach Corlison and Jen Lamborn who originally proposed this talk, but due to unforeseen circumstances couldn't be here.  And I also wanna thank the SIG docs group within Kubernetes for all of their work, many of whom I've listed here. So thank you very much. And with that, do you folks have questions about documentation that I can perhaps help you with? And there's a microphone in the back, right in the middle there. But you're close, so you can just shout it out. So, I'm sorry, what's your name? Tim, so Tim asked a question like, what's my opinion of document-driven development? And I think document, I really like document-driven developments as a model and a concept. I do think documentation should exist along the spectrum of development. And for a lot of the work that I do within the closed source within Waymo, we start with internal documentation about design docs and how we are developing autonomous vehicle technology with content alongside code. And I see that model working really well. Your mileage may vary with it, but I really like that model. Big fan. Hi, this is Vojtek from Acuity. My question would be, thanks for the talk. My question would be maybe the context. You mentioned that you're a developer, you have a background, a technical background, but not every technical writer has this developer background. So my question would be, do you have any good processes or stories about actually the technical writers working with developers when it comes to some complex features and basically how do people who write documentation work closely with developers? Is it like you ask your colleague to show you the features and explain it to you in detail or is it rather that you have to build it yourself and then test and then get back to the developer if you have any questions? What's the process that works best? I think developers, yeah, you're right. I'm lucky in that I was a software developer before I became a technical writer and I still do a decent amount of coding, but that's not every technical writer. And I encourage people who do documentation, do technical writing to get knowledge of coding. It's important that you be able to understand your audience because you're writing to them. Now, they're not gonna have the expertise of the person writing the feature, which is totally fine.  So having some of that developer knowledge is really important. That said, we've developed processes within Kubernetes, for example, to make up for that. The idea of splitting out technical reviews from docs reviews is one way that we do that. We sort of separate the technical writer's work, which is going to focus on their understanding of the end user and existing content and how the documentation they're creating should fit into the larger body of docs that we have versus the technical knowledge needed to understand the code and say, this content is accurate enough to convey the right mental model for the content. So there's a way to balance that back and forth. And I think I do think I work very closely with engineers. I sit with engineers. I learn what they're building and I write from that perspective. And I encourage people who are doing documentation solely as profession to do the same. So thanks for the question. Hi, thanks a lot for the presentation, very useful. My question is just regarding, what advice can you give to those who the English is not the first language? So do you have any particular advice for them? Yeah, I think that when we have, we have a number of members of SIGDOT to speak English as a second language and they're phenomenal writers. I don't think it's something that people should see as a handicap. I actually think it like writing shorter, concise, simple language makes it easier to translate into other languages. And that's something that we focus on a lot in Kubernetes. So I think some advice that I would have is to, beyond the fact that don't get imposter syndrome and don't feel like it's holding you back, is to look at other doc sets that you like and look at other style guides that you like like Google style guide or Microsoft style guide and see how that applies to your writing and how you might improve your own writing over time. Also, I offer developmental feedback to people. So if people are writing documentation, they can send it to me and I will say, like here's how I would edit it based on, if I was in a hurry to publish it, but here is a bunch of suggestions I'm going to give you to improve your writing over time because I see some patterns in your writing that if you change, your writing will sound more natural. It'll be clearer, it'll be more concise. So you're always welcome to ask other writers for developmental editing. That's what we call that. And you're welcome to ask people if you're writing a PR for sick docs, you can ask us for that. Or if you know technical writers that you work with, I would ask them for a developmental editing review of a document you're writing and take that feedback to heart and see how you can apply it to other documentation that you're creating. Yeah. Hi. Thank you for the talk. And my question is, are you familiar with the documentation system called Divyu? And if not, what do you think about systems in general? Because what I realize in my everyday work is that people come to you documentation for different reasons. So I think that there should be some separation between or some different styles of documentation to cater to those needs specifically. How do you do that in your work? I don't, what was the system called again? Was it Divyu? Divyu, D-I-V-I-O. D-I-V-I-O. No, I haven't heard of it. I know that there's a number of documentation systems out there, especially around API documentation and reference documentation and CLI documentation. And those tools help auto-generate a lot of content for those tools, like reference documentation that's generated. And I think those tools are great. They help automate a lot of the technical underpinnings that people want to know and they allow you to be documentation complete without having to do a lot of human written content. I really like those systems. That said, I tend to prefer human written documentation for things that are going to be written, is going to be read more by new users, by people who are coming to the product and want to have a more human experience. So I prefer markdown for that. But I know that there's a number of tools out there and they're constantly changing. I know Stripe recently released, was it a flavor of markdown, mark doc that I've been playing with, that's really interesting. So there are more tools changing. I do see a pattern where projects will lack documentation and people will come in with the idea of tooling will fix the problem. And I would highly caution you against that. It's better to create content first and then introduce systems like you're mentioning that help automate or manage your documentation instead of relying on a system to do all the work for you. I have never seen this succeed. But thanks for the question. I hope that answers what you asked. I think I have maybe a good follow-up question. So I'm involved in a project that's been going on for like a decade and we've had pretty good documentation, I think. But I think the format is holding us back from doing a good job of keeping it up to date. So it's currently in RST and Sphinx and we're looking at porting that to markdown on MK docs. Do you have any advice on, should we just focus on moving to the different format first? Or while we're doing that, should we also review things and try to maybe keep an eye on things like second person and things like this? Ooh, I think a lot of it depends on the size of your docs at. About how big is it? Let's say in terms of pages, about 30 pages or something. I think with 30 pages you could review it. I would do a copy editing review and migration. It's likely from what you're describing, you're going to want to maybe chunk out some of that content into smaller docs. You might have 30 very long docs and you want to sort of chop it up. I wouldn't do that re-architecture at the same time that you're doing the migration. So I would migrate first, then do the re-architecture. But you can definitely do some of that copy editing that I'm describing here, because you're already doing a pass through the content. We might as well make sure it's up to date with 30 pages. If you were to say like 50 to 100 pages, I'd be like, I would do one thing at a time because the project's going to be so big. But at 30 pages, I think you could do it. And you just mentioned that you have to be careful with tooling and not rely on tooling too much. But you would think like switching to a new format like MK docs, which I feel is a lot better. I've written some new documentation in MK docs. I'm very happy with it. While I feel with RST is just not, it's not easy enough or maybe life preview while you're editing doesn't really work that well. Do you think that makes sense? That there's new stuff and it makes sense to make a big jump to a new format? I think it makes sense. And I think it's what's useful. I think the biggest signal that you should look at is what do your users want? So I would talk to some of your users and say is RST and Sphinx holding you back from contributing? And if the answer is yes, then I think you have a great signal. If the answer is no, it's like all of these other issues. It's complexity of the project.  Then maybe you should step back and say, this isn't our, this isn't our number one priority to fix. But there are tools that can help you migrate as well. So that's a great instance of like using a tool to help you lift and shift that documentation over. Oh, we're time. We're time. Oh, I'm sorry. Well, I'll be hanging out here if you want to chat. Thank you so much.


Welcome to the 2016 NCHA Ferturity. I'm here with the winner of the non-pro final, Austin Blake, who rode stuff in my pockets and scored a fantastic 224. Congratulations to you Austin. Thank you. First rider out, first set, he came in, blew them away. I take it that was the plan? Well I was just trying to have a clean run and I mean I wanted to do as good as I could obviously but I just wanted a clean run and let it happen whatever happened. Tell us how that felt that 224. Take us through it. Pretty dang good. That mare's a cow-y little crouchy. I like that mare. And what did you do on each cow? Give us a description. Well my first cow was over here on the side like Billy Calgo's booth over there and I drove it up, kind of slipped it up there and just trapped it in the middle like this. And then my second cow was over here on the other side and I just drove it right up the outside and trotted in behind it and same deal. My third calf was kind of I really honestly I didn't even know that calf. There's two like there's a red calf and a little black calf and I knew I didn't like the red calf and the black calf's in a better spot so I just slipped it up there and tried to get along. Okay now the tough thing about going first is that you've got to sweat it out with everybody else coming after you. Which was the rider horse combination you're most worried about because like Cade Smith last night got a 222 on his horse? No I just wanted to do as good as I could. I mean like obviously everybody wants to win but like I was just happy that I got my mare showed. Tell us about your mare and how did you come up with that name? Well I raised that filly and I really like when she was a cult she used to run around and stop real hard and run around and I thought it's kind of a funny name maybe dumb but I liked it. Have you got stuff in your pockets? I might.  Well to be honest with you I was gonna show that mare to small fraternities and I had Lloyd Cox worker and he said hey you might save this filly for foot worth because I just had her and her sister and that was the only two I had to bring down here and he said just save her for right there. And you got a third on the sister in the limited non-pro correct? Yes ma'am. So two great horses that's pretty good effort to breed and to make the finals and have success with? Yes ma'am they're both decent enough. Now this is not the first time that you've won a major event in the Will Rogers here you won the same event in 2010 tell us about that. Well that was on a one-time Pepto that was the first batch of those and that was the first time I made the fertility finals and I'm not very good at telling anymore than that. How does it feel? Does that is that a different feeling to how you felt with your first one? Well you know it's kind of cool raising her you know and there are two totally different kind of horses like that first horse I won the fertility on like he was running and stopped real hard and this American stopped hard enough but like her deal is she's just so calsmorn. Is it more satisfying to know that you've won on a horse that you've bred? Yes I still own her mom and like it feels pretty good putting a produce record you know on her first set of colts here. Sounds like you'll have a sort after bloodline there. Thank you. You've just won almost $60,000 that's a great check any plans for that? Well I have a good banker and he's gonna take it. Okay and perhaps a good night of celebration? Well maybe tomorrow. Not tonight? No not tonight. It's kind of late. Well enjoy it. Congratulations. Great job. Thank you.


Catch up and get ahead with the edge for the week of March 28th. The San Antonio area added more than 51,000 people from 2014 to 2015, one of the largest gains in the country, according to a new report by the U.S. Census Bureau. Combined with Austin's gain of 57,000 people, Houston's gain of 159,000 people, and the Dallas-Fort Worth area's gain of 145 people, that adds up to 400,000. That's more population growth in any state in the country, except of course, Texas, which grew by 490,000 people, thanks to growth from everywhere, even in Little Loving County, which grew by 28.7%. In Celebration of Women's History Month, a group of San Antonio leaders gathered for a conversation about their careers and the challenges they face as professional women. This year's Texas Women of Influence Panel included San Antonio Mayor Ivy Taylor, City Manager Sheryl Scully, via Chair and former Texas Secretary of State Hope Andrade, Texas A&M University San Antonio President Cynthia Teniente-Matson, and Terry Williams, the Contracting Resource Center Director at UTSA's Institute for Economic Development, Small Business Development Center. Texas Public Radio's Eileen Pace moderated the conversation. Now Cast S.A. webcast the panel discussion as we have for the past two years, so you can go back and replay the video to get valuable insight and wisdom from these impressive women. We're dealing with right now the mayor and I with regard to our public safety unions. A lot of B words are being used. I mean, I'll be really candid with you and I don't think that I don't feel that I would be treated the same if I were a man in this position. Please note that men in this position previously. At the 2016 Maker Faire at San Antonio Central Library, you helped us make a movie about why San Antonio is a great place to live and how it could be even better. We asked you what you love about San Antonio and you came through in a big way. Then we asked you how San Antonio could be even better and you had some great suggestions. Here's a bit of that. And how we're making the San Antonio tech community. I would like it better if it was closer to the ocean. If it wouldn't be so hot. Go to Nowcast SA to check out that video and please share the movie and the love with your friends. Speaking of the library, more than 90 books are going to come to life this weekend at the San Antonio Book Festival, which is free and open to the public on April 2nd, 2016. Dozens of authors will be at Central Library or across the street at Southwest School of Art. They'll be talking about their books and taking questions from the audience about their work. You've got links on Nowcast SA to the book festival's website and a schedule of events and also a new feature, a YouTube playlist with videos of some of the book festival authors. Many of the videos are teasers or book trailers and others are videos of authors discussing their work. For more on all of these stories, go to NowcastSA.com. See you next time.


when worry comes up is we want to ground ourselves in the now, you know, Eckhart totally, God bless his soul, love him as a teacher. The frustration I have with him to be totally honest is he just says be in the now but doesn't often give a how and just a very quick hack right now is look at your feet. Your feet are always in the present moment and it can create an interrupt of the worry like a runaway train. So we'll be talking about that again. And then you ask yourself the question, what do I have control over right now? You have control over what you put your mouth, you have control over what you go do next, you have control ultimately over what it is that you're thinking. It may not feel like it, but you do. So stay strong.