The governing board (GB) has been discussing a policy for invited talks. This has been discussed in this post, and also here. A policy is needed to ensure some level of consistency.
We are posting the proposed policy here for community comments. This will be open for comments till 16th August. Hoping for a good discussion around this.
We highly recommend all event organizers read this and pass on their feedback. Once this policy is passed we’ll expect folks to follow it - so be sure to think how it will impact you if it comes into effect as well !
We’ll engage the community on the thread and address comments. In the August GB meeting we intend to put this policy (with comments folded in) to vote. We intend to follow a similar procedure for subsequent FOSS United policies as well.
EDIT: Here’s how you can contribute to this policy:
- Suggest improvements
- Point out drawbacks
- Request clarifications, or examples. Explain your (hypothetical, real, or past) scenario and discuss.
- Signal approval. This serves as “I agree and I understand will follow the policy”.
- The adopted doc will include credits for everyone who contributed to the discussion
The policy text follows
Introduction
This document defines what “invited talk” means in the context of all FOSS United events. It also lays out the guidelines and procedures to be followed for invited talks.
What is an “Invited Talk”
“Invited talks” are basically pre-selected talks, i.e. talks (or in general sessions) that do not go through a review process for selection.
In all events(meetup, conference, etc at all levels), the event volunteer committees have a level of editorial discretion and power of curation w.r.t the content (talks, workshops etc). Most of the content would go through a review process. However, in some cases the committee basically decides “let’s invite xyz to talk on topic abc as a speaker”. This is based on their existing understanding of xyz’s work and its fit to the event content and objectives. Based on this understanding, an invitation is extended to the potential speaker. If the speaker accepts, it becomes an invited talk. Invited talks thus originate from consensus among the organizers, and do not (and must not) involve a review.
Invitation to (submit a) Talk (proposal) != “Invited Talk”
Invited talk offers must be given selectively, with good understanding of the proposed speaker’s work and credentials. It’s not like “hey xyz looks cool, let’s invite them”. Invited talks are more like “we know xyz has done this good work. this work fits this event, let’s invite them to talk about it”.
Creating a good mix of talks typically needs a proactive event commitee that identifies promising speakers and follows up that by inviting them to submit proposals. In such cases, it is good to include a personalized message saying why an invitation to submit a proposal is being extended. Additionally, the message must not mislead the recipient into thinking that the proposal won’t be reviewed.
Need for Invited Talks
Invited Talks serve various purposes. It is one way to invite speakers who make a good fit to the event, but would otherwise not submit a proposal for various reasons.
“Invited talk” can also be seen as an honour; larger the stage, bigger the honour.
Setting the Bar
FOSS United is expanding all the time in terms of city chapters, student clubs, etc. So it is important to have a set of common guidelines. Simultaneously, we need to account for wide diversity in terms of available expertise and talent that various levels will have access to. Autonomy and devolution are useful. Ideally, guidelines must be flexible without being overbearing and burdensome. More prestigious and higher visibility must ask for commensurately higher quality bars for “invited talks”.
[Proposed] Procedure and Guidelines
For all events, the event committee needs to follow this process for invited talks.
- Proposer of an invited talk (someone in the volunteer group) must come up with a recommendation that outlines the reasons for “inviting X to talk about Y”. Recommendation must include
- who is X
- describe Y adequately
- Show how Y is a good fit to the event agenda. Y must be aligned to FOSS (generically something “open”) or initiatives of FOSS United
- Provide reasons to establish that X is well known for their work on topic Y (e.g. they might have given a talk about Y, have project(s) related to Y, or generally be well known for that topic due to other reasons)
- Event organizing committee (volunteers, etc) will review this proposal, and its pros and cons. To proceed further, there must be unanimous approval of the invited talk (i.e. no dissent inside the committee). If there is dissent, then the invited talk proposal is dropped.
- If this event is something that is being promoted by FOSS United as a “Must Attend” event, then the event committee needs to seek approval for this with some more “centralized group” (I don’t know right now what this should be. Suggestions welcome. The governing board could be a choice in the absence of anything else). A proposal justifying the choice, including the recommendation, must be shared for the approval process. If this is not approved, then the invited talk proposal is dropped. Approval must be solicited at-least 2 weeks in advance.
- If all approvals are through, invite X and discuss with them the possibility of them speaking about Y at the event. If X accepts, great ! Coordinate with X to make it happen and include it in the event agenda. Else the invited talk gets dropped.
- If this event is not tagged as a “must attend” event in the FOSS United platform, and this invited talk is happening, then share info about the proposal and any committee discussions with the “centralized group”
- In all events, “Invited Talks” must be clearly tagged in the event agenda using some qualifiers. Some examples are “Keynote”, “Invited Session”, “Invited Talk”, etc
Recommendation must be entirely written by a human being, without using AI. All rejected proposals must be accompanied by a clear justification. Reviewers of proposals may consider discussing concerns or reservations with the event committee, prior to rejecting any proposals.
Rationale for the guidelines
Guideline 3 is where we try to create some uniformity w.r.t quality bars for the highly visible FOSS United events (tagged and promoted as “Must Attend”). This guideline applies to a small subset of the events, leading to significant autonomy to most of the volunteers. The two week lead time ensures that hurried ‘invite talks’ can’t happen, which is a good thing.
An “invited talk” can become controversial due to various reasons, often out of control of the event organizers themselves. We have seen this happen at various levels, globally and locally. Controversies are unavoidable, and having guidelines will not prevent them (no matter how we try!). The best we can hope for is improving guidelines over time. By having broad guidelines, we ensure that volunteer actions are backed by data, just in case controversy erupts.
Guideline 5 is a regulatory mechanism that keeps a record of what kind of “invited talks” are happening at various levels. These may be reviewed from time to time to improve the process.
Additional whetting for “Invited Talks”
“Invited Talks” aren’t reviewed. That said, the organizing team may take additional steps to ensure that the talk adheres to various event specific needs. This may include discussions about the content and on-stage presentation with the invited speaker.
Recommendation Guidelines
Short, to the point proposals are better than long drawn ones. Authors of recommendations need to keep in mind that reviewers may be from an entirely different background or area of FOSS. Recommendations must be self explanatory, and must not be written thinking that “everyone knows this”. To illustrate, some fictitious proposals are shown below. “bad” proposals have inadequate context, followed by the corrected “good” ones.
Sample 1
Bad Proposal
Let’s invite Greg Kroah-Hartman to speak at our CityFOSS event. He will be in town at the date of the event. We can request him to talk about rust drivers or anything else that catches his fancy.
Good Proposal
Greg Kroah-Hartman (GKH) is a long time developer and maintainer of the stable branch of the Linux kernel (wikipedia page about him) . Looks like he will be in town around the dates of our CityFOSS event. We can request him to talk about the state of rust in the linux kernel, or anything else he wants to talk about. The CityFOSS event will have an interesting mix of talks including various areas. It would be great to have the linux kernel in this mix, and we can’t get anyone better than GKH for this.
Sample 2
Bad Proposal
Let’s invite Arvind sir to talk at our student FOSSClub meetup. He is great with linux. A driver development talk from him would be cool.
Good Proposal
Arvind sir is a faculty at XYZ college, at . He is well known in the student community for his Linux skills. This will be a good thing to include in our next student FOSSClub meet. We can request him to deliver a driver development talk. Students may find this very interesting, and we can expect a good turnout due to this talk.
Note: This wouldn’t need to be reviewed as it’s a student club meet (i.e. it doesn’t carry the “must attend” tag on the platform). Regardless, this illustrates the idea and serves as a good record for this invited talk.
