Defining an OpenSSF DevRel/Community Event Strategy

[webchick]

Last week I attended for the first time the most recent OpenSSF DevRel Community Meeting, and there we touched on the personas that OpenSSF is hoping to reach and the resources that have been collected here to help further along this committee's work. Awesome stuff! 😄 This will be great for enabling "bottoms-up" community engagement for folks already in OpenSSF's "orbit," by equipping them with templates and other tools to facilitate submitting CFPs and giving talks at community events around the world. ❤️

Thinking a few steps ahead though, we might also want to think about events from a more strategic, "top-down" POV. There are a LOT of events out there, and some will naturally be more impactful than others to OpenSSF's overall mission. A purely "bottoms-up" motion has a more "opportunistic" play, and therefore tends to be elevate events that are either a) easy to get into, b) where folks are already planning to be anyway, and/or c) where OpenSSF is already a household name.

This issue aims to identify some objective criteria we can use when assessing events to determine which ones to explicitly target. Let's dive in!

(Note: I've been in Community/DevRel spaces my whole career, but I'm relatively new to the OpenSSF community. So I am going to do a lot of guesswork down below. 😄 The aim is just to get us started with a framework to think about things, and something we can refine over time.)

Developing a Prioritization Framework

OpenSSF may well already have a framework for prioritization (if so, we can ignore this, and please link it!), but in absence of an established framework, something that works pretty well as a fall-back is RICE: Reach, Impact, Confidence, Effort.

Let's talk about each of these in turn.

Reach

This factor refers to how many people will be impacted by our efforts. We can think of this factor in a few different ways:

• Number of attendees (an event with 10,000 people has more "Reach" than an event with 100 people.)
• Size of developer ecosystem (the JavaScript community is much bigger than the Rust community, for example.)
• Size of open source project ecosystem (WordPress has more reach than Drupal.)
• Geographic location (there are more people in Bangalore than there are in Minneapolis)
• (more ideas here)

Impact

This one is a bit squishy, but digging around on both our charter and personas it seems like here we want to target:

• Events around one or more Critical Open Source Projects
• Events with key open source project leads and maintainers in attendance
• Events around developer ecosystems most likely to introduce new security vulnerabilities. ;) (e.g. some of the biggest perpetrators of the OWASP Top 10 for example?)
• (other "impact" criteria here!)

Confidence

Generally speaking, the more well-respected (and well-attended) an event, the tougher it's going to be to get a CFP accepted for it, and the less the tactic of submitting the same standard talk abstracts will work, as there's an expectation that CFP submitters will cater their talk to the conference's target audience.

Just to name one example, PyCon US has several pages of guidelines they want people to review prior to submitting, and even a whole entire mentorship program to give folks guidance on how to submit a CFP. They take their conference program very, very seriously.

So for our "Confidence" score, we may want to evaluate criteria such as:

• Have other security-oriented talks been accepted in the past?
• Does anyone at the OpenSSF already have an "in" there? (e.g. they spoke at the event before, they are a household name in that community, etc.)
• Have technical leadership in that community demonstrated an interest in OpenSSF before? (for example, attended a town hall, hang out on Slack channels, etc.)
• (other criteria here)

Effort

How much work is this going to be to actually do if we get accepted? Criteria here could include:

• Travel budget is required (vs. we have someone already on the ground in that location or planning to attend)
• It's in a (human) language we do not yet have enablement materials for
• (other criteria here)

Non-Negotiables

This came up in the discussion at the meeting, but you might also want to have a hard line where you say a firm "no" to having OpenSSF presence at an event. For example:

• The event does not have an enforceable Code of Conduct
• The event is in a geographic location known to be hostile to under-represented groups
• One of the event organizers has been involved in a major controversy
• (other criteria here)

(optional) Calculating a "score" for each event

If you want math, rather than people, to say "yes" or "no" to things, you can go fl Six Sigma and do a whole Prioritization Matrix to bubble up to the top which events have the largest "RICE" score. (Reach * Impact * Confidence) / Effort)

But step one is agreeing on what criteria make an event "strategic."

Thoughts?

[edodusi]

Great work @webchick ❤️
I agree with all of this, and I think we should expand this and turn it into a MD document to be included in this repo.

This goes into "how should we structure the repo?", should be part of a "guidelines" section or something similar and be linked and checked every time this group needs to make a decision.

[edodusi]

This is the issue I mentioned #3
@webchick can you open a PR on this, creating a document into guidelines folder so we can discuss there and merge it when we are satisfied with an initial version?

[Cheukting]

I agree with @edodusi Thank you @webchick these information is very helpful :-)

[webchick]

Sounds good! I'll post back when I have a draft PR ready for review. :)

In the meantime, if folks want to chime in with thoughts on which factors to be considering when trying to create a "shortlist" of developer-oriented events to target, would love to hear from you!

[mlieberman85]

This is awesome! I think one other thing I might include in the criteria is particularly around the open source focus of the event. There's a whole spectrum of events from 100% open source, 0 vendors, to events that accept open source talks but are significantly more focused on vendors, e.g. RSA.

[webchick]

Spun off #27 into its own separate discussion as that doesn't need to hold up the rest.

(My approach is generally to discuss, reach some amount of agreement/consensus, then PR, but if it's better to submit that one as a PR as well, let me know, and I can do it that way instead.)

[webchick]

Relevant to our interests: https://github.com/ossf/wg-securing-critical-projects/tree/main/Initiatives/Identifying-Critical-Projects/Version-1.1 here's the backstory / evaluation criteria used to develop the list of "critical" projects.

[webchick]

Another thing to think about in the context of this event strategy is guidelines for various levels of participation in others' third-party events.

For example, an idea that came up in this week's meeting from @edodusi was "OpenSSF Community Days" (akin to Kubernetes Community Days). It'd be great to think a bit about what types of events these would make sense for and who we'd want to target with what kind of content.

(As an aside, we may want to think about calling these something more general than "OpenSSF Community Days," oriented more around what participants can expect to get out of coming, in order to attract folks with no prior knowledge of OpenSSF.)