Skip to content
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

Customize waiting list size #72

Open
danleh opened this issue May 5, 2024 · 3 comments
Open

Customize waiting list size #72

danleh opened this issue May 5, 2024 · 3 comments

Comments

@danleh
Copy link
Contributor

danleh commented May 5, 2024

Since quite some people cancel on short notice, it would be great if one could configure to have, e.g., x% or y people on the waiting list.

@Clemens85
Copy link
Owner

This should already be possible with a workaround:

  • Create some N new participants (you can use the "Fill with example data" menu action from the "..." contexdt menu)
  • After having done that, you can swap those new participants (that may reside in waiting list) with participants in the list that are not in waiting list. Thus you automatically have those real participants in the waiting list and the "dummy" participants in the real list and you can always swap back the real participants and get the "dummy" participants into the waiting list (and you may finally delete them).

May look a little cumbersome, but actually it is quite easy and I know some guys do it that way.
Maybe this is however a task for creating something like a short help / FAQ section or something like that.

@danleh
Copy link
Contributor Author

danleh commented May 8, 2024

Just so I understand correctly, this would mean the generated "example participants" would get assigned into teams/routes as well, right? Ideally, we would just like the waiting list to be longer than the default size (the remainder of division by numMeals * teamSize right now, correct?). That is, even if one could assign more people from the waiting list into teams, we don't want to, to make sure we have enough people to swap in even after the routes have been assigned.

To give an example: Let's say 180 people registered for "Mainz kocht", with team size 2 and 3 meals (minimumParticipantsNeeded is 18; nextParticipantsOffsetSize is 6, according to

). Since 180 cleanly divides by 18 (and 6), we would have an empty waiting list. But we want to have at least ~15 people on the waiting list, since out of experience ~5-10% of participants cancel a couple days before the event.

If I understand correctly, this currently would not be possible with the workaround, right?

@Clemens85
Copy link
Owner

Yes, the example participants would also be assigned into teams. This is however not that big issue as it sounds. You can swap the single teams in such a way that only example participants are assigned into one team each other (this is of course a little bit of work, but supposing that you only have a few of those example participants this should be quite fast).
Depending on what is happening, you can later cancel them out and replace them by real participants (this is the N participants on your waiting list) or just delete them without replacement. This all should be done however before sending the final dinner routes. As soon you have sent the routes and something changes, you will always have some trouble in terms of notifying the affected teams / participants etc., I don't think that a customized waiting list size will be a big help at this point.

I know this is neither ideal nor comfortable, but it should also work. Anyway it is always sort of a hassle dealing with such things, most likely it would be easier if you can just put some participants manually to the waiting list, but in the end I think the complexity still remains.

And another important point from a technical point of view: Technically there currently doesn't exist a construct of a waiting list, this more a type of virtual construct, which is mostly computed on the fly. This has some advantages, but also some disadvantages, one of them is that it would cause some efforts for implementing such a feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants