I'd like to propose and template for events where we would like to represent Fedora. Going to conferences is sort of the go-to thing to do, but aside from setting up a booth and giving out things, what can we do. Going to a conference costs a lot of money depending on who goes
and what the conference is. With a standard event template perhaps we, as the Fedora ambassador community, can quantify the value of participating in events. Here are my thoughts on the template/process:

1) Propose an event:

The proposal should include:
- The event and location
- Cost to attend the event as a vendor or organization, if any
- List of Ambassadors who will attend
- Ambassador in charge of our participation in the event
- Required materials to be sent to the event
- Travel cost estimates for Ambassadors working the event

OK, so this is all pretty standard stuff and we already do it. Here's what I'd like to add:

• One or more Ambassador proposed talks. If the event is a conference with speaker tracks, the Ambassadors working the event should propose one or more talks for Fedora. More on this below.

• One or more measurable goals for Fedora. If this is a developer-focused conference, a goal could be to gain new contributors and match them up with a mentor.

• Talks should direct people interested to the Fedora booth where we can help them get involved where they want to contribute. For large events where the number of new contributors is high, we could hold a workshop session too.

2) Start a git repo of standard talks. A lot of us already have a bank of standard go-to talks when we go to a conference. Why not pool these for all Ambassadors? They should be organized by target audience and skill level so that if we need to propose an intro talk, we know where
to find the standard talks. I bet if we look around our home directories and ask we could probably create a large pool of talks quickly.

That's not to say we would never update the talks. In fact, I imagine every conference would need a refresh of the slide deck. But the point here is we have something to work with already and have 90% of the work done.

3) Create a welcome kit for new contributors. It's almost like a new hire orientation process. We want new contributors to be excited about joining the project, regardless of how they are contributing. Far too much of our contributor documentation is focused on package maintenance. We need to balance that out with the other areas where we need contributors.

Alright, now is the part where lots of people reply to this message and point me to where we already do the above. If that's the case, great! The fact that I didn't know or was able to find it should indicate we need to consolidate and organize our efforts more.