> For the complete documentation index, see [llms.txt](https://docs.builtbydao.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.builtbydao.com/guides/community-events.md).

# Community Events

Events give members a way to gather, learn, contribute and build relationships around shared interests and projects. A useful event plan connects the purpose of the day with the practical details people need to take part.

You can participate in different ways: attend a discussion, learn at a workshop or choose a specific shift where help is needed. Start with the commitment that fits your interest and available time.

## Understand the Plan Before Answering

Read the event’s purpose, date, time and location. For an in-person gathering, check the directions and accessibility notes the host has supplied. For an online event, look for its meeting information. Use the available calendar link to bring the event into your own schedule.

Some location details are shared only with the intended participants. Follow the event’s access instructions if a location is initially hidden. If you need more information about the venue or participation requirements, clarify it before making plans to attend.

## Know What Your RSVP Means

The event explains which responses are available. Depending on its capacity and access rules, you may be able to confirm attendance, join a waitlist or ask the host for a place.

| Your response or status    | What to Do Next                                                           |
| -------------------------- | ------------------------------------------------------------------------- |
| You have a confirmed place | Plan around the event details and check for updates.                      |
| You joined a waitlist      | Follow your status; wait for a confirmed place before treating it as one. |
| Your request is waiting    | The host needs to decide it before your place is confirmed.               |
| You can no longer attend   | Change or cancel your response where the event still offers that action.  |

An RSVP helps the host understand expected participation. Check-in records attendance on the day. After you have checked in, your event response is fixed.

## Choose a Shift When You Want a Defined Responsibility

Where the event offers shifts, review their times, responsibilities and available places. A shift lets you commit a particular part of the day, which can make participation easier to fit around other responsibilities.

Sign up for a shift that you can reliably attend. Available places depend on capacity, your event registration and overlapping commitments. A shift may also connect to a project task; the signup result explains when that task has been claimed for you.

If you need to give back a shift, use the available withdrawal action early enough for the host to adapt. Read the result carefully: giving back a shift can leave its linked task assigned to you. Manage any remaining task commitment from the task itself.

## Coordinate with the People Taking Part

Use the event conversation where posting is available to ask relevant questions, clarify arrangements and share useful updates. Keep the event’s actual purpose in view so other participants can find the information they need.

For a project workday, use the linked task for work requirements and evidence, and the event conversation for gathering arrangements. This keeps the contribution connected to the project while giving people a shared place to coordinate the day.

## Check In Using the Event’s Method

Follow the check-in instructions provided for your event. The available method can involve a host’s code, location-based instructions or a host checking participants in. Your check-in state tells you when attendance has been recorded.

Attendance does not itself issue Contribution EQTBLT. Where an approved Contribution EQTBLT policy applies, the resulting EQTBLT follows its authorized settlement process. See [Earning EQTBLT](/guides/earning-eqtblt.md) for how confirmed EQTBLT is recorded.

## Leave Feedback That Makes the Next Event Better

After taking part, use the feedback form when it is available. Explain what helped, what was confusing and what would improve the next gathering. A specific comment about directions, shift timing or the way the activity was organized gives the host something practical to learn from.

The aim is a community that gets better at gathering. Clear commitments help the day happen; feedback helps the next one become easier to join and more useful to the people involved.

## See How the Parts Work Together

In an **illustrative garden workday**, one member takes an early setup shift, another attends the shared activity and a third takes a later shift linked to a project task. Directions help them plan their arrival, event chat clarifies arrangements and check-in records participation. Their feedback gives the host a basis for planning the next workday.

Different amounts of time support the same shared effort. A defined shift or a clear event response gives each member a way to belong to the plan.

{% content-ref url="/pages/xo8oDsBWJ5sWtkvPFr6B" %}
[All Guides](/guides/guides.md)
{% endcontent-ref %}

{% content-ref url="/pages/a70fUSkUcY0wo1Q2OM2L" %}
[Choosing Your Work](/guides/choosing-your-work.md)
{% endcontent-ref %}

{% content-ref url="/pages/OJPuOP9Q2GxbquSdWWCk" %}
[Shared Spaces](/guides/shared-spaces.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.builtbydao.com/guides/community-events.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
