 Hey, everyone. Yeah, so as you may have said, I'm Brian Turner. I'm a software engineer at Uber And I've been a contributor in the Spire project for a little over a year now So let's go ahead and get started So great, you might be interested in making a contribution to Spire for a variety of reasons and Maybe you're just interested in the project and are eager to get your hands dirty and learn more about it and get deep into the code If so, that's great And if you're kind of newer to the project, maybe a good place to start would be to look through the github issues And there's a tag that's applied to some of the issues Which is called community good first issue These are generally kind of the low hanging fruit work that needs to be done in the project You can think of things like test improvements or refactoring or maybe debtmide or documentation updates Those kinds of things that don't require a lot of expertise and anything And any of the code in the project Another scenario is you might be looking to use Spire or maybe you're already deploying Spire and you've identified some issues or Some lack of feature support for specific use case that you have in your organization A great place to start is to look through the github issues and see if anybody has reported this issue in the past And if not, I would highly recommend that you go ahead and create an issue And just in the issue just kind of give a brief summary of what it is that you're facing or You know what kind of issue you've seen that's something that Maintainers the projects actively monitor every week so the maintainers try to get back to Folks who create issues in a pretty short time. So And if you are just certain Unsure about whether Spire works in a certain mode or Whether there's support for a specific kind of environment A good place to start might be in the spiffy slack workspace. There's a dedicated channel Spire which is You know includes people from the community includes the maintainers project and the maintainers pretty actively Watch that channel. So that's a great place to kind of get started as well So let's say you've kind of figured out an issue that you want to run with and actually make a contribution So the best place to start here is to go to this contributing markdown file Which is at the root of the spire repository in github And this contributing doc, I think I'll just go ahead and jump to it Be more useful to just look at it directly um So here is the spire repository in github And if we go down a bit here, there's this contributing dot md. I'll click into that And so a few things you want to kind of look through here. One is just sort of the general contributing and governance Guidelines that are established throughout the spiffy projects Once you kind of review those, this is some prereqs for getting your dev environment set up for spire Um, so you'll have to go through that This describes kind of how you build the project how you run tests how you run um and build docker images Um that you can use to test locally There are also some conventions explained here throughout the project of you know, where code lives So, uh, there's been quite a bit of code that's been added to spire in the past couple years So if you're kind of newer to the code base, this is a good place to start to see How things are laid out so you can find the particular modular subsystem that you're looking to modify or extend Um, and then there's a lot of conventions that are established throughout the project Just naming conventions metric name conventions and how metrics are emitted There's also some logging and error conventions. Just how capitalization of messages and things like that And a little bit of talk about how mocks are used in the project And so this is kind of like the the overall landing page for getting started once you've actually submitted a contribution locally in a commit then you can submit a pull request for that And uh, the pull request will just have a template. I can pull up a pull request. I have opened right now just to show an example So when you push your branch to your remote fork and Generate this pull request, you'll get this template It includes this checklist of does this commit conform to the contributing guidelines? Does it include the proper tests and regression tests? And is any documentation updated that needs to be updated? If this feature does not have any forward-facing documentation, then this could be optional Uh, you'll just want to kind of talk about what is the effected functionality and your change and then an overall description of what the change is And then the maintainers of the project are automatically included in the reviews. Uh, so This is something the maintainers monitor every week and try to give timely feedback on So I think we're running a little bit over time. So I'll go ahead and stop there If you have any questions feel free to send them my way or to the spiffy slack We'd be happy to answer those Thanks