[PROPOSAL] Add recurrence type to the data model

[fahu]

Proposal

Introduce a new field to track the recurrence type (e.g., one-time, recurring, monthly, ...) of a specific event.

Field name: recurrenceType Possible values (initially): oneTime, recurring.

Value definition

oneTime

Refers to events that possess a certain uniqueness due to their location, program, artists, etc.

Example: The punk rock band Wizo is on tour and has a gig on the 22nd of February in Wels, and another one on the 24th of February in Vienna. Although the artists and program remain the same, the locations differ, making each gig a oneTime event.

recurring

Pertains to a series of events where each instance differs only in date.

Example: An event to visit the Linzer Zoo, available daily from November to April, would be classified as a recurring event.

Why?

Identifying the recurrence type of an event would allow users to easily filter out non-unique events (e.g., museum exhibitions, zoo visits, etc.).

I believe most people using an event search platform are primarily interested in unique events that occur on a specific date (e.g., the upcoming weekend).

Existing platforms, such as linztermine.at, do not offer the option to filter by recurrence type. Therefore, implementing this feature could serve as a unique selling point (USP) for Boudicca.

---

I'm not really familiar with the contribution guidelines for new features/proposals, but if you agree I would be happy to offer my support in getting the required changes implemented.

[fahu]

We could even consider making the recurrenceType field mandatory by allowing unknown as possible value.

[dmorawetz]

I think this would also be a valuable feature.

This discussion should also include an intentional decision on whether this field should only serve as a search filter, which basically boils down to the proposed boolean "recurring or not", or include more information, like the iCalendar RECUR field.

Recurrence can mean many things (e.g. every second Friday in a month, or every other week). Extracting those interval rules seems like a hard problem, given that the events currently shown on an event page might include some, that were rescheduled.

On the other hand, it might be valuable information for newcomers at tech meetups, or similar groups.

Probably the simplest and most valuable path forward would be a separate field, or a third value, where collectors can just inject this information. It would be like the location and registration information for Posthof; simply hardcoded by source.

As I am not really involved in this project, I can only speak from an outside view.

[kadhonn]

Hey, thanks for your suggestion!

I also think that this would be a really valuable feature because the recurring events are quite noisy right now.

That said, we in general do not want to make fields mandatory, especially because "not set" and "unknown" means the same thing here.

I would keep the recurrenceType field as simple as possible, maybe a boolean indicating recurring events, or maybe a enum like you suggested. I do not really like the idea of having more complex things in there like "every friday", because that introduces a looot of complexity, in calculating/showing events and even more in collecting events. We could maybe add this information in an additional field which is only for humans to read and not being parsed, simply so people have more information when looking at the event, but I would not focus on that for now.

Now, the question is how we detect recurring events. There are three ways I can think of right now: 1) The simple way would be on the collector side, for example with Stadthalle Wien we have an event and a whole list of dates for that. If those dates are more then for example 5, we mark it as recurring. But this way is probably not possible on some platforms. 2) We could add this logic in the Enricher, which could look at all events of one collection and see if there are some which are identical, except of the date of course. 3) As @dmorawetz mentioned we could keep a hardcoded list of events we know are recurring. That of course would work but means more manual data maintenance, which I would like to avoid as much as possible.

also, for "I'm not really familiar with the contribution guidelines for new features/proposals, but if you agree I would be happy to offer my support in getting the required changes implemented." we do not really have contribution guidelines for now, but we are happy of everyone helping us out :) a good way to get in touch for us for help and or more communication is our discord server: https://discord.gg/xAqjs86d or on github of course :)

[fahu]

Hi @dmorawetz and @kadhonn, thank you for sharing your insights. :)

we in general do not want to make fields mandatory, especially because "not set" and "unknown" means the same thing here. I understand your concern. My initial thought was that making this field mandatory could highlight its importance for new collectors, assuming that the recurrence type would be relatively straightforward to identify for most events.

I would keep the recurrenceType field as simple as possible Fully agree, I think the field should be as simple as possible.

maybe a boolean indicating recurring events, or maybe a enum like you suggested. Initially, I considered a boolean field as well. However, I suggested an enum to allow for more flexibility, should the feature be expanded in the future.

Regarding event detection: I suggest starting with a simple approach on the collector side. This should help to filter out most recurring events (many of them originate from linztermine.at where it's also possible to identify recurring events easily). If this approach does not sufficiently address the issue, we could then consider exploring options #2 and #3 further.

[twatzl]

I like the idea. We have the same thing for Museumsbahnen. Many railways have their season in summer an then they operate multiple days a week. The same route all the time.

However one hard requirement for me is:

• Even if there is a recurring_event field all collectors MUST resolve the recurrence and report a list of events (this is important, as later parts in the workflow should not HAVE to deal with recurrenct, but rather MAY deal with it)

Regarding the additional information. We may add that as yet another field recurrence_type or something like this.

This is a big topic I will also have for Museumsbahnen. As they tend to go crazy with this.

[fahu]

I agree :) In my head this field provides additional context for a specific event, but does not trigger any other action (like creation new events based on a given schedule).

[kadhonn]

but is it really that important? :D i mean, it really is helpful, but i would not say it is that important for now we only have two mandatory fields, name and date, the rest is optional. and it will probably stay this way (at least for now^^)

my only concern with the enum right now is, that we already have 3 states. recurring, onetime, and not set. now our current use case is hiding recurring events so that we reduce noise. for that we would filter out all with the value set to recurring, but leave all with onetime and not set, so those would currently be handled the same. can you think about an example where we would treat them differently?

i am also with @twatzl here, the eventcollector must not deduplicate the eventlist, but should report all events, even if recurring. we only want to add metadata that this event is part of a recurring series.

well, it is not quite so easy with linztermine i think, because the way our collector works is by only collecting all the events in one week, for each week in the next 6 months, and then simply appending them all to each other so if there is a weekly event, each week will only contain it once and there will be no simple way to detect this like in the example you posted. instead we would have to go over each event we collected, compare them and then set the flag. which is basically a generic algorithm already which we could put into the enricher so it works for all eventcollectors out of the box. so i think currently i like this approach the most

[Yolgie]

of course the linz termine collector can be adapted to detect this more easily, but try to change as little as possible per MR to keep them reviewable

[Yolgie]

i could also see a value in having this field be "this is not recurring if the tag does not exist or is explicitly set to false" and "is recurring in some way or other when it's true or any other value is set"

this could cover cases like differentiating between:

• museums that are not really recurring but always open or something like that
• sheduled events that have the same agenda but might differ in actual content like the /dev/lol hacknacht every thursday (maybe with the value recurring)
• cinema or theater shows that are played on multiple days/times (mabye as repeating)

events that i would not consider to be recurring are:

• multiple events of a tour
• multiday events that are handled as multiple one day events i.e. ars electronica festival, pflasterspektakel, ...
• events that count their occurence, but are independant of each other i.e. socrates 2023 & socrates 2024 or technologieplauscherl or CCC

See also the distinction between events and recurring events at the techplauscherl community news: https://technologieplauscherl.at/community-news/

[kadhonn]

hm... i can see the value of this enum, although i am a bit unsure if that is really something someone will actively filter for. but ok, lets use the enum

so, i would suggest following steps to implement this: 1) do a generic implementation in the enricher. this can probably only detect "recurring" or not but would work for all collectors and would be good enough for a simple filter in the frontend 2) then we can extend single collectors to set a more specific value, for example if we now that something is a museum we can set those to "always open" or whatever. and since the enricher should always honor already set values from the collector those would win and we end up with more specific values for events we know and more generic values for all others

does that sound like a good idea?

[kadhonn]

@fahu do you want to implement this feature?

if not i would take this over, because i really want it :D

[fahu]

Unfortunately, I didn't find time yet. If you have time please go ahead ☺️

[kadhonn]

Ok, so we have a first version of this up and running for a bit now :) There is a new checkbox with "Zeige sich wiederholende Veranstaltungen" which is default off and if on it includes recurring events.

And the detection is pretty simple for now: If the same event name in one collection of one collector is detected >=4 times it is marked as recurring.

This kinda works but I think there could be improvements:

1. Currently we mark a lot of Theather performances as recurring, I am not sure if I like this.
2. Should we really per default hide events? Because it is not obvious for users that events are missing.
3. I am not sure if I like the checkbox. Should we maybe use a select instead with "All, Onetime, Recurring" values? There is no way right now to only show recurring events, but maybe noone wants to do this anyway...
4. I don't like the checkbox label. Maybe we need to call it more like "laufende veranstaltungen"?

Have you played around with it? What are your opinions about that?

[kadhonn]

currently things like the street food market are tagged as recurring, which is stupid: https://www.linztermine.at/event/701796