-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Buildup/teardown volunteering signup #1747
Comments
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? |
I think some kind of secret link is fine, it doesn't have to be too complicated. |
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. |
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:
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. |
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?) |
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? |
See also #1716 |
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 |
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:
|
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? |
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. |
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) |
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? |
Okay, we don't have that support, it was removed for 2022. |
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:
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.
The text was updated successfully, but these errors were encountered: