Good evening. Happy fiesta. I see some of us are addressed for the fiesta occasion. This is a week of celebration and we're celebrating here at the Central Library with a very special guest who will be introduced very soon. First of all, let me introduce myself. I'm Ramiro Salazar, Director of the San Antonio Public Library. I want to extend to all of you a very warm welcome. As I indicated earlier, we have a wonderful program and we're excited to be presenting a very special guest and presenter. Before I continue, let me see if I have any board members that are here that I need to recognize. I don't see anyone. Okay. I do want to thank Nowcast and the leadership of Nowcast for live streaming this particular presentation. Charlie Rand, thank you so much for your support and all you do to empower the community with not only information but the experiences that you share through your service. Thank you so much for what you do. April is not only fiesta, part of fiesta, but it is National Poetry Month and throughout the library system, we're offering the number of programs to celebrate the power of poetry. We're happy this evening to be partnering with the Department for Culture and Creative Development and I'm very pleased and honored to be introducing my colleague and the head and director of the Department for Culture and Creative Development and that's Felix Padron. He'll be coming to the podium very soon. Felix as director of this very special department, you have taken a department to higher levels of excellence and have expanded your influence in the arts which is very important in the city and so I'm grateful for the work that you have done to enlighten the community with experiences in various forms of arts and it is my pleasure at this time to invite Felix to the podium and he will be introducing our special presenter today. Felix. Thank you Ramiro for that wonderful introduction and buenas noches para todos y bienvenido a la biblioteca central de San Antonio. Es un placer. I want to thank you obviously everyone for coming out tonight for this special location and the library thank you thank you thank you thank you for partnering with us for the special presentation tonight. It gives me great pleasure to introduce the wonderful guests that we have here very special individual but first I want to give you a little bit of background on perhaps how we got here. Many of you may know that in 2012 in the year 2012 San Antonio became the first major city major city in Texas to appoint a port laureate and since then other cities have followed including the city of Houston they sort of got the bug and understood the power of having a port laureate and how transformational that could be and then a smaller city but equally important as the city of McAllen which is actually doing some pretty phenomenal stuff in the valley they have appointed their own port laureates so that's really amazing that we have been able to sort of set that stage. We then in 2012 obviously we did appoint Dr. Carmen Tafoya as the first port laureate for San Antonio. It was a wonderful to see how she was able to really take on the helm of that appointment for her two-year period and really did a remarkable job in transforming really the thinking about what we do, what we breathe, what we read in this community especially with the young people she was able to do over a hundred sort of presentations engaged in this community in that conversation. In San Antonio obviously we do recognize that poetry plays a significant role in the culture of our day-to-day lives and education and how we shape our population to really inform and really support the sort of the brand that has been anointed to the city which is a city on the rise and I think this is very much a part of that movement. Having a port laureate brings to the forefront the necessity to promote literacy, poetic arts and literature and I think it goes even more beyond that. Our port laureate will foster this message throughout her two-year term which I want to do soon a minute. Just a few weeks ago our department had the pleasure of kicking off National Poetry Month with the appointment of our well-deserved and treasure second poet laureate Lory Ann Guerrero. Lory many of you may know was raised in the south side of San Antonio, yes. She attended McCollum High School and at the age of the tender age of 16 she had her first publication, pretty remarkable. While attending Palo Alto College her composition professor Linda Harris recognized Lory Ann's talent and encouraged her to apply to Smith College. She was accepted as a non-traditional student, I think that's pretty special, non-traditional student. I love that term.  Needless to say she preserved and sacrificed to pursue her dreams of writing and calling, she recognized at a very, very young age. She went to graduate from Smith College with a degree in English language and literature and then received her MFA in poetry from Drew University. In 2012 she won the Andres Montoya Poetry Prize for her first length collection, A Tongue in the Mouth of the Dianne, which plenty of books, please buy them and she'll be reciting from that book in a little bit. The book was published by the University of Notre Dame Press in 2013. The author, Martin Espada said this of Lory Ann's writing, Guerrero writes in a language of el cuerpo, the body, visceral, almost arbitrarily vivid, vivo, the language of a poet who knows how to work her hands. Pretty remarkable, digging deep down in the soul. Lory Ann believes that reading and writing lead to the awareness of oneself and when we are aware that our voices have the ability to affect even the smallest change we can become willing to strengthen them and share them. It is this reality that empowers our communities to seek higher education and to uncover untold stories. That's the basis of her poetry at this time. Since turning to San Antonio in 2008, or returning to San Antonio in that year, 2008, Lory Ann has taught at Gemini Eng, Palo Alto and the University of Incarnate Word. She has also been a visiting writer at UT El Paso and our lady of the Lake University. She has taken this year to finish her book tour and work on her net collection, A Crown of Gumen Cindo, which will be published, I think, pretty soon, ready to get published. So it will be pretty amazing. Looking forward to them. I will close with a quote from El Alcalde, Julian Castro, following in the footsteps of Carmen Tefoya will not be easy, but Lory Ann Guerrero is an inspiring choice who will amplify the importance of literary arts in San Antonio. Her personal story and professional success will resonate with muchos San Antonians. We look forward to the next two years as Lory Ann carries on this literary tradition in San Antonio that began last two years ago. We want you all to stay involved with the great ideas and events to come. It takes a community to make this work and thank you all for being here and supporting not only poetry, but also supporting Lory Ann Guerrero. Con eso quiero introducir la poeta Lory Ann Guerrero. Bienvenido. Thank you all. Thank you all for being here. I'm really happy to add this thing is in my face. Can y'all hear me like this? Is this okay? There. I'm really happy to be here. It's my first reading as Poet Laureate of my city. It's an honor. It's an honor and it's unbelievable. I just did an interview with Texas Poetry Review, Borderlands, that's supposed to come out in June. And my interviewer asked me what does it feel like? What does this feel like? And no one had actually asked me that, so it wasn't until I had this question and I had to write an answer that I really thought about it. And you know to be someone who, you know, the only girl of my family, the youngest, I was constantly seeking a space from which to speak. I wanted to be listened to. So to be in this space now, it's kind of what you wish for. But I've spent a lot of time, this is what I was telling the interviewer, I spent a lot of time looking in the mirror and reminding myself that this is what a poet looks like. This is what a strong woman looks like. This is how we do what we do. We just work hard and we be ourselves and we keep on fighting. Keep on fighting. So again, I'm really, really honored to be here. I want to thank the San Antonio Public Library, which has been a lifesaver for me, my entire life. The Department of Cultural and Creative Development for the support and Joel, I don't know if he's here. I wanted to say too that, you know, poetry is such an important thing and it's important when we, you know, as an educator and as a mother, especially I try to get my students and my children to understand that when we're reading poetry, it allows us to access parts of ourselves that we wouldn't normally, things we wouldn't normally think of or maybe things we're afraid to say. And so in doing that, there's an empowerment that happens that allows us to sort of walk through the world with confidence and makes us able to speak up for ourselves and for others and make change. And when you're writing poetry, it allows for this exploration of the self. And it's in those moments when we're writing poetry that we're really able to acknowledge the things that we already know. And I think certainly in communities like the one I grew up, I grew up in the South Side, an underserved community, I think we were constantly striving to be better, do more, get out of that community. And the reality is it's only because we had never really acknowledged what we already have. The smartest man I know was my grandfather, he had a third grade education. And so to acknowledge that, I think it's really important that we do that for ourselves and for our ancestors and for our children. But I'm going to read to you from my book. It's for sale, please buy some. I keep it real, I'm a poet. I'm going to start with the first poem of the book, it's called Preparing the Tongue. In my hands, it's cold and knowing as bone, shrouded in plastic, I unwind its gauze mummy like, rub my wrist blue against the cactus of its buds. Were it still cradled inside the clammy cow mouth, I should want to enchant it, let it taste the oil in my skin, lick the lash of my eye. What I do instead is lacerate the frozen muscle, tear the brick, thick, cudd conductor and half to fit a ceramic red pot.  I choke down the stink of its heated moo, make carnage of my own mouth add garlic. This next poem, this next poem is called Sundays after breakfast, a lesson in speech. There were no names for men like that. Gringos who stitched up their rules, their white garb, lace snug the issues of the day. Lord didn't make us to mix with them folk, they said. But God's got nothing to do with the black boys jump still alive into a restless river. God's got nothing to do with having to tell their mamas.  This grandpa could name Los Cuerpos, body swaying above the cotton like sheets on a line. No importaba que no eres negro, pero que no eres gringo. No, it didn't matter that you weren't black, grandpa says pushing himself from the table. But that you weren't white.  This one's called roosters home coming. They're roosters. She corrects me. Chubby Cox hang above our head from the ruffle of curtain in the room where her children eat in her kitchen next door to the house where I used to live. She laughs and two step pups a couple of those equis con Lima. I've missed you neighbor I say peering through her window into the kitchen I used to cook in next door looking for the painting I left behind the curtains I sewed looking to see if I damaged the counters with an imprint of my ass wondering if my DNA might show up if detectives ever needed samples is my hair wound tightly in that carpet skin flakes painted into that red door neighbor tells me the new woman next door has a baby that cries all night. And when the man struts home at four in the morning, he crows like a madman. Our beer is ceremony. We talk about Maria. Remember her? Her baby Lewis. Did you know she was pregnant when he killed her? That he killed the baby first? The boy first in front of her? Our children rush through the kitchen paletas and hand to the backyard with the men who love us today. Passing the salt con limon we pray for the woman next door hoping blood is never never shed in my old home like in Maria's two blocks down. Neighbor loves her curtains. Come back. She says. Come back. And when you do, I'll bring you Caldo the way I did when you were expecting la chiquita before you moved to the snow where roosters are thin and don't know how to dance. So one of the things that I explore in my book, you know, when I was writing or revising a lot of this book, I was living in Massachusetts. I moved there when I was 27. I graduated from Smith when I was 30. In those three years I was finishing up this book. I shouldn't say I was working on this book. And there were so many things happening in my city and I started to feel like I needed to get home because I'm superwoman and I can save everybody. I'm going to read this book. It's called Esperanza Tells Her Friends The Story of La Llorona. She killed her babies in the river over there by the Bill Miller barbecue place. You know by the Holy Mother Church, she was friends with my grandma. They played bingo together, I think. Oh yeah? Why'd she kill them? They were brats and they were probably never helped her clean the house and they're probably really whiny and always wanted candy and line at the H.E.B. Had she do it, Espe? She drowned them one at a time and herself too, I think. That's probably why she cries. She probably didn't mean to kill herself too. That's not how the story goes. My mom said it happened in Mexico and not San Antonio.  What do you know?  Anyway, I think she reincarnates herself.  Whatever, Espe. Serious. She comes back in real life and keeps on killing her babies, but I don't think she cries anymore. She's so used to it now. She's gone to Houston, had snokes, to Plano, even back to San Antonio right here in the south side. You think you know everything? Tell us how come sometimes she kills herself and sometimes she don't. I don't know. Maybe she cloned herself and now there's lots of yoronas.  I love reading that one. Thank you. This one's called Ode to El Cabrito. I think most people know what Cabrito is. Maybe called we eat it at Don Pedro Sien. Ode to El Cabrito. More than sheep and cow and butterfly, I love you. No envy between us like the rooster footed.   In the onion and cilantro, you do not recoil like the burnt skin of the pig, but spread yourself, sunbather.  You love being loved.  This one's called Stray Cat. She was fat, round as the moon and just as gray. She didn't have time for hiding, for safety, for hissing away on lookers. Her legs jerked and out rolled the little slick and warm bundles too. She circled them, inspected the mousy ears, licked the furlous pink skin. They made no noise. Their tiny hearts rippled though softly. She ate one, then she ate the other. So I thought I had marked here. Yeah, I'm gonna read this one. Yeah, okay. So yeah, one of the things that I was dealing with when I was living far away was my mother sends, calls me and sends, starts sending me clippings from the from the Express News about the babies that were found under a house in the south side. And maybe because I was postpartum, I don't know, but it really it took a toll on me. And so I have these two poems that I'm gonna read to you from that experience. The first one is called Babies Under the House for Saraya and Sebastian. When you open your eyes again, Saraya, this will just be one of those things like rice and bean tacos every night, having to go to the free clinic, buying gas with food stamps at Ben's ice house at the corner of Pleasanton in Petaluma. But you know that, don't you know that your body will never grow completely? When you open your eyes, your skin will be smooth as a day you were born, not what it was when they found you and the tiny thing that was your brother. The dirt around you will have licked away mother's milk from your lips.  You won't even remember. When you open your eyes again, Saraya, you will be the mother. Your tart Mexican heart won't let you be anything else. No need for grownups, child protective services who are too busy, the legislators who couldn't give medication, education to this poor neighborhood, this city, la raza with no muscle, no voice, hope decomposing in a couple of plastic bags. But there are two things you will have that your mother never did. A whole Saraya, a whole Sebastian. So when this was happening, this fear of violence that I grew up around, I guess when I became a mother, it really started infiltrating my psyche and my dreams. And there are many poems that I write that are straight from my dreams. I kept dreaming that I was going to die. And this one day I woke up and I sort of rolled out of bed and wrote down the dream word for word. And I revised my poems, you know, 20, 15 times. This one got very, very little revision because it was just, it was straight out. This one's called Morning Praise of Nightmares. When the steak knife fiddled against the sinew of my gut, I heard the slow wine. Felt each ridge. Felt the simmering red erupt like the juice of an overripe plum, the tickle of nectar running down the body still warm from the sun. And from the kitchen to the street fair, as it often is in dreams, children laughing, a clown, the color yellow, balloons melting against the burned sugar of the skin. And guns, tiny, like from gumball machines in tiny hands, bullets red and green and gunmetal blue piercing the skin like botflies, their metal heads in deep until that offspring, that winged blood gently and timidly took flight. Then the peeling of my skin. Who was that crafter whose face I never saw? The paper maker, his teacup hands, his close pin fingers, rinsing clean the lace of my forearms.  I could taste my own blood, though I couldn't lift my hands to finish the job, put myself out of misery. I was butt remains, a piled heap of slop on the floor of a house I never shared a meal in. Even my eyelids were gone and my spine exposed. I was an afterbirth without the birthing, a too early puppy whose whole pink body thumped with each beat of his slow heart. This is my morning praise of nightmares. Open your eyes. I hear three mouths whisper against the flower of my skull. Mama, open your eyes. Sundays after breakfast, a lesson in cotton picking. South Texas 1943. It was a kind of dance. Feet shuffling in dust, fluttering hands like birds nest building. Blood staining brown birds red.  I watch him slow weep of his eye remembering the girl who'd name and nurse nine children. He picks my grandma by the color of her dress, her eyes. And because she's lucky, not by how much cotton she can pick. So how are we doing on time? Anybody? I think I'm going to read two more from here. This one's called put attention. Put attention, grandma would say, as if attention were a packet of salt to be sprinkled or a mound we could scoop out of a carton like ice cream. Put attention, put attention, put it where in her hands in the percolator on top of the television set that seeps fat red lips and Mexican moustaches. Next to the jade bura between la virgen and cousin cousin Pablo's sixth grade class photo, marshmallow teeth jumping out of his mouth. We never corrected her. Like the breast Spanish lulled grandma's tongue as we threw down shards of English laughing for her to leap in and around. Put attention, put attention, put it where? Shall I put attention in my glass and drink it soft like Montepulchiano de Abruzzo? Like Shinerback? Orchata? Put attention. Ponga atención she tried to say in our language. Put attention somewhere large. Back into her eyes. In the part of her brain that doesn't remember her own daughters. How to make rice. Translate instructions. Don't take the baby out of here. Y'all keep the baby in here. Do I need to? Okay, can y'all? Oh, that's better, right? Oh, I got to do all first. Okay, that sounds really loud. This is better. Okay, sorry. This next poem is called, I get to tell the story of this poem. It's called wooden box. My grandfather when I got back from Massachusetts, he asked me, he called me Piyuya. Piyuya, what do you want? And I wanted him to take the the reclaim the lumber that he'd been storing in his shed and make me a dining table with it. He couldn't understand why I wanted this, but that's what I wanted. And he said, Okay, well, start pulling that lumber down, and we're going to make a table. So we started doing that. And I got in his way. So he sent me out. And I went to go get him a glass of water. When I got back into the workshop, he was kind of sitting on a sitting on a bar stool, and he was kind of slumped over. I said, grandpa, what's going on? You know, he looked sad. And he said, you know, I'm over here making you this table. I should just build myself a coffin. This one's called a wooden box. He demands this. Nothing else. No mahogany slick or roses kissed by lilies, no music or speech weeping limited.  We are not to sob for the child him, the bed and alphabetless picker of cotton, potatoes, tomatoes, follower of crops. We are not to sob for the cactus man vaquero lover him. Grandpa who takes his milk from the moon, who knows the time for cookie, the time for wine. No. When he is gone, he will be gone. I can make the box myself. He says, I can make it myself. I used to cry through that one. I don't anymore. I'm getting better. I'm going to read this last poem from the book. And then I'd like to share some new work if that's okay with everybody. My grandfather was blind. And this one's called on blinding. When finally, the shadows grow like cactus, scraping the iris gray as the sea and I no longer see the articulation of a bird's wing, or the curve of my own magnificent knee. When finally, the nerve behind that bulbous white that tickle of brown forgets its job, loses its mind to time, erupting hot and slow as magma. Know that I know the magic of the blind. I have catalogued your hands in my hands. So thank you. I am working on new poems about my grandfather. I last him in July. It's been almost, oh, it's been nine months yesterday. So the book that I'm working on is called A Crown for Gumesindo and it's a crown of sonnets, which is a series of 15 sonnets. So the last line of the first sonnet begins the second sonnet and the last line begins the third and so on and it forms a wreath or a crown. I'm only going to read three from the crown. It's not finished yet, but it's almost finished. I'm going to read you number seven, number eight and number 11. Number seven, newborns. I can't see. It's better. Newborns. Let's look at our reflection in the mud. See how in four months each of us has changed. What is your name without a body? My name without you here. I am new. What I never was.  What festers in the bellies of strangers does not concern me. There is only this. I am the only mother. Mine is the only child. I decompose alongside you, wanting and not wanting everyone to see off balance and leaking my skin and strands. The oddity that was put in my hands. Number eight, Dia de los Muertos. The oddity that was put in my hands, your truck. It used to be I drove this road each week to pick you up. Now I drive this road each week to lay you down again. Today is the day of the dead. When did you die? Today I bring you chicharron con huevo, chile, which is to say I bought breakfast to the goats. I want to slip my hand into the photo of you, fix your hair as I did, help you with your sweater, guide the salt to your plate. The grass is starting to grow over you. Shards of rock gone smooth. I sing to the bees. I lay my ear to stone. It doesn't hurt. I hear your voice rising from the dirt. And this will be the last one. It's called casketing. It's number 11 of the 15. Cascading is another dream poem. Oh, I can't see it. Cascading. I've buried everything I've ever loved in the bone of reason. Now, even in sleep, you are dead. Sometimes in your metal colored coffin, I will you to the grocery store. Once to a papery. Twice to fiesta bakery on Pleasanton. You are heavy. Once I was in high school in a play and parked you stage left. Always I shake you. Wake up.  Sometimes the casket is open. And I kick you. And when in my small shoes, I make contact your ribs crumble like the bark of an old Mesquite. Wake up. Wake up. We cannot run the numbers. Argue. Make your mother's bread. If you are always going to be dead. Thank you all so much for coming out tonight. I really appreciate it. Carrie Moxigimba. And on behalf of the San Antonio Public Library, I'd like to thank Lori for attending today and all of you for coming. We also have a copy of her book, A Tongue in the Mouth of the Dying, that is going to permanently be a part of our Latino collection. We are going to have her autograph it right here today so that it will go upstairs and be here forever. Thank you so much.


