Proposal Guidelines

We invite all community members to submit proposals to the GOOD conference. Whether you're a seasoned presenter or this is your first time submitting, we encourage everyone to contribute to the event. We aim to feature a diverse range of presentation formats, including posters, pre-recorded talks, tutorials, and more, allowing for various styles of engagement and knowledge sharing. We especially encourage first-time speakers to participate and share their voice.

We are currently accepting proposals for talks, tutorials, posters, and birds-of-a-feather (BoF) sessions, but we also have an option to propose your own proposal (“Other”) to share your creative idea for the program. Each of these program elements offers unique opportunities for presenters to engage with the community and share their expertise, insights, or research. The proposal selection process is open, meaning reviewers will see your name and identifying information, while the reviewers' names will also be made public.

Talks are either 25-minute or 10-minute sessions, including time for Q&A. A talk proposal is a concise pitch designed to convince the audience to invest their time (10 or 25 minutes) to learn something valuable.

Tutorials are 90-minute or 3-hour hands-on sessions where instructors lead participants through a focused learning experience. Proposals should clearly outline the session requirements and the materials provided in advance (e.g., GitHub repos, links). The same proposal guidelines apply, but with a specific emphasis on prerequisites and how the session will be structured.

Birds-of-a-feather are 90-minute sessions that provide additional opportunities for community building. These sessions usually include short presentations by a panel and a moderator with the bulk of the time spent opening up the discussion to everyone in attendance. BoF topics can be of general interest or based on the themes and topics of the conference.

Posters allow presenters to visually communicate their work in a more informal setting, fostering discussions with attendees. A poster proposal should succinctly summarize the core idea or research, why it's important, and its key results or insights. Make sure to highlight what makes your poster engaging and how it will encourage interaction and discussion.

Tips on How to Write a Successful Proposal

A strong proposal should address:

• The topic (WHAT) and why it’s important or intriguing.

• The target audience (WHO) the talk is aimed at.

• The style of talk (TYPE)—whether it’s math-heavy, hands-on, light-hearted, informative, etc.

• The takeaway (LEARNING OUTCOME)—what attendees will gain from the talk.

A proposal serves two purposes: 1) convince the Program Committee to accept your proposal, and 2) act as the description of the talk/tutorial on the schedule. If accepted, you will have the opportunity to further edit and clarify the proposal ahead of the schedule’s publication.

There are two parts to a proposal:

1. Abstract: The abstract tells attendees what the talk/tutorial is about. It should answer all of the above questions, but it should remain short and to-the-point. This is your chance to pitch attendees on watching your talk/tutorial. If you are submitting a tutorial proposal, the abstract should also specify the requirements for participating and how materials will be distributed (e.g. Github repo, links, etc). If your materials are already hosted publicly somewhere, you can include the link. 

2. Description: The description expands on the abstract and provides background and additional details about your talk/tutorial. It is often helpful for talk descriptions to include an outline of the talk/tutorial. The Program Committee reads each description carefully to determine if a talk/tutorial is a good fit. This is your chance to pitch the Program Committee on accepting your talk/tutorial. The Program Committee does occasionally ask for more information after proposals have been submitted, but it’s better to include relevant details up front and try to anticipate what questions the Committee will have after reading your proposal. For example, if you think the Committee may think you’re trying to cover too much ground, an outline with time estimates could help alleviate that concern.

Additional Talk/Tutorial Proposal Suggestions

• Who is your target audience? Think about your target audience in terms of job role (data scientist, engineer, researcher, etc.) and experience level. Being clear about who you are speaking to (and the background knowledge you can expect them to have) is helpful both to you as you prepare your presentation, as well as to the audience considering whether your presentation is a good fit for them to attend.

• Clear title: A catchy title can be useful, but don’t overdo it. People should get a rough idea of what your presentation is about just by reading the title. Your proposal and your presentation should be consistent with your title.

• Get feedback: Ask friends and colleagues to review your abstract; bonus points if they are your target audience. Take time to tweak your abstract if needed. Additionally, if you are a first-time speaker, please indicate this in your proposal and we will reach out with more information regarding mentorship opportunities.

Common Pitfalls

Here are some common pitfalls that could lead to the proposal not being understood or rejected by the Program Committee:

• Overly long proposals: Keep it simple and clear. Good proposals typically provide all the important information within 200 words. This is not a strict limit, just a suggestion to help you stay focused.

• Future work: While talking about future work is interesting and could be mentioned in your talk, the core content of the talk should already be shaped, and you should be able to describe it in your proposal. Don’t rely too heavily on future data collection or future prototyping, because things often don’t go as expected.

• Sales pitches: We are a community of creators and users of open-source scientific computing tools. You can reference your closed-source product or platform, but the audience will find the talk more interesting if they can try your techniques with the open source software. Your problem definition, proposed techniques, and business domain are also interesting, but sales pitches are typically rejected.

• Repeated talks: We have a strong preference for new talks, and new speakers. If your talk is already available online, it is unlikely to be accepted for the conference.