Deadline for submitting talk proposals has passed.

Technical Talks (20 minutes)
Talks on

• LLVM Infrastructure,Clang and all related sub-projects
• On uses of LLVM in academia or industry
• On new projects using Clang or LLVM

Tutorials (40-50 minutes*)
In depth talks on LLVM infrastructure or other core libraries, tools, etc. Demos encouraged.

Student Technical Talks (15 minutes)
Talks from students using LLVM, Clang, and all sub-projects in research. This is not a competition, but a specific category for student talks.

Quick Technical Talks (10 minutes)
Lightning fast talks about a use or improvement of LLVM and other sub-projects.

Lightning Talks (5 minutes)
Lightning fast talks about a use or improvement of LLVM and other sub-projects, LLVM community, Community.o, etc.

Panels (45 minutes*)
Panels may discuss any topic as long as it’s relevant to LLVM or related sub-projects. Panels can take many forms, but a common format is to begin with short introductions from each panel member, and follow with an interactive dialogue among the panelists and audience members. Panels should consist of 3-4 people (but not more than 5) and have a moderator.

Poster
Present a poster during the assigned poster session during the event.

* Exact times TBD after talks selected and the schedule planned

• Submissions should be sent by August 11 (end of day AoE). 
• Notifications will be sent on August 28.

Speakers must present in person. There is no option for virtual or recorded presentations. 

Free registration for speakers is limited to:

• Technical Talks: 1
• Tutorials: 1
• Student Talks: 1
• Panels: 1
• There is no free or discounted registration for lightning or quick talks.

If your accepted talk is not in one of those categories with free registration, please reach out if you need financial support for registration.

For each proposal you must submit the following:

• Talk title
• Abstract
• Submission type
  • For technical talk submissions, you can indicate if you would give a shorter talk (ie. Lightning or Quick instead of full length Technical Talk)
• Photo and bios for all speakers (required)
• Short abstract for the website/program
• Extended PDF abstract (optional)

Submissions without the required information may not be accepted.

This is a guide to help you submit the best proposal and increase your chances of your proposal being accepted. The LLVM Developers’ Meeting program committee receives more proposals than can be accepted, so please read this guide carefully.

If you have never presented at an LLVM Developers’ Meeting, then do not fear this process. We are actively looking for new speakers who are excited about LLVM and helping grow the community through these educational talks! You do not need to be a long time developer to submit a proposal.

General Guidelines:

• It should be clear from your abstract what your topic is, who your targeted audience is, and what are the takeaways for attendees. The program committee gets a lot of proposals and does not have time to read 10 page papers for each submission.
• Talks about a use of LLVM (etc) should include details about how LLVM is used and not only be about the resulting application.
• Tutorials on “how to use X” in LLVM (or other subproject) are greatly desired and beneficial to many developers. Entry level topics are encouraged as well.
• Talks that have been presented at other technical conferences tend to not get accepted. If you have presented this topic before, make it clear what is new and different in your talk.

Guide to Proposal Fields:

Title: 
This will be displayed on the website, schedule, and signs. Keep it short and catchy to attract attendees to your talks. A couple of examples are “WebAssembly: Here Be Dragons” or “Beyond Sanitizers: guided fuzzing and security hardening”.

Abstract:
Here you can include details about your talk. An outline, demo description, what takeaways will your audience have, etc. 1-2 paragraphs is sufficient usually.

This section will not be published and is intended for the PC to better understand how interesting your talk will be to the audience. For example, if you would prefer not to reveal some conclusions in the published abstract, explaining them here ensures that the PC can take them into account when evaluating your proposal.

Submission:
Optional PDF containing extended details. This is in addition to the abstract. Keep in mind that the program committee does not have time to read 10 page papers for each proposal. 

Authors:
Anyone who is an author of the work or the proposal. We do blind submission, so the program committee will not see this information.

Website Abstract:
1 paragraph. This is displayed on the schedule and website for attendees to consider when selecting talks.

We suggest you proofread and pay attention to grammar.

What type of talk submission is this?
Here you can select the type of talk you are proposing. 

For technical talks, are you open to a shorter length talk?
This applies only to those proposing a technical talk (20 minutes). Often we have space for shorter talks (5 or 10 min), so please indicate if you are open to giving a shorter talk on this topic instead. 

Speaker Name(s), Photo, Bio (up to 5 for panels including the moderator):
This should be only the people giving the talk. Typically this is 1 or 2 people for longer talks, and only 1 for shorter length. This is not shared with the program committee. It is used by the logistics team to populate the speaker page on the event site and get speakers registered. This is required information as it takes longer to add speaker information after the fact. For panels, please determine your panelists and moderator at the time of submission.

Which speaker is your moderator? (PANELS ONLY, all others write N/A)
List the moderator name. The program committee does not see this.

PC conflicts
Check any conflicts with program committee members. These are people that can not be impartial when reviewing your proposal. See HotCRP for the full definition of conflict. 

The submission is complete
You must check this when your proposal is final and ready for review. This allows the program committee to start reviewing proposals as soon as they are completed and not wait until the submission deadline. So please click this when you are ready for review.