Okay, welcome everybody, thanks for coming. Tim and I are going to give a session about our personal experiences about the issue queues and how beneficially it has been for both of us spending time there working and helping other people. Here's a little introduction about us. My name is Juan, but I'm normally known as Juan P. I'm a developer at Civic Solar and within the community I maintain a few modules such as Twitter or OAuth. I'm also the author of the trust users guide book. So if you tweet something containing the hashtag trust guide, I'll pick a random tweet tonight and I'll let you know if you want a copy. I'm Tim Plunkett. I'm from Philadelphia in the States and I work at ZibTech and I'm a core developer and I co-maintain a couple modules and I don't have a book. Okay, here we have summarized the main ideas that we want to transmit here. The main thing is that whatever your background is, you need the issue queues and the ellipsis is that the issue queues needs you as well. No matter if you are a developer, a state builder, a salesperson, you will find a box sometimes or you will find an unexpected behavior with a module or with the Drupal site you're working on and the best place for looking for a way to fix this or to understand what's actually happening, it's having a look at the Drupal.org issue queues. By saying that anybody can help, I mean that we actually need people from different backgrounds to provide feedback because it's not just a thing of developers that they keep on submitting patches and evolving modules. We need people from user experience backgrounds to submit screenshots for example, we need designers as well and there's always a constant demand for these kind of roles to help on the issue queues. One of the things that you will learn once you start helping there is that patients is like gold there.  If you need that kind of urgency, you better move to the IRC and ask there in one of the Drupal channels and very probably, I mean, most probably, somebody will help you out there. The most well-known channels, if you wanna know what are hash Drupal or hash Drupal support. There are some others, but those would be the more general ones. There's also a link there at the bottom, which would be a good starting point. So how to start? I guess most of you have already worked with a few Drupal sites or you are part of a corporation who works with a shop or an e-commerce site. Just think about a project within Drupal.org or a module that you like, such as, I don't know, views, for example. And open the issue queue and have a look, chime in. See how people interact with each other. Some person may have an error or a doubt that you may be experiencing the past and there you can help. So as I said before, it's not just about fixing modules or submitting patches. There's a lot to do there by just commenting and sharing knowledge with each other. You'll see that the community is very challenging. Me, for example, as a module maintainer, I see that most of the progress I do on the modules is driven by the community. It's somebody who had an idea and suggested it at the community. Some other people chime in, and it was at some point me who chimed in as well, studied the API at that point, and commit something that some other guy submitted. So at the end, you can see that everybody is trying to make the modules evolve and do more and more and more. And that's a really, really, really learning process that is fun. It's really, really fun, and that's the best thing of it. You can also join with somebody else who knows about contributing and just go through some issues with him or her, and that's very effective as well. Don't know if you want to talk about anything here. Okay, I'm gonna sit down because this mic is not reaching. The issue queue form, who has never seen this before? Okay, this is how Drupal.org works. Everything goes through this form. Whenever you need to create a new issue or update an issue, you'll see this. Most of the major things like version are gonna be obvious. You're working with Drupal 7, you're working with Drupal 6, or you're helping develop Drupal 8. The component, most projects only have four components. Code, documentation, miscellaneous, and user interface. And the category are, there are four categories. Bug report, support request, feature request, and task. If you're working on Drupal because you want to help and jump in, you might work with all four of those. But primarily, if you have a problem you need to solve, it'll be a bug report or support request. And someone asked me earlier, what is the difference? The difference is support request, you're not sure if it's your fault or the module's fault. And a bug report is when you're sure that it's definitely not your fault. You might still be wrong, but that's okay. The priority, there's minor, normal, major, and critical. This is where the whole being patient and being understanding comes in. Generally, your issue is normal. There are very, very few issues that are actually critical. Saying, I have a site and it stopped working today, and my boss is mad at me, doesn't make it critical. If you click the button and all of your users went away, that's critical. And there's a big difference there. Broken for you and broken for everyone is where you can draw the line with what is critical and what is not. And the status we'll talk about in another minute. But the one thing to be very careful about with the issue queue is the assigned field. You go in, you submit a new bug, and you assign it to yourself, no one's going to look at it. Assigned means that you have it under control, you don't need any help, and you know what you're doing. So I'll see all the time in the issue queues, support requests or bug reports assigned to the person who submitted it, and they just get ignored. So be very careful with the assigned field. Don't assign it to yourself unless you actually have the intention of working on it. The status field, these are all the different statuses with one exception, but everything starts with active. When you file a first open an issue, it's going to be active. It means it's new, someone needs to look at it. The needs work and needs review imply that there's a patch. Someone has worked on it and actually put the time forward to roll a patch. Setting it needs to needs review without a patch, it'll just get set back to active. So it's a waste of time. Going between needs work and needs review, it'll generally be between those two states for the entirety of the issue. Someone uploads a patch, it's needs review. Someone reviews it and finds a problem, so it goes back to needs work. Someone updates it, it goes back and forth. If someone sets it to postponed, maintainer needs more info. It means the maintainer needs some more information from you. They need to know what version of the module if it's used in the dev version or not. What other modules are you using? The five or six closed statuses, there's different categories of those.  There's probably a reason for it. Most often it'll be closed as duplicate. And there'll have been another issue someone else submitted that addresses the same problem you're having. And finally, eventually, it might get actually marked reviewed and tested by the community and then committed as marked fixed. And that's a good thing. Do we have any questions so far? Okay, okay. Yes. Yes. Yeah, so most queue maintainers either get an email or they keep track of their own issues. But yeah, someone will take note of it. If it's core, it's a little different. And I'll talk about that in a minute. But in contributed modules, yes. Almost all of the maintainers know when there's a new issue filed. And the other thing is, if it's a bug, you see an error. You just paste that error into your issue body. And someone Googles for it. Drupal issues show up pretty high on Google results. Someone else might comment on it and say, yes, I also had this error. The maintainer will get another email. So if you see the same problem as someone, you can, if it's still kind of undecided whether or not it's really a bug or not, you can chime in to help confirm that it's really a problem. Yes. Specifically about core, this applies to contribute in some of the bigger modules like date and views and whatnot. A lot of the smaller modules just work. You know, you need that module. You download it and then you have no problem with it. And as I said, most contribute maintainers get emails about other issues. The Drupal core doesn't work that way. The maintainers don't get notifications about everything because there are 10,205 issues right now. But you can, you, everyone here can actually help with core. You don't have to be a programmer. We're going to post these slides or do we post them already? Yeah. Posted the slides. These links actually go to things. And it explains where to help starting with core. There are going to be two things on Friday. This Friday, a training session on how to get set up to work with Drupal and then an entire core mentoring sprint that I'm helping run to help teach everyone how to actually contribute. So if you come to that on Friday, we'll help you get set up with Git, Drupal, Drupal 7, Drupal 8 and start you contributing. And we do that also every week, twice a week on IRC. And that's the core mentoring hours. And there's also a session, Gabor's session on how to get the most out of getting your feature into core. And that's another way to learn more about getting new things into core. That's a long URL. That's why we are pasting them. So if you want to get these links, just go to the session. There's a PDF there, which is the one we are viewing now with all the links. So you got to the point that you found a bug in your Drupal site and you want to share it with the community or you want to find information about it at Drupal.org. First, you need to know what's actually happening. If you have no idea, you can do as Tim said, copy and paste the error or describe the behavior in Google. And most probable, there's an issue already created. That means that that completes the fact that whatever error you have, it's very, very, very probable that somebody else might have it already, either sooner or some more time ago. So that's why we are empowering in saying that you should search on Google and you should try to find if there's a related issue before creating a new one because that adds a lot of workload to the module maintainers. If you know that the project that is related, for example, if you know that it's a bug related with the date module or with views, then go to the issue queue and search there. We encourage you to use the advanced search engine, which it's a link that is at the top of the issue listing and it adds extra fields. Do you want to do a quick demo of that? Yeah, let's show it. So this would be the default listing of issues for views, for example, and that's the link I just mentioned. There is such an amount of issues in views module. I mean, that's why it took so long. Those are the fields. I don't know if you want to mention anything about them too. So yeah, you were asking about how to specifically find things. First thing I do, I skip. I go to Google first, especially if you have an exact error message. If it's an error message, you can Google it. You will almost always find it right away. If it's some behavior that you don't quite understand, you're going to have to do a little bit more research. But if Google fails you, which it can do once in a while, there are a couple important ways to make this advanced search work for you. Obviously, the first thing is you'll want to put your search string in. But beyond that, you can restrict it by exactly what version it is. Don't use the exact numbered ones, because people will file them against all sorts of different numbers. You know, views 3.1, 3.2. Always just use the 7x or 6x version. You can, between the two, if you're having a problem, bug and support request is an easy way to filter it down. It's generally, if you're having a problem, it's not a feature request. Leaving the priority completely blank is the best. And with the status, if you use open issues, it includes recently fixed issues, which is actually a good thing. Issues that are marked fixed have been fixed in the past two weeks. And there's a possible chance, especially if you just upgraded your module, that they rolled over a new release, something broke, and they figured it out right away, and they've already fixed it. So if you don't look at the fixed ones, you might never actually find your bug. But the open issues tag is good for that. And when you search that, it'll restrict a lot more. Especially with views, there are so many issues. They're about halfway split between Drupal 6 and Drupal 7. And the bugs aren't generally the same. It would be in one version or the other. So as you can see, there's less issues here now. Does that sort of answer your question? Yeah, when you search on Google... Yes. So just to repeat, when using Google.com, you can put in... You can use a site filter within Google Search. And that will restrict it to only show results from Drupal.org directly. And that is very helpful. The other thing is if you do Drupal all day, Google will learn that you do Drupal all day and will help restrict your search for you. That's how you know you're really a nerd, when all your results are Drupal results first. The other thing, the number one tip to debug a module is just download the dev version. The stable releases, especially in Drupal 7, are kind of a false sense of security. It's not security in the site security sense, but that, oh, this module must have no bugs. It has a stable version. That's not true. Or this open source, everything's constantly evolving. If you are using the last tagged version, that means you're missing out on every single issue fixed since that point. So with views, it was like, the last release was in June. It's been a whole summer worth of work done. And there's a really good chance your module... Or so your bug was fixed since then. So downloading the latest dev version is the quickest way to solve your problems, generally. I've done it a number of times where I spend all the time debugging it. And I've even gone so far as to write a patch and then realized I was on the wrong version and my exact patch was already committed by someone else. So that's the easiest way to solve a lot, yes. Generally... Generally happier than I am with the four-month-old stable version. Right. The way Drupal generally works is you have different branches. So with views, you have 6x, 2x and 6x, 3x. All of the changes made to 6x, 3x are intended to not break your site. If you're upgrading from 2x to 3x, everything's going to break. It won't, hopefully not. But it could and it's not promised. All of the changes made to 3x from now on are intended to make it better. So they're not introducing vastly new things.  There are a few factors that you can see in order to decide if a development version of a module is stable or not. Such as how many people... If you see the statistics, you can see how many people have installed that version. If you see the issue queue, you may see if the maintainer is actually fixing things. Or it's just leaving all issues open. You can even read the latest stable release notes and see how strict the maintainer was following the standards, how many issues were fixed. And lately, if you know a git, you can just check the log and see what was lately committed since the latest stable release to the one that is the development one. That should give you enough to decide if it's actually something that you can use in production or not. And that said, when we're developing a site before it launches, we're constantly updating to the latest dev. And then once we actually launch the site, we still want to update to the latest dev, but you do that in a test site. You do not do that on your live site. So if you got coding skills and you are helping with the issue queues, you can help on actually submitting patches and reviewing other patches. It is as important to do the former than the latter. Because normally when you submit a patch, the maintainer will wait for somebody else to review it and test it. And verify that the patch applies correctly, fixes the issue, and that the code within the patch complies with the standards. Patches that are reviewed will catch the attention of the maintainer, the first ones. And that's something we're gonna talk at the end of the session about which ways are better to catch the attention of the maintainer to get something done. There are some tools here that are mentioned with their respective links. I've just attended to a session about debugging and there is a box tomorrow at 2 p.m. about X debug. So if any of you want to know about it, I really encourage you because the X debug author is gonna be there as well. Of those links, who doesn't, does everyone know every single link down there? Really? You all know all of those things? Okay, thank you. Git is the version control system Drupal.org uses. There have been lots of talks about that. Devel is a module that you use on your local development site that provides a lot of helpers for quickly creating new content or stepping through, not with a debugger, but manually exposing parts of Drupal code and helps you write modules. Firebug is the Firefox extension to inspect the actual source code of a website. Chrome and Safari have their own built-in versions of those and the Chrome one is now actually probably better than Firebug. Drush is a command line tool to use Drupal and it can do almost everything you can do with your mouse clicking on a Drupal site and there are a lot of sessions about that and buffs. So if you don't use Drush, you really should. You can do almost any administrative task that you can click on from the command line. XDbug, as Juan mentioned, is primarily PHP Debugger and Dread Editor is probably the one most people don't know. It is a browser extension. It's actually just a Drupal project, Drupal.org slash project slash Dread Editor and it improves your browser in a way to help it makes the issue queue experience a little better. So an example would be if you see a patch, find a patch. Yeah, you picked the wrong issue. There you are. No.  When you find a patch, that's an image. When you find a patch, it provides a way for you to view and comment on the patch in your browser without downloading it and it gives you a review button that you can click on and it loads the entire patch in a nice little JavaScript overlay and you can click on parts of the code and leave a comment and it'll post it all in with the context of where you are in the patch into your issue comment. So if you've ever seen those huge blocks of reviews by people where they have like inline comments on all the code in a patch, that's how they're doing it. So yeah, it'll look like that. That's how everyone does that. It's a browser extension.   It's very, very, very useful and if you spend any time in the issue queue and you actually look at patches, you should install that. This is great. For example, when you review a patch and you want to mention a specific line that is wrong with it instead of copying the beta and pasting it, you can just format it in this fancy way. Okay, so next slide. Yeah. So let's say you found a bug and you submitted an issue and you know what you're talking about and you want someone to actually look at it now and then it sits there for like three weeks. How do you actually get someone to look at it? I can think of four ways. The first is what we call triage and it's like the medical term, but it's where you just go through the issue queue, sort by issues with the least number of comments, so mostly zero and you click on it. Someone else's patch, not yours and you look at it and you see, did they file it correctly? Is it against the right module? Is it against the right version? Did they set it to critical support request? Don't ever put something as a critical support request. It doesn't actually exist. There's no such thing. And just having one comment on there, as you said, like it will ping the maintainer and it will kind of bring that issue back to life again. And if your issue is the one with zero comments and you make all the other ones have at least one comment, someone will then look at yours. And that's what there's a lot of, this link takes you I think to the triple core one. There are something like 3,000 issues that have no comments on them. You know, some poor soul found a bug and no one looked at it yet. It's not nearly as bad as in contrib, trust me. That's the easiest way for someone who doesn't write code to help. It's like thinning the herd of what's left for them to look at. As long as you can read and understand Drupal modules, not the code themselves, you can help there. If you are a coder, if you have a patch and there's a bug, if you write an automated test, it will get committed within a week, almost always. The quickest way to get a patch in is to write a test for it. This link takes you to the Drupal.org simple test instructions. The other thing is if you go into IRC and you say, I want to help write a test, like three people will stop what they're doing to help you. You can go into IRC and get ignored for weeks, but if you volunteer to write a test, they will drop what they're doing. The other thing also works better in IRC but also in the issue queue is you can trade patch reviews. So if you are looking, you have a views bug and you see another views bug patch written by someone else, you can find that person and say, well, you look at my issue and review it and I'll review yours. The bugs go away a lot quicker when everyone's working together. The other thing is if you roll a patch and three weeks later there was another commit that broke your patch, just re-roll it. It's a nice way to bump your issue back to the top of the list but to also keep your patch updated. There's nothing worse as a maintainer than coming to an issue, seeing a patch and having it be so old that I can't do anything with it. So keeping tabs on your patches and re-rolling them is a good way to keep your issue top fresh and ready for the maintainer. Just to note here, re-rolling means updating the development version that you have of that module and see why your patch that you submitted three weeks ago doesn't apply. Maybe a line change, a comment, it can be anything. What you're doing by re-rolling is updating against the latest development version so it's still valid and someone can still apply it quickly in a local environment to test it. Any questions? How to safely patch your site. Disclaimer, safe is not a strong word used here. It's safely in my opinion. There's a lot of problems where you patch a module. You're not hacking the module, you're patching it and then a new version comes out and all of a sudden, if you update, you lose the changes you've made. And maintaining that over time can take a long time. It can be error prone. And who's had problems with that? Have you ever run a site and tried to update a module and lose all your fixes? Yeah, it's pretty rough. The way we do it at ZipTech and a lot of other shops is you create a folder in your repository called patches and you put every single time you change a module or core, you put the patch that you upload to Drupal.org into that folder and you name them well. Because if you have foo.patch and astf.patch and thing.patch, you're never going to know what module to apply to. So the convention is the module name and then the issue number and the comment number. And if you have multiple patches, it can be helpful to do a comment name, some string describing it. So this was a Drush bug with the archive restore functionality. So it's Drush archive restore, the issue number and the comment number. And that way later, if someone changes your patch, you know, oh, this was from comment five. Now there's a new patch in comment nine. So you can swap it out and always have the latest patch in your repository.  Do I have any patches against that? And this link down here is a sandbox I'm working on to build a site for yourself to keep track of this for you. So what you do is you just enter the issue number and it, you know, every cron run it looks and says, did someone update that issue? Is there a new patch? Did it get committed and updates your site accordingly? So you get a nice chart of, you know, what this looks like. It looks, if you go to, we're using the same functionality to help run our core sprints. So if you get a Drupal office hours.org. Can I get any from here? That's just in a new tab. Drupal office hours. Yes, that one. So this is the views one. So this is the same, right? Yeah. This site is loading. Yeah. So, well, those are all committed. So these issues are issues we're working on to put views in core. And whenever something happens in the issue queue, all of those columns get updated automatically. And at a glance here, we can look at these are the issues I'm working on to work on this initiative in this module's case. It's more about I'm using for this site that I'm building, I have these patches and then you can just check this or have it send you an email and say, Oh, the module got updated. Check your patch or someone posted a new patch. Go find that patch and see if it's better. So I, you know, it hopefully it'll make our lives easier when we are in our workflow. And I think other people might use it too. Issue queue. Oh, back issue queue etiquette. So the issue queue can be a contentious place sometimes. A lot of times if you're not patient or if other people are impatient, it can get nasty. Has anyone been in an issue where things got nasty before? Or have you ever seen an issue? Which yeah, we're, well, you go into core queues. So, but yeah, it can get, you know, people, tensions run high. They have a client who is angry because their site is not working and they need that patch committed. Yesterday, that will get you nowhere. And in some times it will literally get you nowhere. Some maintainers may just say, I'm not going to commit this. Like you were rude or you were impatient. And it's my module. And each issue queue is different. Each maintainer is different. So the best bet is to just be nice to everyone. And the number one thing, as I said before, don't abuse critical or even major. You know, like humility is a good thing. Patience is a good thing. You know, acknowledging that your problem may not be the biggest problem in the world right now and everyone needs to stop and look at it. That will get, that'll go a long way. And going back and saying, oh well, you know, I'm working on Drupal 6. This issue is on Drupal 7. I'm going to switch it back to Drupal 6 because that's what I care about. And then said, no, no, no, we're working on Drupal 7 and you switch it back again. Like that doesn't get anyone anywhere. All it does is waste everyone's time.  A lot of it is codified in the Drupal Code of Conduct. The Drupal Code of Conduct, which is borrowed from Ubuntu's Code of Conduct, illustrates the best ways to interact with other people in a virtual and, you know, community environment. And has a lot of, you know, very well established ways to just, if you're having a problem with someone, just, you know, take a deep breath, back away.  And that really, you know, reading that every once in a while and remembering that the issue queue, people you're interacting with are people too, you'll get more done. The final thing is the issue summary template. Whenever you go to edit or create an issue, there's a big blue box at the top that says, here is the issue summary template. And it basically codifies a way to, if you go to the, just edit the issue, you're posting a comment, so, yeah. So if you edit the issue, it gives a nice structure. And the, it's- That's a new one, right? Just hit edit. It's there too. It, the problem and motivation, that link, yeah. The problem and motivation for this, and it actually gives you an HTML, it's literally a template. You copy this into every issue, or you should copy this into every issue you see. The problem and motivation, you describe what is wrong, or what you're trying to do if it's a feature request. The proposed resolution. And when you first open an issue, you may not know what the proposed resolution is, but over time, who's read through a hundred issue, a hundred comment long issue, and it changes direction like four times. It's like, first we're gonna do it this way, then two months later they decide to do it a different way. And you blow three hours reading through that. Anyone ever done that? Yeah, it can, and think about all of the other people that read through that too, and think about all the hours that are lost. So the idea here is when an issue changes direction or decides to go a different way or some new information is found, the issue summary at the very top of the issue is updated. So in theory, all you have to do is read that, those four paragraphs, and then you know what happens, and you can skip the first hundred comments, which saves everyone a lot of time. This is done mostly at core, for example. It's a relatively recent thing, and core is where it started. It's actually one of the initiatives. I think Jess is the one who started with it. Basically, one of the great ways to help contributing is just by reading what has been discussed and using this template to edit the first comment at the very top. So it really contains everything that has been discussed in a simple summary. Anyone at the Drupal.org account can edit any issue now. That's a couple months ago, but any of you can go and click Edit and edit the original post. It's common courtesy to leave their original text and add stuff above it, but not everything has to be in comments. If there's some sort of consensus, that can be put at the top so that you cannot waste everyone's time, and everyone can know what's happening. So the problem motivation, the proposed resolution, which generally comes last, but the remaining tasks says, I need someone to test this. I need someone to test this in IE. I need someone to go through and manually click and do these five steps to make sure that I'm not crazy and this is actually really a bug. And then once an actual idea or change has been proposed, especially in core, we're trying to be very careful about user interface changes. How will this change? Is it going to move the button from over here to over there? Is that going to confuse people? So views, for example, in Drupal 7, we try not to change anything because there's so many books and blog posts written that have screenshots and we just don't break those so that we don't confuse everyone. API changes I think is the next one and that's for programmers. Like if we're going to change how a function works, we have to tell people that. And we don't do that in the middle of a release but that's how you know how to update your module from Drupal 6 to Drupal 7 or Drupal 7 to Drupal 8. Someone writes down, this is how you used to use this function now use this function, etc. And that's it. Are you stretching or asking a question? Oh, you're stretching. Yeah, any questions on that? So at the end, we took from Ubuntu its code of conduct. It basically says that, you know, the better you behave and the more constructive and positive you are here, the more you're going to get. Actually, I don't know, I can share a quick experience when I once found a bug with the Twitter module and I submitted an issue with a patch, nobody reviewed or somebody did after some time but then I found that the maintainer wasn't really helping on the issue queue. So instead of maybe blaming him or yelling in the issue, you can find some very nasty ones. I started helping with other issues and asking our IRC and after some time, more people got involved and I actually started maintaining the module because the actual maintainer didn't have the time at that point to keep up with it. So during all that time, I started understanding how did it work, all the APIs it used and that in the end shows you how much can you learn by just helping on the modules you use and spending some time from your free time browsing over them. So that's the end of our session. It's the end of our slides. We still, we have just a plenty of time. Does someone have a story they want to tell or a question they want to ask or ask for, you know, yes. If you could come up to the mic for this section so we can get it on the recording. Our session title was very long. So we have put there a shorter link in case you want to add a review about it. Okay, I think it's an issue we had with a module that has, you know, a lot of issues happens when you combine multiple modules and interact with each other and I think sometimes the people would say, all that issue is only related to that module. So I think that maybe the issue queue system doesn't manage that very well and I don't know if it's the people's responsibility to take care of that like solving an issue just because it doesn't interact. I mean, you know. Yes, that's actually the hard, one of the hardest problems is when two modules don't play nice with each other and it comes down to a lot of times. So this is the other thing. If you think if one module is broken, you file it in that issue queue and if someone says it's always the other module they can move it. It can always be moved and sometimes it may balance between two modules. I had this similar problem and the maintainer said, that's not my fault, it's the other person's fault. And I went three months before they figured out it actually, it comes down to it's someone's responsibility to solve it and getting to the core of that and saying, oh, okay, well, sure. No one's wrong here, but someone has to fix this. Which module does the fix make more sense in? That's, and that's, you know, no one wants to be wrong. So rephrasing it in that way and saying which would be easiest and where's the quickest way to get this done when it comes to a standstill like that? At the end, somebody has to do the proper debugging in order to understand and demonstrate what's the best solution. I don't know. The first time I worked with core, for example, with a core issue, was because I found that a bug in fit's module which the maintainer told me in the issue that it wasn't a fit's fault. Then I went down to see tools and then Merlin of Chaos almost killed me because I introduced a bug into see tools, fixing that thing. That went, that got reverted and then I got down to core where Sun had all, had just created a fix for that, for that. Then that whole after some discussion and then it went back to see tools and back to fit's. Nine months later. Yeah, that was, that's what normally happens sometimes.  So it wasn't just the PHP error we were getting at fit's module. It was something that was down in core that wasn't properly right and was provoking that other modules weren't implemented. So implementing some paradigm correctly. You had a vision? Yes. You know, how do I fix this? Yes. Right. And they would fly back to me saying, oh, you can change the module of that. Yes. You can change the module and you can bat and say, I do, yeah, I need advice. I don't know your module. How do I fix it? Because, you know, even if, yeah, if you know it's your problem and you have to fix it, but you don't know how to, you can get advice from someone else just by moving it to their issue queue. And so don't be afraid to do that, especially when you know, oh, these two modules don't work well together. The other thing is you can open one issue in each queue and point them at each other and say, oh, this one, like I open one here and I open one here. Know about the other ones, like someone figure it out and then at the end one will be closed as a duplicate, but it gives both of them a time to, a chance to react to it. So someone else? What are the standard recourse options available if you submit a bug or an issue and no one is able to fix it? Just source problems? It sounds like there's a specific example you have in mind. It's happened a few times. So with micro data module or voting API module, it's not supported for specific things. And there's maybe a niche group of people who are affected by it. And there's not enough resources for the developer to actually focus on that one thing. So what is an alternative? I've talked to a couple of people about doing something like setting up a chip-in for a specific... You just took my answer. Okay, but I was wondering if there was actually an effort then to organize that? There was a discussion of formalizing a way to set up chip-ins per project or per issue. That was postponed because they're still in the middle of upgrading Drupal.org to Drupal 7, but they're actually talking about that. Ability to say, look, I will pay you to do this thing that I need done. That's a possibility. And but you can do that on your own. You can contact the maintainer via their contact form or you can go in IRC. And that's... Sometimes money is the only option at that point. But generally, a lot of times it's just a visibility thing. There are so many bugs. And being proactive about it helps. Besides, some maintainers don't even have the email notification from the issues. So sometimes, for example, if they go for a trip for one or two months or... Yeah, people go on vacation. They don't check at the ideopayatation.drupal.org. They don't realize that there is a problem there and that you need help. So that's why the personal contact form that it's available on each user's profile, it helps. It sends an email. And if that doesn't help, you can go to the Webmaster CQQ and ask there for help. Just saying that this module doesn't have any support. And you'll get a response. There's an unsupported modules queue where modules go when they don't have someone to maintain them. And people take them over all the time. Like some people will... New people looking for something to do will look through that list and say, Oh, I can help with that module. So if it just sits there and everyone knows that no one is supporting it, but no one says anything, then it's not getting done. That's actually the link. Yeah, unsupported. It used to be called abandoned, but that was too scarring or something. I don't know. Yeah, that's... Because as a module maintainer, if you're not actually supporting it, you should mark it unsupported.  So that's why they changed the name to remove the guilt from the maintainer. Actually, here are steps for people who are reporting issues, but they are not able to maintain the project. Here are some resources for you to follow. And actually here, they mentioned the Webmasters queue, which is just another project that it doesn't have any code. It only has issues related with Drupal.org. So now you all know how to use the issue queue perfectly, and they'll never have a problem again. I hope. Any more questions? All right. Thank you very much. Yeah, go ahead. Yes. It's also our topic. Just who is this Stanley Kubrick fan? I wouldn't do that.


The Tiger financial news network Welcome folks, we have the now industrials trading down 77 Nasdaq's up 22 S&Ps up one and a half gold gold contract down $10.90 trading at 2008 and ounce We have silver up 17 cents 25 dollars 44 cents an ounce light sweet crew down a buck 65 $79.29 9 cents up 21 cents a barrel notes and bonds a 10-year note Down a tick straight in 1 14 0 7 the 30 year off 10 at 129 23 and King dollar King dolls up 219 ticks trade in 101 964 the year is at 109 the yen is that There we go the ends at 134 and the British pound is at 124 to 1 US dollar We get over and take a look at the market folks What you're gonna have here same deal, you know bottom line get less volatility out here and You know you rejected lower price out here at 412 you're at 414 in the spy and It looks to me like that's still game that for 418 out there now. What's intriguing is that the way? This is a little setting up today if we had if we had a bigger day that would have been a lost engulfing But bottom line that's not there yet And I don't expect it to be either by the way if we take a look at that the cues same type of set up inside The cues bottom line you started out at the lows, which is that 316 you're at 319 right now The high that it's trying to test, you know yesterday. We almost got it. We just missed it yesterday The highest trying to test out here is that 3? 21.63 and it's all about this US dollar So the doll you can see the dollar this morning the dollar this morning bottom line You know it was up, but it was weak, you know and you got up to a price point of that 102 228 You're at 101 964, you know and we're back on here higher dollar lower market You know dollar goes sideways market can get some traction So it's kind of a cut-and-dry deal out here once again, which is pretty cool trading wise Gold gold contract. I suspect is gonna, you know bottom line pull back a bit more. You get we I Rejected lower price out here today at the 1980 mark, you know, but you had 209,000 contracts That's that's that's a little too much contract volume as we're pulling back That's the bottom line So I suspect that we are gonna get back into the 1900s inside of the gold market stare at their folks who come right back