Organizing GRASS Contributor Events

Group photo at the GRASS Developer Summit Raleigh 2025

This guide is for anyone planning in-person GRASS contributor events. These events are crucial catalyst for the project development, and organizing them is a great way of contributing to the project. You can go big or small based on your resources and preferences.

University space at CTU FCE Atelier D and work-friendly Pracovna Café during meetup in 2016 during the ISPRS conference in Prague

GRASS group during the FOSS4G 2022 Community Sprint

Name

GRASS community events happen under various names such as code sprints, developer summits, contributor meetings, or community meetings with location and year typically attached to it and GRASS appearing in the name. The name you choose can help communicate the event’s focus, attract the right participants, and align with funding opportunities or co-located events. After you decide the name, be consistent in using it for the event.

When naming and framing your event, consider:

• Who you want to attend (core contributors, newcomers, power users, local students)
• The primary activity (coding, docs, outreach, roadmap planning, onboarding)
• Potential partners or co-located events (e.g., OSGeo, universities, conferences)
• Alignment with funders' expectations (technical sprint vs. user outreach)

Purpose

These events are primarily intended to support and accelerate contributions to the GRASS project, but they can also include elements of outreach, collaboration, and learning.

• Primary focus is contributing to GRASS project:
  • Coding (core, GUI, modules, CI, packaging)
  • Documentation and training materials
  • Testing, bug triage, release planning
  • Outreach and community growth
• Optionally an event may engage users and the public:
  • Introductory workshops or demonstrations
  • Open discussion sessions or lightning talks
  • Local user meetups or themed sessions

Format

3-people event in Solany, 2014

This section describes the overall setup and framing of the event. Choose the format that best fits your goals, audience, and resources.

By context, formats may include:

• standalone: A self-organized GRASS-focused meeting, typically small, flexible, and often self-funded.
• co-located: Held immediately before or after a larger conference (e.g., FOSS4G, ISPRS) to share travel costs and increase exposure. May reduce how long participants can stay at the main event.
• combined event: Overlapping, or partially overlapping with another event (e.g., OSGeo Code Sprint or FOSS4G Code Sprint). For a fully overlapping event, you can just organize the contributing activities related to GRASS project.
• distributed: Parallel meetups at multiple locations, possibly coordinated via messaging or video calls.
• hybrid: Primarily in-person with optional virtual participation. (Note: fully virtual events should follow a different guide.)

By duration:

• one-day: Short meetups for introductions, discussions, or quick work sessions.
• multi-day: Typical for in-depth collaboration, including sustained development and planning.
• recurring: Events held in a series (e.g., weekly meetups, seasonal sprints).

By audience and purpose:

• contributors only: Focus on development, testing, documentation, and roadmap planning.
• contributors + internal showcases: Include informal talks or demos among participants.
• mixed audience: Public-facing activities like demos, workshops, or lightning talks to engage potential users and the broader community.

Structure

This section outlines how to organize the time and sessions during the event. There is no fixed template. You adapt to your goals, participant experience, and available time.

Common structural elements include:

• unstructured work time: Often most productive for returning contributors or during the later days of a sprint.
• opening session: Introduce participants, review goals, and share logistics or updates from the project.
• feedback sessions: A participant invites all other participants to provide input, suggest priorities, or reflect on progress.
• breakout groups: Focused discussions or collaboration on specific topics (e.g., Python API, GUI, CI setup).
• working groups: Assign participants to small teams to work on predefined topics or problem areas throughout the event. Helps ensure coverage and progress on key issues.
• presentations or demos: Optional short talks to share ongoing work, highlight use cases, or present outcomes. These work especially well for engaging local users or guests.

Include only what’s needed for your group. A light structure with flexible working time often works best for experienced teams, while more structure may benefit newer contributors or public outreach.

Location

Seven local participants joined a meetup in Raleigh in 2016

In-apartment Community Sprint Autumn 2017

• Global:
  • Good travel access for international contributors
  • Broader participation
  • We did both standalone and events co-located with other events

• Local:
  • Low-cost and easy to organize
  • Great for recurring or test events
  • Can be anything from a university room to someone’s backyard
  • We had many successful small, local meetups

Other considerations:

• Availability of suitable spaces
• Proximity to your intended audience (core developers, new contributors, local community)
• Influence of travel, accommodation, and on-site expenses

Timeline

• While some venues can be arranged on short notice, others—especially those at universities or with group accommodations—may require reservations up to a year in advance.
• As a general rule, start planning at least 6 months ahead to allow time for logistics, funding requests, and participant coordination.
• Participants usually need an approximate date and location to commit. You can gauge interest through informal conversations before making a public announcement.
• After the event, allow time for follow-up tasks such as writing reports, sharing outcomes, and facilitating reimbursements (if applicable).

Venue and facilities

Table, chairs, power, and wifi (not on the photo) made participants happy during a Community Sprint which was part of FOSS4G 2014 sprint in Portland

A whiteboard came handly during a 4-person Community Sprint in Prague, 2019

You don’t need much to get started—just tables, chairs, power, and internet. Venue types can be anything from a university lab or co-working space to a tent in someone’s backyard. Rental is often not needed or might we very affordable at universities which may recognize that organizing such events is part of their mission or already covered through their existing budgets.

• At minimum: A room with tables and outlets, and a stable internet connection
• Nice to have: Quiet workspaces, breakout areas, whiteboards, projectors, secure storage

Clarify to the attendees what is your plan for accomodation (individual accommodation options in the area, college housing, your couch). A single house can serve as both a work location and a primary accommodation option.

Some venues may be limited to small number of participants, e.g., due to limited accommodation options.

Budget and funding

While your options and number of participants will likely increase with money, some events have been organized with zero budget. Participants can cover their own costs or you can get funding for travel support (you can focus only one main or only on new contributors). Opt-in reimbursements may help to communicate a limited budget, while promised support may enable specific participants to come. Other possible expenses include venue, Wi-Fi, swag.

Funding sources: GRASS project funding, OSGeo (you need to apply during OSGeo budget planning phase for greater expenses), national organizations, local institutions, individual or organizational donations

Acknowledge sponsors on the event page and during the event.

Food and logistics

You don’t need to provide food, but providing at least lunch helps to make the day smooth.

• At minimum: Go out together for lunch or facilitate orders
• Nice to have: Provide daily group lunch, snacks, and organize group dinners
• Collect dietary restrictions or preferences if offering food. You can ask participants with dietary restrictions or preferences for help with handling that part since they are likely the experts.

Registration

While email may work, we have a good experience with sign-up on wiki (usually, you need to know who is coming and for how long). A form as opposed to a public wiki page may be more acceptable for some if you are collecting t-shirt sizes or dietary restrictions.

Swag

Unified t-shirts and OSGeo banner during a Community Sprint which was part of the FOSS4G Europe 2017 Code Sprint

Not mandatory, but people really appreciate it. Wearable swag creates sense of unity and double-counts as promotion.

Social

A late-afternoon hike during GRASS Community Meeting Prague 2023

Evenings can be planned or spontaneous. Social activities don’t have to mean going to a bar—group hikes, walks, or cooking together work just as well.

Photos

Take photos, ask a specific person to take and collect photos. A shared Google Photos album worked for us most recently.

Make a dedicated effort to take one or more group pictures. Make group photos on the way to lunch. After lunch, people leave to work before others or otherwise disappear.

Online Infrastructure

Recommended:

• Use a wiki page as the central landing and coordination space. While a news post on the website may be a great landing page, a wiki page is great for collecting and sharing information before, during, and after the event.
• For CI, ask a maintainer to adjust settings (e.g., temporarily enable “sprint mode” checks)

Reporting

Usually, individual participants record their activity on the talk page of the wiki page. Consider using GSoC-like format of “what was the state before - what is the state after” for reporting each participants’ contributions.