Signups?

[Joshua Kronengold]

Has there been any thought to adapting Konopas to allow it to easily be used for signups?  It seems to me that the primary thing needed would be to have a "signup status" for events, saying how many signup slots they had and how many people were already signed up--which could then feed into a cart model where people would add events into a cart and then check them out (with any details to be worked out on a server; as usual for server stuff this could be a simple interface with an implementation on the for-pay server or an exercise for the con if it was easier to just build their own REST ui).

The only other major thing is that you want to handle priorization of some sort.  The two models I've seen cons use is either the flow control model (where there's a hard limit of how many games a given account can be signed up for at time, which grows over time so more people get their first or 2nd place items), or the "alternates" model where users specify their first place slots and what they want if they don't get into those (but if this model is strictly time-ordered, it frankly is identical to the default "first come, first serve" model).  Another model that seems viable and better for events with many slots per day (the flow control model is mostly used for US larp cons, which typically have 5 major slots across the entire event and only minor use of post-midnight slots, in comparison to, say, 5 day gaming cons with 2 hour default slots and post-midnight slots to 4AM, meaning that there might be more than 28 slots to manage) is a queued system where each member prioritizes their signups numerically, and signups are then resolved at some deadline period after which they can sign up for alternates.  In that setup someone with a better tiebreaker will only beat someone into an event who has a worse tiebreaker -and- doesn't pick a higher priority; it seems like this system would work well for larger events, and again, the only thing needed to support it on the client side would be a cart system and (if the right configuration item is added) a way to order priorities among events.

[Eemeli Aro]

Thought, yes; action, no.

The problem is that the KonOpas codebase is now getting rather old, and effectively working on it would require a paradigm shift or two in its implementation -- essentially, for any sizeable change everything would need to get rewritten from scratch. I've done some occasional work in that direction, but even that is now at a stage where it'd need to get re-re-written for me to enjoy working with it.

So new features are rather strictly on hold. I am now working with the code again for Worldcon 75, so I may get something more fundamental done after the con and its hurries are over -- but not before.

In fact, as a part of the changes I've just made, I dropped the entire comments capability, and may indeed look for more things to drop from the codebase before I really get around to porting it to something like webpack + babel + react + redux.

On 17 July 2017 at 20:12, Joshua Kronengold <mn...@labcats.org> wrote:

Has there been any thought to adapting Konopas to allow it to easily be used for signups?  It seems to me that the primary thing needed would be to have a "signup status" for events, saying how many signup slots they had and how many people were already signed up--which could then feed into a cart model where people would add events into a cart and then check them out (with any details to be worked out on a server; as usual for server stuff this could be a simple interface with an implementation on the for-pay server or an exercise for the con if it was easier to just build their own REST ui).

The only other major thing is that you want to handle priorization of some sort.  The two models I've seen cons use is either the flow control model (where there's a hard limit of how many games a given account can be signed up for at time, which grows over time so more people get their first or 2nd place items), or the "alternates" model where users specify their first place slots and what they want if they don't get into those (but if this model is strictly time-ordered, it frankly is identical to the default "first come, first serve" model).  Another model that seems viable and better for events with many slots per day (the flow control model is mostly used for US larp cons, which typically have 5 major slots across the entire event and only minor use of post-midnight slots, in comparison to, say, 5 day gaming cons with 2 hour default slots and post-midnight slots to 4AM, meaning that there might be more than 28 slots to manage) is a queued system where each member prioritizes their signups numerically, and signups are then resolved at some deadline period after which they can sign up for alternates.  In that setup someone with a better tiebreaker will only beat someone into an event who has a worse tiebreaker -and- doesn't pick a higher priority; it seems like this system would work well for larger events, and again, the only thing needed to support it on the client side would be a cart system and (if the right configuration item is added) a way to order priorities among events.

--
You received this message because you are subscribed to the Google Groups "KonOpas Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to konopas-dev+unsubscribe@googlegroups.com.
To post to this group, send email to konop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.