You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some way of indicating the service method more explicitly. Currently there is a limited capacity checkbox which I am happy about, but I get the impression that it does not always is stated explicitly what is the case.
In my opinion, the best solution would be that the board makes a few options that can always be applied for an activity, records these in the Activity policy and those get explicitly listed
Why is this needed?
There are various service methods in use which are not always explicitly explained. See below for examples
Other information
Examples of implemented policies
first come, first serve
-- the de facto standard
first paid, first served
-- parties/SNiC/events with ticket sales
draw if (full before YYYY-mm-dd hh:ii:ss) else 1
-- which is a generalisation of 'draw on signup close' and 'draw after one hour'
-- used for popular activites/weekends
no capacity limit
-- which technically is a more specific form of first come, first serve
draw with drivers prioritised above passengers -- sometimes used for weekends: a draw is done, if there are not enough drivers in the first X, the first driver after X replaces the last non-driver; that non-driver will get waiting list position 1
draw with skippers prioritised -- sometimes used for specific weekends: see above for how it works
external party policies (e.g. Wervingsdagen)
Then, usually also members > graduates > others is implemented for 1 and sometimes for 3 as well
The text was updated successfully, but these errors were encountered:
What would you like?
Some way of indicating the service method more explicitly. Currently there is a limited capacity checkbox which I am happy about, but I get the impression that it does not always is stated explicitly what is the case.
In my opinion, the best solution would be that the board makes a few options that can always be applied for an activity, records these in the Activity policy and those get explicitly listed
Why is this needed?
There are various service methods in use which are not always explicitly explained. See below for examples
Other information
Examples of implemented policies
-- the de facto standard
-- parties/SNiC/events with ticket sales
-- which is a generalisation of 'draw on signup close' and 'draw after one hour'
-- used for popular activites/weekends
-- which technically is a more specific form of first come, first serve
And then we have the specific cases:
-- typically used for e.g. educational activities for freshmen, the FYC barbecue, certain freshmen bonding activities
-- sometimes used for master bonding activities
-- sometimes used for weekends: a draw is done, if there are not enough drivers in the first X, the first driver after X replaces the last non-driver; that non-driver will get waiting list position 1
-- sometimes used for specific weekends: see above for how it works
Then, usually also
members > graduates > others
is implemented for 1 and sometimes for 3 as wellThe text was updated successfully, but these errors were encountered: