 OK, hopefully pressing that button means that we are now alive. I see that it started recording. So hopefully we're up and running. I see the number of participants slowly beginning to rise. So hello everyone. I'm Rachel Lawson. I'll do some introductions in a little bit just as we reach time to get stuck in. I'm seeing some things. So I wonder where you're all from as we wait for people to come into the room. Please do use the chart. Tell us where you're from. Just write your country or your state in the U.S. or something like that just so that we know where we are. Just write it in the chart. Hello. Oh, we got someone from India. Praveen, hey, how are you doing? I'm in the San Francisco Bay Area. Well, actually, someone schooled me recently and told me I'm outside the San Francisco Bay Area because it takes me 12 minutes to get to public transportation to get me to San Francisco. So I'm 12 minutes outside of the San Francisco Bay Area in California. Well, I'm actually in the UK. I'm in a county of Norfolk in the UK, hence my Twitter handle Rachel underscore Norfolk. And yeah, we've got lots of people coming in now. We've got someone from Bolivia, Chicago, Colorado Springs, New Jersey, New Jersey. Someone spelt it. Mississippi State, London. Hey, if you're in there. So you're a couple of hours south of me, really. Hey, Ruben here from Canal in Spain. Hi, Ruben. I hope everybody's enjoying the little event you've got going on there right now in Canal in Spain. So we'll give people another couple of minutes because we're in no rush. We're in no rush. We'll do this right. We'll take it from there. So we've still seen a few people coming in. Flores is down there with Ruben in Canal in Spain, which is great. We'll see how things are going. We've got quite a few people in the room already. Which is always good to see. We've got my friends to be there as well. More people coming in. We're into very reasonable numbers. It's working, is this? You might find that I'm occasionally unsure which button to press because I'm not used to using the webinar function in Zoom. I normally find myself doing that in big blue buttons. So this is completely new to me. We've actually been discussing big blue button in some spheres across Drupal land these days. So I'm really excited about learning more about the project because there's a lot of peaked interest. And these open source as well. So if you don't like something, you can go change it. Which is always quite nice. Maybe somebody will want to do that after this. You never know. Hi, Kareem. Good to see you again too. Okay, numbers are still climbing. So I'm going to give it another 30 seconds or so and then maybe we'll make a start. That seems a reasonable amount of time. Because I don't want to keep those people who are here straight away waiting. Because we've all got busy days, I'm sure. Especially after yesterday and the Fastly content delivery network outage. My goodness. We've all got lots of catching up to do. That's for sure. Okay. Right, well I'm going to make a start. So welcome to everyone. I'm Rachel Lawson from the Drupal Association. I act as the community liaison there. And I love to hear from people in the community and adjacent to the Drupal community all the time. So please do find me on Drupal.org at rachel underscore Lawson. And come and say hello. Today we have with us Amy June Heinlein. So thank you Amy June. I'd just like to introduce to you. So Amy June is the open source community ambassador at Canopy Studios. A key agency in working in Drupal. As a Drupal core mentor and now beginning to act as a Drupal core mentoring lead as it happens too. You need to update this bio. With a dual focus on both open source community development and inclusivity. She's uniquely placed to help individuals become more comfortable and confident as they contribute to their communities. Amy June has got a vast experience co-organizing various open source camps and contribution events throughout North America. As a self-described non-coding developer I like that. She focuses on lowering the barriers to contributions helping communities and individuals discover how they can contribute and belong in more ways than code. Amy June is an outside of open source. Amy June is a lover of vintage air-cooled Volkswagen's which might explain Amy June's username which is Volkswagen Chick. And you can find her in the hills of Northern California looking for geocache treasure and playing Scrabble in the Sun. Sounds fantastic. Welcome Amy June. Thank you. The floor is yours. So I want to preface the presentation that this idea and these concepts really come from my deep desire to standardize attributing contributions outside of code to our community members. So I'm going to present some information about current community projects and how they need support. And then I want to close with a demo on how to create your own community project a meta issue and how to break down attributions you know break up an issue and give attributions to different people. So with seeing that I'll get started and like Rachel I have to find buttons. I do work at Canopy Studios. We design, build and support websites for clients that make positive impacts and we're hiring. We're hiring Drupal developers and tech leads. We're hiring project managers and then in case some WordPress folks are coming over to find out how Drupal contributions work we also work in WordPress and are hiring WordPress developers as well. So a little bit about what we're going to go through today. I'm going to talk a little bit about why we contribute and some of the benefits that we get when we contribute beyond the feel good altruistic part of it. We'll talk about community projects. We'll go over some Drupal initiatives. We'll talk about how some passion projects were turned into community issues and then we'll talk about attributions and credits. And then after the formal slideshow I'll do a demo where I'll create a community project on the fly and then I'll walk through creating an issue and giving attributions on sort of the thousand foot level. We won't get too granular but just an idea of how you can break things down. So we always hear, you know, come for the software stay for the community but why do we contribute? First, there's the little bit of the guilt factor, right? You know, we heard Jury's talk about makers and takers but if you depend on open source then open source depends on you and some of these other points will kind of dive into that a little bit deeper but it's a community and all people contribute in different ways. Our contributions are really valued. You know, not everyone uses Drupal or approaches the community in the same way or level of engagement either, you know. And that's absolutely fine and that's probably perfect because everyone's unique perspective is important when we build our products and build our community, especially with our software. You know, you think, oh, this bug is an edge case or, you know, my specific demographic is a use case. Well, we're not. We're all in this together and if we don't see each other's perspectives then, you know, we're not a whole community. You get what you give and of course you get more than that. You know, you practice and improve your skills not only for that code aspect but in leadership and management skills. You know, the more you contribute, the more you learn and Drupal also provides incentives through those attribution systems and these incentives can help drive more contributions. You know, it's that cyclical thing. You know, the more people feel better, the more they'll contribute and then, you know, it's just like, you know, I wouldn't say downward spiral but like the momentum keeps building and then contributing makes you feel like you're part of that broader Drupal community. You know, you go to camps and you go to conferences and you go to meetups but now there's another reason to go to go to Contribution Day. You know, you meet people with similar interests. You build relationships and friendships and a network that can last a lifetime. The Contribution Days are really unique. You know, you can pick up a mentor. You can start mentoring. That extra day, lots of people, you know, go home or only stay for part of it. But once you get into that contribution cycle, staying that whole day and staying afterward for suppers and dinners really builds your network, especially with mentoring. So let's say you work for an agency and your agency, excuse me, might not be keen on why they should pay you to help give back. So I want to give a couple of reasons why agencies should give back, you know, along those sponsored contributions and this goes to that higher level of takers and makers, you know, not only software developers using it but the agencies are using those CMSs for free too. So companies who are consuming Drupal as that free open source project should certainly give back. I mean, there's really no argument against it. You know, they should appreciate the value of helping each other. It helps reduce redundancy and duplicating efforts, you know, if you're working on a website for a client and you find a bug, you can give that back to Drupal within a few minutes, you know, and another agency who experiences that same bug doesn't have to duplicate efforts. And in our industry, the tech industry, software industry, you know, using and contributing to open source software is seen as basically good corporate citizenship and can be seen as part of a firm social responsibility, you know, back to that if you depend on open source, you know, it depends on you. But it's fun and rewarding for employees and your even agency owners and CEOs. It's fun and rewarding to work closely with the smartest people in the Drupal community. It really, really helps with employee retention. You know, the more you give back, the more you get back. And this is really reflected when potential employees and partners view your agency pages on Drupal.org too. If community is important to them, they can go to your page and see how often you contribute, who on your team contributes. They can see how valuable it is to an agency. Okay, so shifting gears a little bit and looking at community projects because that's why we're here today. So first we'll look at some Drupal initiatives. And these are initiatives that are already established and they're looking for contributors. So I wanted to start here because sometimes creating your own project can seem a little bit bigger than it is. So maybe helping and volunteering on a project that already exists is a good first step. So promote Drupal. Promote Drupal has one main purpose. It's to create marketing materials targeted to people who make decisions about whether or not they use Drupal for their business. Did my slide change? There we go. Okay. So these are broken down in two ways. I'm going to introduce the initiative and then I'm going to talk about what they're looking for just so you can see. And then underneath the title, you can see that I give a space where you can contact people, where you can find where you can go and then if they have regular meetings, I have that listed there too. So promote Drupal. There's a project that's been around for a while, but they've just started breaking down their roles and committees into different levels. And actually this weekend Slack, if you go to promote Drupal in the Slack space, you can see in their meeting some really valuable notes. So some of the things that they're looking for, they're looking for marketing and community members for outreach. They're looking for 20th birthday committee members, Drupal ambassador committee members. This group, their goal is to spread the word about Drupal and communities outside of Drupal universe, focusing on attracting new talent. There's the strategic initiatives marketing committee. Their goal is to spread word about Drupal's innovation and highlights the work of the strategic initiatives. And then there's the evaluating evaluator marketing committee and their mission is to improve the onboarding experience for evaluators. So like I said, they just recently kind of broke down into subcommittees to make it easier for people to find what roles they might fit best with. Drupal mentoring, this one is near and dear to my heart because a lot of folks journey into Drupal might start with a mentor. So I'm a non-code developer and it's a niche that I did not find easy in Drupal, but how I found my niche was I latched on to someone and they helped me and they're still my mentor. So because that helped me so much, this is something that I do. It's sort of that leading by example. The Drupal mentoring team is a group that supports mentors on a daily basis, but your level of commitment can fluctuate. We organize follow-up activities and we help the Drupal Association manage mentoring within the community. If you have experience contributing, you can help others get started by becoming a mentor, especially now that the geographical barrier is reduced. There's lots of online opportunities to help with mentoring these days. Working with others on a shared project means you'll have to explain how to do things as well as ask for help. So you learn a lot when you mentor as well. That act of learning and teaching can be really fulfilling. Again, the space is mentoring in the Drupal Slack channel and then we actually meet monthly on a Wednesday. And I think this time might be wrong because I say 9 a.m. Pacific time, but I think it might be noon or one. So I took this off a calendar, so this isn't right. But we are meeting today. So if you want to join that channel and kind of check out how we do things, perfect opportunity. And then I listed some things that we're looking for. We have a new program in Drupal called Discover Drupal where we're training some new folks just learning the skills being site builders and they're actively looking for mentors. We're looking for folks to help us with our community tooling, especially as things are developing and changing. We want a consistent tooling set from event to event and a consistent tooling set for when people contribute. We're looking for folks to help with first time contributor workshops, not only at DrupalCon, but at the local and regional level as well. And then that gets broken down into, you know, triaging issues, planning the major events. And then when we have a major events, we break it down into, you know, having a mentoring room lead, having a communications lead. If we're at DrupalCon, having someone sit in the booth. And this is an excellent opportunity to meet your community. Even if you haven't mentored and you're going to mentor on Friday, you can have booth duty on Tuesday, learn from the person you're sitting with, talk about all the different things. But it's a great opportunity to meet people who are interested in contributing. And then of course, like every other project, we're always looking for help with documentation. And as a new mentor, you are the perfect person to contribute to the documentation because all of us have been doing it for a while. So we skip steps. Just like encoding, we make assumptions. So all different types of things you can do with mentoring. And feel free to reach out to Rachel or I because we're both very open about getting folks onboarded for mentoring. The Drupal Recording Initiative, if you've been to any local North American camps with some European camps, you've probably seen Kevin running around, pushing the big red button. The idea behind this initiative is to make the recording of Drupal and Drupal adjacent talks at summits and camps and meetups. Anything outside of DrupalCon. Really want to make the process like easy and turnkey affordable and available. Kevin is not the only person who records these sessions, but he's definitely the loudest and the most prolific and your best point of contact. And there's all different things. So video is your passion or getting information out there is your passion. We're looking for training and mentorship, improving camp support and ongoing recruitment. We're definitely looking to expand the coverage. Shipping kits and covered more than just North America. And Kevin can't go to every camp. So if there's more people to cover some of those camps, come on board. Again, looking for people to help move documentation into GitHub and add visuals. Kevin's really looking for a better recording success rate. And that means really going back to that training and making sure that we have a better partnership, better preparation for volunteers and contributors for onsite coverage. And then working on funding, you know, it's expensive to go to camp to camp. And then overall organization. And then the content discoverability is a, is a good first step for involvement because that involves like looking at the content and curating it. Tagging it with. With, with either the camp name or the topic or the speaker. It's just the way to get involved in that. It's just getting at accessible and adding captions. And these are good ways to get involved. Where you are, you know, because this isn't just an initiative that means going to camps, but you can do stuff from the glory of your living room too. And then it's Kevin Thule. So he's K. Thule and Drupal Slack. And then he has a Drupal.org project. Project slash DRI for Drupal recording initiative. This group welcomes all types of contributors, you know, programmers, content managers, project staff. However you identify as a contributor in a part of the Drupal community, there's definitely a space, I have to move because the sun's in my eyes, there's definitely a space for you to get involved in the D&I group. They really continue the conversation about Drupal and diversity and inclusion and equity in their Drupal space. They meet every two weeks in Drupal Slack, and they have a few different Slack spaces, they have diversity dash inclusion, but they also have specific channels to help with specific needs. They have a session help channel, they created this channel to help people, particularly those from historically excluded or underrepresented groups, to help prepare people to talk at camps and conferences, to get more faces visible, you know, have more people's faces that look like you visible when we go to camps and conferences. There's the speaker initiative. I work on this in the WordPress space, and sometimes I take it to some local meetups here before calls for papers. This is an online event where we train speakers and we talk about imposter syndrome and we talk about leveling up speaker skills, brainstorming and selecting topics, you know, how to develop a pitch in a bio, how to outline a talk, and this is a really easy space to get into because I have a slide deck and people can run with it, you know, they can help me with one and then give one in their area, so this is a pretty low entry point, and then they have a few more Slack channels, you know, they have a career channel where people can post different career listings, and then they also have a contrib channel, DDI contrib, where they work on things like the gender field and other diversity movements there. The events organizing working group, they're concerned with supporting community-led events within the Drupal community. It really supports those community-led teams to grow Drupal through local events, so this is, if you think about it, a little bit of an extension of the promote Drupal initiative, you know, we're really getting the word out there about Drupal, you know, and there's different people who come to these events. There's people who are looking to start an event, people who have been running events forever, but when we think about events, we also think about meetups, you know, those are those more informal gatherings of people interested in Drupal, you know, more aimed at the local knowledge and community, and then there's camps, you know, those are one or two or three-day events that focus on Drupal, and they bring together more of the geographical area, and it's usually an extension of a meetup, like I run at San Francisco Drupal users group, and then we have Bay Area Drupal Camp, Bad Camp, so, and we kind of get filtered in from other locations, and then there's DrupalCon, you know, this working group doesn't necessarily work with DrupalCon, but DrupalCon is always looking for volunteers as well, and DrupalCon, of course, is that global or continent-level gathering, and it runs several days to a week, you know, and it consists of contribution events, trainings, keynote sessions, usually these are more organized by professional event planners in conjunction with the DA, but there are tons of opportunities to get involved in volunteer, and some of these things, these little tasks, these little volunteer tasks, can help spark you and give you, give you just enough to push you over into, I can lead the trainings part of Bad Camp. I think I can take, you know, it sort of gives you that inspiration to like move up in the role system, and then as far as event organizer and volunteer roles, you know, there's all different kinds of things. First, they have their own specific Slack channel, you can reach out to me if you can't find it, but it's called DrupalCamp Organizer Slack, and they meet the second Tuesday of every month and they alternate what time zone to make it more inclusive to the world population, but we talk about all different kinds of things, and this list though is more about what you can do when you're at camps at the volunteer level, you know, there's not just the website, but there's marketing and social media, there's retweeting, you know, there's help programming the content, you know, you can help organize training sessions or contributions, you can help with the financings and be part of the nonprofit team. Social events is super important for networking, you know, we get together, but that community building sometimes happens, you know, over a cup of coffee or a beer. You can help design, you know, the logos from year to year, you can help help the t-shirt designs and help with the print in the in the swag that we give away coming up with different and new ideas of things to give away, of course, helping with audio and visual. Volunteers are great, but they need some hurting, so camps are always looking for people to help with coordination of volunteers, and then of course, you know, accessibility, that can mean several things that could mean helping with the website or making sure that the menu is accessible, you know, to everyone involved. Diversity, inclusion, inequity, making sure that everyone is represented, you know, that we have faces from all different places, we have all different voices of skill levels, all different topics, you know, diversity and inclusion, like any topic that you can think of has a need for more voices. And then of course, you can help with code of conduct. The community working group, which I'm going to talk about in a minute, puts together events that can train code of conduct officials, you know, but this is important because people want to feel safe at the events they go to. So if that's something that's important to you, you know, you want to make sure that everyone feels safe, you know, definitely volunteer for code of conduct. And that was a good segue into the community working group. The community working group is actively looking for folks to help. We do have a team, but we are, again, the more voices, the better representation we have makes us a better group as a whole. The mission of the CWG is to foster a friendly and welcoming community for the Drupal project and uphold the Drupal code of conduct. So that's it in a nutshell. We have in the last two, it's been two years now, we've broken it down a little bit more. We have a conflict resolution side, you know, this act, this, this is the group to maintain document, wait, no, the conflict resolution team deals with the code of conduct stuff. They are actively looking for people to help fill that role. But the onboarding process of that is joining the community health team first. So we have a community health team. And the community health team really focuses on the health of the community. And we have it broken down into a community health team where we help with workshops, we help with inclusive language in the issue queue, we have an event support part where we work with events to make sure that code of conduct are up to date, you know, give them some resources. We're looking for ambassadors, you know, ambassadors can be public health ambassadors, they can be ambassadors to different open source communities. And then we're looking for subject matter experts, you know, we have a subject matter expert, you know, for diversity and inclusion. So we're really looking to make sure that we round out the team a little bit more. And we do have a space in Slack in the Drupal Slack, it's community-health. And we are having office hours quarterly. We've only done one so far, but this is something that we want to invite the community to come to. And I don't think we've established the cadence for that yet. So we'll see that sometime in July, I bet. But that's the community health space in Drupal Slack. And then I want to talk a little bit about content moderation, because when this is, there's some cues in the issue queue that reach beyond code. And these aren't quite community initiatives, but they're important initiatives for Drupal.org. And we just don't have enough folks who contribute to these cues. We have Drupal.org site moderators. This used to be called the Webmasters queue, but we changed the name to be more inclusive. We look at user accounts. We report spammers. We deal with requests to confirm new users, that kind of thing. Drupal.org content queue. These are for non-documentation content, like case studies, marketplace listings, Drupal feeds, book listings, case studies, hosting. A lot of folks will file issues that they want their organization approved for something, and we just don't have enough people moderating that content and approving it. So this is a good place to kind of get back to the Drupal community. And then, of course, documentation. Rachel and Jennifer work a lot on documentation, and it's just always needed, right? And then to kind of get involved in these cues, you can join that Drupal.org channel in the Slack space. And then for more ideas, there is actually an issue queue. If you reach out to us or we'll send emails out, we'll have a list of links, but there is an issue queue where people just post their ideas. Like, say you have an idea for a project, and maybe you're not bold enough to just start the project, feel free to list this in this issue queue, and people can start talking about it. My cursor had this idea about the Olivero theme, and that started in the issue queue, and now it's in core. So ideas come from everybody in the community. Okay, so those are community projects that are looking for contributors. And I want to look at some specific community projects just as examples where these were people's passions, and they work on them so much, and they turned them into community projects. So I'm not listening, and then any sort of order, these are just three that popped up that I want to share. Talking Drupal, this is a weekly podcast about Drupal and web development. They have guests on every week. They process a podcast every week, so they made a community project and help with attributions. Accessibility talks, A11Y talks, this is a project I am passionate about. We meet once a month and have people come on and talk about all things accessibility. It takes a lot to run a monthly event, and we have five, six, seven people helping us out. So we're actually going to look at this example in one of the demos, but we created a community project to help incentivize volunteerism. And then Damien McKenna from Media Current has this unique space, Contrib Half Hour, where people meet weekly. They were started to provide support for the Drupal community, and they discuss Drupal topics every week, and the meetings are open to whoever wishes to join them. And it's a discussion, and sometimes he has guest speakers on. Sometimes it takes us 15 minutes just to talk about what's going on in Drupal and what events are coming up. But people contributed this every week, and so people come, they get a credit for being involved. And the attribution project, before moving into the demo, I want to speak a little bit about the attribution projects, giving credit where credit is due. Good intentions are always assumed from each contributor. All of us start as beginners, and we know that there's always a learning process. So here's a few examples of contributions that should be recognized, and this is taken from Drupal Core documentation. If you found a bug and you created an issue and you followed that template and you wrote a well-written issue, you should get a credit. Proposing the solution, either in the form of a road map or a patch or a comment, if you provide valuable information that leads to a solution, you should get a credit. And of course, reviewing and testing a patch. But with saying this, you can't just review and test a patch and leave a comment that says, hey, patch applied, good to go. Leave some insightful information for maintainers and folks looking at it. Make sure that you tell what you tested and what you reviewed. Provide screenshots if there's some UI solution. We want to alleviate the burden of having to retest. So if you're specific about what you tested for, grammar and spelling looks good. Past coding standards, steps to validate were this. You should get a credit. And then, of course, adding documentation. If you can add documentation, even to the issue summary, by providing steps to replicate, steps to recreate the bug, anything that really helps move that issue forward, you should get a credit. But with saying this, remember that the crediting system is a manual process. And it's not guaranteed to be flawless. So give our volunteers and our maintainers a little grace and assume positive motivations. But if you feel like maybe you did a little bit of work and you didn't get an attribution, please feel free to mention that in the issue queue. I always just tell people to remember their etiquette. And that's a whole nother presentation. But there is like a document on issue queue etiquette, you know, follow etiquette, follow best practices of just being nice and explain your situation of what you did. And generally, maintainers will go back and re-evaluate those credits. Can I just say it's often worth making sure that saying if you're going to say something like search and search looks good, give some evidence, screenshot, whatever it is before and after, something like that, that just makes a person reviewing see that, yes, I can prove that this review happened. That's how you get credit as well. Yeah, because we all know that a patch can apply, but it doesn't mean it did the right thing. So now I want to talk about when we create our own community projects outside of those code projects. What can we do? What kind of attributions can we give in those? Well, first, just be sure that you clearly define your method for giving attributions. You know, if you actively participate in a meeting, explain what actively participating means to folks. But you can give all different kinds of credits. You can give credits for an organization of an event, creating the marketing and promotional materials, managing the project, even sometimes managing the issue queue on some of these larger projects is worth attributions. And of course, a volunteerism and adding any sort of documentation. I have a question slide, but we're going to, I think, hold off on questions unless there's something relevant before a demo, Rachel. I think I think the main one at the moment is getting access to the presentation. People are quite keen to have access to the slides. We will post those in the chat later on in the session. Yeah. So don't worry about those. I think one of the things that you talked about there that I want to phrase as a question was around putting ideas in the project issues queue. Why do you think people do that? Why do you think people need to, how shall I say, ask permission? I do this all the time with you, Rachel. I ask Rachel permission for almost everything, but you know what? I know she's going to say yes, but I need that little bit of a push, you know, to really make sure that my idea is okay, you know, that collaboration and brainstorming. I think, I don't think it's like imposter syndrome. I don't think it's an experience. I think it's just human nature to ask for that permission on something that, especially on the community project that no one quote unquote owns. You know, you don't own any spaces in it. So it feels like you should ask for community input. But you don't have to. No. So I think it's, I think it is human nature that people like to hear that they want to have someone say, yes, I'm interested in what you're doing. And I think it's got value before they start committing time. Yeah. But if anyone needs me to come around and say you've got permission, I will. I've got no position to do this, by the way, I'll just do it. For transparency, like working on this presentation, I'm all Rachel, do you think this is a good idea? You know what I mean? So it's like we all, we all are there. But I love that issue queue because going through that idea queue, there might be someone who has those same passions as you. And maybe no one's commented on their issue yet. And they feel like, Oh, well, it's not something that people want. So if there's something in there that sparks your interest, make a comment and start collaborating, you know? Yeah. And there's a lot of issues in there. And I do have to say a lot of the issues are antiquated, and they've already sort of are in the works. But there's a lot of good stuff in there. So well worth a browse through. I'm going to post a link to that in a minute. I'll have a dig. So now, I will do a few things. I will create a community project. Creating a community project. It's pretty straightforward. I'm not going to say easy because that's relative, but it's pretty straightforward. There is a page on Drupal.org. It's Drupal.org slash project slash add. And if you go here, you'll see this title of create a project. And there's all different kinds of projects listed here. There's the general project, module project, a theme project, a theme engine project, a translation project. But we're talking about community projects right now. This is a non code non code project that we're going to open. So, you know, the definition community projects can be used for any purpose that supports or enhances the project and community. Okay. I'm going to read that again. That supports or enhances the Drupal project and community. So this can be a podcast. This can be a get together. This can be anything where there's networking involved, where you bring members of the Drupal community together in a meaningful way because we know that networking and community in Drupal does help us get jobs. I'm not going to lie. The more people you know, the larger support system you have, the more mentors you have, the more you learn, the more you grow and the more opportunities open up. So I even though this does not have the word networking in there, I do fully believe that if you have a networking project where you put something together quarterly or at local camps, definitely include this in a community project because they do take time. And it's a good way like you can do something for a year. You have a community project and you want to create redundancy. You have someone else come in and take over that role and they start doing it the next year. So anyway, we're going to create a community project today. So if we select this, and I already had the tab open because I didn't know if we'd have internet, it opens up this create community project. And it's just a form with fields. So it's pretty simple. And actually what we're going to do today is I'm going to find my notes. And I am going to I'm actually getting interviewed for a podcast after this. My friends over at Lando have a podcast called DevQuest. It's about your career journey for the modern web. So it's kind of case studies for people. You know how we post case studies on Drupal.org. These podcasts are very much like that. So for the sake of brevity, I have everything in a doc and I'm just going to copy and paste. But you can see the name. So we're just going to do DevQuest podcast. What kind of project is it? We're going to call it a full project. What's the short name? This is that machine name that's going to be after the slash project slash. So be mindful because this short name, this machine name will never change. So this is something like if you want it changed, it's like a long process like dealing with Neil Drum and all those kinds of things. Believe me, just get it right the first time. Okay, I do not have an image for this because just to be transparent, I did not look to see if I could put a logo here for for Lando. So I'm going to leave this part blank right now. We're going to select this as actively maintained because we're going to have two developers working on this every time they do a podcast. We're going to say these are under active development. Now these are more for those code projects, but it's a required field. So I just kind of use your best guess here in the description. Okay, again, for the sake of brevity, I already have this sort of mapped out. So my description, I talk a little bit about what it is. I talk about how we can find them on the web, who the host is, and then at the end, if anyone has an idea, there is a summary here. So let's just edit and add a summary. And if we scroll down, you know, if you had some files you wanted to attach supporting the organization, this is going to be tandem because they run Lando right now. How they helped, they are supporting organization. Can I spell that right? Okay. Components. Now this changes from from project to project and you'll see in the issue queue how this fits in, because this is a community project, we're not going to have any code. What we're going to do is we're going to change these. We're going to have a marketing component. We're going to have an episode component, and we're going to have a documentation component and a miscellaneous component. That way, if something happens later on, there's sort of a catch all for that. If I scroll down, you know, you can insert your own summary template if you want. Submission guidelines, this is where you can maybe fill in your expectations for attributions. And a lot of these, you know, on these community projects, a lot of the information isn't necessary and you can add it as you go, but you can see here, there's some different fields you can do. But essentially, you know, I've entered my name, I've entered your summary, I've entered a description with some helpful links for folks. And then I'm just going to hit save. Now, once I hit save, I have an issue queue. I have a place to track issues for people who help with this project week after week, month after month. Now, because this isn't my project, I have buttons up here where I can change different things. So I have a maintainers button. So what I'm actually going to do, I'm going to add a maintainer. So I'm going to add a maintainer, I'm going to add Dustin, because this is his project, I'm going to give him all of the permissions and update. And you can add as many maintainers as you want. So if you have a community project where you have three or four organizers, this is where you would add them. So that's a little bit of the attribution process too, is because only maintainers of these projects have permission to fix issues and give attributions. Okay. So now that we've created a project, what I want to do is I want to show an example of a project I've already created and talk about breaking up issues into more workable chunks. So I work on San Francisco Drupal users group. You can see here's our project page. We've added an image. We have our issue queue on the side. We have expectations. But I'm going to open the issue queue for folks. And what I've done is San Francisco Drupal users group is a Drupal meetup where we meet twice a month because of the pandemic, our geographical barrier was reduced. So we have so much good content that we meet twice a month. But running this virtually is so much more work than just going to the pub and sitting down and talking. So we've broken up our issues a little bit because it is so much more work. So you see my issue queue and what we're going to do is we're going to look at our meta issue for this Thursday's meetup. Jen Lampden is going to come and she's going to talk about backdrop. So I've created a meta issue where I've clearly labeled that this is a parent issue. Here it is. Here's our meetup. But with an extension of that, I've created and broken up the tasks for this meetup into child issues. I've created a marketing task. I've created the video production and uploading task. And then I have a task for event posting because we post the events everywhere. So if we look here, you can just kind of break it down. I have it broken down where this is the expectations of how to get a credit if you're going to be in the marketing. We expect you to promote through these channels through LinkedIn, through Facebook, through Twitter. And then as far as like if we go back to this parent issue, what's nice about these parent issues is because the child issues are here on the corner. But how do we get those in the corner? So I'm just going to kind of give the thousand foot view of creating a new issue. Okay. And we'll just delete this one. So I'm going to go to the issue queue. There's this create new issue button. And I'm going to open that in a new tab. I'm going to look for that meta issue of Jen. I'm going to copy the link here. And the link is important because as I create an issue, you can see it's another form with fields, pretty self-explanatory. But because this is going to be a child issue of that parent issue, by paste that first issue here, we can see the meta issue. I'm lazy. I just kind of copy and paste this. And I come up here and I'm going to say example issue during DA webinar. Because what we're doing here is we're going to create an issue for folks who ask questions or haven't ever commented in the issue queue before. You folks right here now, we're going to, of course, you know, when we type in front of people, you make mistakes. But we're going to create this issue so folks can like experiment and play around in this issue. And we'll give you credit for it because this is a safe place. This is my issue queue. It's a safe place. So anyway, so I've created this issue and I'm just for the sake of brevity going to be a little bit quick. Category, it's a task. We're going to leave this as active because we're not doing anything now. This priority, you can read more about this on Drupal.org. This is not a code project. We're not in a hurry for anything. No one's going to die if we don't get this issue completed. I normally just leave these at normal. But if you're working in the Drupal Court issue queue, definitely set major bugs to major component. Now remember we filled in those components for the dev quest. We filled in marketing episode and miscellaneous. This is where they show up. So you can see that I put in a little bit different ones for San Francisco Doug. I did speakers, sponsors, miscellaneous, marketing, organizers, and event. So this one's definitely going to be miscellaneous because I wanted to reserve a catchall for kind of random issues. And then here, remember we filled in who our maintainers were? As a maintainer of this project, I can see other maintainers and assign them this issue. Now if you're not a maintainer, you'll just see your name and unassigned. But this is what is valuable with adding your maintainers is I'm going to assign this to Marky just randomly. You know, he'll get a notice in the mail in his email that he was assigned this and he'll be like, what the heck? But this is for example. So with that, if you wanted to, you could add issue tags. Remember issue tags are autocomplete. So let autocomplete do its job and always just select one that's already created because we don't want accessibility spelled wrong 87 times. So just click one that's already created. We're going to just select novice. And then you can scroll down. You can see that if it's not a parent issue, you can have a related issue. You can add files if you have a text file you want to want to want to include. But basically, you just hit save. Now, because this is a child issue of that parent issue, if we go back to that issue again, it now appears in that sidebar. So this is what's really nice about creating these meta tickets is you have sort of a ticketing system within your ticketing system that groups things together for you. You know, so I'm just really clear that I create a meta ticket. And then I create the child tickets. And then as they get worked on, they change status and colors. So it's pretty, pretty straightforward. You know, you might want to play around with some of the wording and things like that. But that's sort of the general concept of creating a community project and giving attributions. And with these child issues, you really define the expectations too. You know, like you can see if I pull up the video, these are the to-dos. So when someone goes in there and says, I did these things, they're going to go through and they're going to define what they did. Because I define them up top too. It doesn't mean that only one person has to do them. It just means that we want like some sort of transparency and accountability in the queue. You think there's something else I should show Rachel? See, ask for permission. This is where I have to get to the microphones again. No, I don't think so. I think that it's worth knowing the different phases of an issue. Say where an issue goes from active, where it goes on to in review needs work, and then eventually fixed. It's worth saying that. And also knowing that after it's fixed and gone green, because we always like green issues, that eventually two weeks after that, it will switch to closed brackets fixed, automatically, just so that people know. So once an issue, oh, go ahead. I would say once an issue is fixed, the only person who can change that status is another maintainer so that people don't keep reopening issues for you, which makes your life easy. And with that, I can actually go through giving an attribution right now because we're not quite done. So I'm cheating a little bit because I usually for this project, I'll give attributions the talks on Friday or on Thursday. So Friday, I'll go and do all the attributions. But I've already done all the marketing for this Thursday talk. So we'll just do it a couple of days early. So if I select the marketing talk, I come down here. And this is me attributing me, but it's the same concept for other people as well. And actually, Markey helped with marketing too. So we'll use Markey too. Here, in the issue, are all the expectations. Let's say your expectations changed halfway through. You can scroll down and you can change the summary at any time, just so you know. Just make a comment before you say that you added some links or whatever to the summary, but feel free. Issue summaries are updatable. But I'm going to go through here and I'm going to say I marketed the event through Slack, Twitter, Facebook, LinkedIn. And sometimes I would give links if I wanted to. And then Markey marketed. And with that, you can add your formatting. I'm going to make it a little nicer for folks. I'm going to mark the issue as fixed because now we're done with it. If it was a different kind of issue, say I wanted someone to review my work, I would click needs review. That's the general process when you go through core. You hit needs review. That changes the color of your listing in the queue. It makes it yellow. It highlights it that it needs review. And then the next step, someone would come in and review your work. They would hit reviewed and tested by the community and they would outline what they did for that review process. For community project, there's a little bit more room for flexibility on these things. But mostly I want to show how to attribute to. So I'm going to move this to fixed. If I had assigned it to myself, I would unassign it at that point. I would make sure all of this stuff is up to date. I am Volkswagen Chick. I work at Canopy Studios. This you can change depending on who you have working. Like if Canopy didn't pay me for my time, I would uncheck this. But they are. So I'm going to select Canopy as my organization. Let's say I was working with the exploratorium and they were paying Canopy's time to work on this project. You can add the organization's name too. So not only the organization you work for, but the client you work for too can get, if they're registered as an organization on can get attributions as well. So that's a pretty neat thing. If you're volunteering your own time, this is for metrics. We want to know who's getting paid for their work and who's not. So this can change. It might be on the weekend where I'm using my own time or a project maybe Canopy doesn't support. I would click my own time. But I am working at Canopy today. And if I scroll down, we have our parent issue. Down here is a maintainer. I have this section that other folks don't have for crediting others. Now, as people make comments, their name will appear in these boxes. Markey hasn't commented on this issue though, but I want to make sure I give them credit. So I'm going to select me because I've worked on this issue. And then I'm also going to let autocomplete be my friend and pick Markey. So now if you notice down here, it added both of us for attributions. So I can pick anybody's name here. I can pick Rachel. She didn't help. So I'm going to delete it. But you can add anybody you want, comma separated. So this is the glory about owning the space and being able to give attributes. Pretty straightforward, but I'm always very transparent about who I'm giving the attributes to. I'm listing Markey and I put I, that kind of thing. And then I go down here and I hit save. And now that I hit save, a couple of things happen. I've credited Markey. So if we go to Markey's page on Drupal.org, if we scroll down here, one of the last issues he was credited on was Drupal.org. So now just with that click of the button and putting his name in there, he gets that attribute. Also, if I go to my parent issue here, we can see that as your issues move statuses, your parent issue reflects that. You know, green is fixed, red is needs work, yellow is needs review. So this is a really good way to just kind of break down your projects like say, you know, you're working on the marketing initiative and you're working on a slide deck for something. You can see clearly what tasks are left and what level of development. Because sometimes reviewing is quicker than writing the thing. So you can kind of gauge how much time you have and what issues you have. So really dialing these projects in makes it really easy for folks to find things to do, find things that they have time to do and just, you know, just makes it really clear and easy. And we're at time. We're getting very close. So I didn't know if there was anything in particular you wanted to bring up towards the end Amy June. No, not necessarily. I just get, I get so passionate about these because it is so much work. Like we think about code a lot and that that is really important. But so are all of those other parts, you know, because, you know, I have speakers come on and speak at SF Doug, or I have speakers that come on and speak at ally talks and we can't pay them, you know, it's just not in our in our cycle, you know, but what can I do to incentivize them? What can I do to what can I do to help incentivize their employer to pay them to come and talk for two hours at SF Doug and because to like, especially when we're when we're on campus, we have people come in who are like, what's Drupal? Well, you know, that's one of the one of the important things about all of these things too is that networking, you know, the more people we meet at the events, the more people we hear talk, the more words we hear, the more concepts we hear, it just yeah, I just love it. I think it's I think to try and sum up what what you were saying is all open source projects are main are mainly successful because there are people involved. Having the most amazing code in the world is entirely irrelevant unless people are interacting with each other, helping each other, trying things out, working together. That's what makes any open source project. And that doesn't happen by magic. It doesn't happen without a lot of effort by people, people organizing local events, people doing all of the different things you've been talking about today. And because that's just as important, if not frankly, my view, more important than the code, then it should be recognized in terms of as actually saying, hey, yes, this person has done this work, they should be recognized for doing it and and have it registered both as time they've spent and time that their organization has given them the ability to spend. So yeah, it's really important that if you're doing these these community pieces of work, yes, absolutely, use the community projects and get people the recognition they deserve. And I feel like it broadens the scope of who feels included as well. Because I know agencies I've worked for in the past haven't sent everyone to DrupalCon because there wasn't something for the HR team or there wasn't something for the marketing team, you know, or they go home early because there's nothing for them to do in Contribution Day. And I really feel when we have more of these community projects, you know, it's just another reason to stay and meet a different different people because every, you know, I just feel like everyone should come to Contra Day, you know, and if we give them that space to do that, you meet so many people. I mean, I know you meet people at DrupalCon, but the Contribution Day is like really unique in who you meet and who you network with, I think, you know. So, but it gives them another reason to send more of the team, which actually leads to more team building because you see more of the team more often, you know. So, because I always feel like, I think when I first started Drupal, I wasn't even in Drupal yet, I was married into Drupal, I would come to an event and I'm like, there's no place for me. But that quickly changed, you know, and then when I started to get into contributions, of course, it changed. But every once in a while, I feel there's people who come in who don't necessarily know where to go. And I'd love to be able to create those spaces. I'm giving this talk again in Drupal Camp Asheville, and I'm going to create the community project for the Drupal Coffee Exchange because the Drupal Coffee Exchange is a networking exchange where we meet people. And it's another one of those like, is it really Drupal? But some of those people I've met, like now I work on SimplyTestMe because I work with Adam, you know what I mean? So it's just one of those like, other, an additional space to bring more people in. You know, the more people we have, the better we feel, just all the energy involved. So, yeah. Wonderful. Well, thank you very much. I think we'll probably have to email you the link to the slides afterwards, but we should have all of your details because you should have registered to come here today. So that should work. But thank you everyone for coming. Thank you, Amy June, for actually a really great presentation that I hope we can record and edit and reuse lots because there was some wonderful bits of information in there. And people seem to enjoy it from what I've been reading. So that was great. Go and tell all your friends, yeah, that they can do this. And if anyone's waiting for permission, you have permission. Go try things out. Okay. Don't wait. Don't wait. Go do it. And yes, we'll try and send you the recording as well. Absolutely. Thank you. Ooh, what's this? There we are. Oh, wonderful. So last I wonder, June, Bikina Frasso, we are a Women Unassociated Training Drupal for Girl and Women. We create websites and applications in Drupal. Let me know more about that. Judith, you did the, was it Judith? Is that the same Judith that was interviewed as part of the Acquia Women in Drupal blog series? I need to find that out. There's a Judith that we connected to do the Acquia Women in Drupal blog series. We should talk more. Please contact me. Find me. Rachel underscore Norfolk. Drupal.org slash you slash Rachel under Norfolk. And I want to find out more about the program that you're running and how we can help. Thank you very much, everyone. And we look forward to seeing you at the next webinar. Thanks, Rachel. I don't know how to stop this. I think it's the leave button.