Buildup/teardown volunteering signup

[russss]

Our current process for managing buildup and teardown volunteers isn't great, it would be nice to have a better workflow here.

Rough list of requirements:

• Collect planned arrival/departure times and contact details. We need this for safety purposes, and so we have numbers for catering. We currently do this with a Google Sheet but this has got too big, and a publicly-accessible sheet limits the details we can collect.
• Inform volunteers about site safety rules in a relatively structured way, and at least have them acknowledge that they've read them.
• Provide buildup volunteers who've signed up with arrival info, such as who to get in touch with to get a lift from the station, where to park, what they need to do when they get on site, etc.

Glastonbury this year has quite a nice form for this which emails you a QR code which can be exchanged for a buildup wristband. I'm not sure if we want to go quite this far - it would provide some benefits but also require more admin work on site.

We should ideally be doing this through the volunteer system, but I think it would require quite a few new features - I'm not sure if this maps onto shifts especially well, and I think at least initially it should be invite-only and not visible to general volunteers.

It would also be nice to collect volunteering offers in a more structured way but I'm not sure this necessarily fits here.

[SamLR]

We probably want to consider how we'd vet people and make sure orga fill it in too

[thinkl33t]

We probably want to consider how we'd vet people and make sure orga fill it in too

Could we have team links similar to the SSO signup links that team leads can share to their vetted people?

[russss]

I think some kind of secret link is fine, it doesn't have to be too complicated.

[Jonty]

From this year: Everyone volunteering for buildup needs to be attached to a team and approved by the team leads, or attached to a generic "volunteer" team who actually has someone managing those volunteers to make sure they're being given things to do.

The important bit is that putting your name in a form does not guarantee that we're ok with you coming until it's approved, especially if this is a secret link that can be shared around (unless they are single use links).

This doesn't necessarily need to be software, but it does need to be a process.

[SamLR]

From this year: Everyone volunteering for buildup needs to be attached to a team and approved by the team leads, or attached to a generic "volunteer" team who actually has someone managing those volunteers to make sure they're being given things to do.

This feels like a statement aiming to solve a specific problem but I'm not sure what that problem is? Is it that there are volunteers not doing things, that can't find things to do or that aren't associated with a team? (and if it's the latter is that actually a problem?)

[Jonty]

From this year: Everyone volunteering for buildup needs to be attached to a team and approved by the team leads, or attached to a generic "volunteer" team who actually has someone managing those volunteers to make sure they're being given things to do.

This feels like a statement aiming to solve a specific problem but I'm not sure what that problem is? Is it that there are volunteers not doing things, that can't find things to do or that aren't associated with a team? (and if it's the latter is that actually a problem?)

The first two - due to the large number of people on site it can be unclear who is with which team, and if people have turned up as floaters they can often end up sat around with nothing to do as nobody is actively giving them work.

This manifests in two ways: 1) People who just turn up and do nothing (which we do not want because it's demoralising) 2) People who don't have a clear route for how to get work, because they're not on a team

If people are on a team they have a lead who knows who they are, and should be ensuring they are getting things to do. If they're not on a team, we need someone to be managing those people to ensure they are being utilised.

[russss]

I don't really want the scope of this to creep too much, as it's already a fair amount of work, so I'd suggest anything which involves assigning buildup volunteers to teams is a separate issue. (We might be able to do this with the shift system though?)

[idnorton]

Hidden volunteer role per team which requires the TL to approve sign up to might work. Does both jobs in providing each team with a specific signup URL (presumably based on the team/role) whilst giving visibility?

[idnorton]

See also https://github.com/emfcamp/Website/issues/1716

[SamLR]

I've had a chat with Jonty about this and the specific problem that I think is worth solving here is that it's useful to have someone who is in charge/a point of contact for every volunteer.

Work assignment is separate to this

The volunteer system can already be configured to require that someone has approval via a volunteer admin (in this case a TL) before their allowed to sign up for shifts/a role

[SamLR]

As it stands I don't think there's anything in the original spec from @russss that is a major departure from what the volunteer system already does. Although some pieces like arrival/departure may need either work or bending the idea of 'shifts' quite a bit (although as per-discussion with @Jonty else where more explicit shifts may help prevent burn out amongst volunteers anyway)

I think at the moment the major work around this will be in:

• Process
  • Making sure people are approved/rejected in a timely fashion (this will need to be in place months before the event which means volunteer system will need to be live for at least this on a similar scale)
  • Making sure volunteers know they have to do this
  • Any enforcement (which we generally don't like to do so what do we do about folks who turn up and don't work)
  • anything else I'm missing
• Docs
  • Making sure role/expectations are clear at time of sign up (and or that there's a method to contact people after they've signed up to update them)
  • Making sure people are aware of the above processes
• UI
  • Probably some sort of filter to show/hide setup/tear down roles
  • Validation (you can only sign up to 1 type of setup/tear down role)
  • Make sure the list of roles is manageable

[idnorton]

Volunteer signup does have details of planned arrival and departure dates/times.

Do we need to start with a list of roles if we're talking about expectations or is that going to be higher level?

[russss]

It's worth noting that a chunk of this stuff (site safety, possibly additional contact details, etc) will only apply to setup/teardown volunteers, not volunteers during the event. We probably shouldn't allow unapproved volunteers to set arrival/departure dates outside the public opening.

I don't think we should bastardise the concept of shifts, because I suspect it may be useful for us to have actual shifts during setup/teardown in some cases. So maybe we need to attach this to roles instead.

[idnorton]

My assumption would largely be that if you're on setup/teardown, shift starts when you arrive and finishes when you leave so I'm not sure there's much benefit to trying to mash those into this.

[SamLR]

My assumption would largely be that if you're on setup/teardown, shift starts when you arrive and finishes when you leave so I'm not sure there's much benefit to trying to mash those into this.

The argument for having shifts is that having say, 2 shifts (7-17 / 11-21) will relieve pressure on folks who might otherwise feel they have to do 7-21 every day (and hopefully prevent burn out)

I'm also not 100% sure we do ask for arrival/departure dates in volunteering, I can't see it (although it would be trivial to add)

[idnorton]

Yep. And if we're speccing software at this point then it might be worth adding support for shifts but it feels like it might be over complicating.

It definitely used to ask for arrival/departure, but that might have been removed at some point?

[idnorton]

commit c56c3660aefe3182011f08bde0e94f885304ecd2 Author: Robert McWilliam rmcw@allmail.net Date: Sat Mar 26 18:44:35 2022 +0000

Remove planned arrival/departure time for Volunteer since we're not using this system for setup/teardown

Okay, we don't have that support, it was removed for 2022.