Ambassador Program RFC

[jemgillam]

The beginnings of an Ambassador Program document, open to discussion.

I have put this in a folder as I envision more documents added, such as a code of conduct and any other written content which needs to be created to go alongside the program.

[Urigo]

I would also add to that maybe a set of measured and proven requirements to become one?

[erikwrede]

I'd favor not doing that and seeing who applies first. Let's not discourage interesting profiles we don't know about yet. If we see a lot of interest, we can always introduce minimum requirements.

[erikwrede]

To specify that, I'd favor a self-written pitch over a checklist that an individual meets certain criteria. We want creative ambassadors and people that love to represent GraphQL - best to hear their thoughts about why they should be one, instead of why they fit the requirements.

[jemgillam]

I agree with Erik that we should keep it open to begin with. I expect take-up will be slow in the first couple of years, I would also want to reach out to likely candidates. In my work on the conference "Subject Matter Experts" initiative, we made a set of questions to gauge who the applicant was and I think we could ask the same here:

• Briefly describe your familiarity with GraphQL. Consider including any open source projects you work on, any working groups you’ve attended, spec proposals you’ve been involved with, talks you’ve given or books you’ve written

• Do you currently hold any formal leadership roles within the GraphQL ecosystem?

[benjie]

talks you’ve given or books you’ve written

We should include things like YouTube series here, maybe something like:

talks you’ve given or media you've published (books, videos, podcasts, newsletters, tutorials, blogs, etc).

[martinbonnin]

I would push back on that. The drive to publish should be about sharing and educating more than financial. Plus, it's very easy to setup a personnal blog these days!

[erikwrede]

+1

[benjie]

In an ideal world I would agree, but we do need more content on the GraphQL blog...

[jemgillam]

This has come as a suggestion from the Foundation's marketing committee, for when someone's grant proposal doesn't quite fit in their remit (Grants are more for longer engagements and larger pieces of work to be produced I think). It's probably a good idea to keep it to catch these kinds of grant proposals and see if the person wants to become an ambassador instead.

[martinbonnin]

Do we want to specifically include open source contributions here?

[erikwrede]

How about putting that into a separate program, if budget allows? I think the foundation already has one. Building OSS feels like a different budget than building a community - although both are deeply intertwined.

[martinbonnin]

True, there is a grant program already for sponsoring OSS work on specific features/projects so we don't want to canibalize that.

I guess what I meant is more OSS in general. Maybe more about answering questions and working with maintainers on reproducers and evolving the language. Feels like this could be factored in. But it's also very "internally faced" and not very "outside world faced", which is typically the role of an Ambassador. I'm fine leaving it out for clarity.

[jemgillam]

Yes, the Ambassador imitative is about external-facing activities, so contributions to the GraphQL repo / projects itself is out of scope.

However, if we can come up with a succinct way of saying "engaging with open source external to the GraphQL project" then that would be great!

[jemgillam]

Did anyone think of a good phrase for this? Something like "cross project collaboration with external open source projects"

[martinbonnin]

Probably something about prolonged inactivity? I wouldn't necessarily put too much process there and leave it at the discretion of the "pastors" (or however we decide to call the group that is going to supervise the program)

[jemgillam]

The problem is you need a concrete process before ever having to use it. In running events and community spaces before, I've found it much easier to say "what does the code of conduct say?" instead of thinking on my feet. Having a process in place also means you are less likely to be accused of unfairness if an incident does happen. However, we also have the backstop of the legal team at Linux Foundation to help us here.

[martinbonnin]

Agreed but we don't want to make it too administrative as well. I would try to word it as generally as possible: "we expect you to do X contributions/year" (contributions probably being voluntarily open as some will be bigger blog post authors, others conference talks, others YT videos, etc...).

The dress code analogy works well. We want to give guidance but still leave some room for improvisation/creativity.

[erikwrede]

Lots of thoughts here, but I like the first draft! Thanks @jemgillam for getting this going 😊

[erikwrede]

I'd favor not doing that and seeing who applies first. Let's not discourage interesting profiles we don't know about yet. If we see a lot of interest, we can always introduce minimum requirements.

[erikwrede]

Expensing payments as soon as an invoice is available is how we handle it at strawberry. Reimbursement after the appearance leaves risk on the ambassador, for example in case of cancellations due to sickness without reimbursement by the airline.

We should have clear policy on which cancellations still warrant reimbursement, and which don't (for example: the individual decides to go on vacation instead of attending the conference after travel plans have been billed). Edit: Reading this again, my example sounds somewhat extreme 😅 my point was more about making clear distinctions what we find OK and what we don't accept.

[jemgillam]

@erikwrede if you have a policy for Strawberry I would love to give it a read. I really would like to be able to get payments made before the event so our ambassadors don't go out of pocket. However, that is a question for the expenses team at the Foundation.

[erikwrede]

To specify that, I'd favor a self-written pitch over a checklist that an individual meets certain criteria. We want creative ambassadors and people that love to represent GraphQL - best to hear their thoughts about why they should be one, instead of why they fit the requirements.

[erikwrede]

We should agree on a guideline for this. While no hard distinction can be made, we should provide some guidance on what is considered content promoting vendor x and content telling a story about GraphQL, that involves vendor x. Because if we keep things void of vendors, maybe practical use cases and audience relevance are limited.

[jemgillam]

Yes I think it's important to keep the spirit of the program vendor-neutral (as the Foundation itself strives to be), but there is no getting away from the fact that vendors do play a part and the audience actually seeks out how to do something with x software.

[erikwrede]

+1

[erikwrede]

How about putting that into a separate program, if budget allows? I think the foundation already has one. Building OSS feels like a different budget than building a community - although both are deeply intertwined.