Allowing multiple date choices

[wxcafe]

Something like what Doodle does where you can suggest multiple dates/times for an event, and people can vote on which ones are best for them, would be great!

[lowercasename]

Hi! This is a lovely idea but at the moment it's beyond the scope of Gathio for me - it would require a fair chunk of extra code. But anyone who would like to take a stab at it, make a PR and I'd love to include it!

[dev-nicolaos]

Maybe an easier way to enable this workflow would be to not require a date upon event creation, so the editor can link to a Rallly poll? Once a date was agreed to, the editor could add it to the event.

The only tricky part there would be figuring out a policy for how long the event stays in the database if the editor never adds a date, since (according to the gathio homepage) its currently deleted a week after the event ends.

[lowercasename]

That's quite an elegant idea, and it's nice that it allows Gathio to stay focused on the thing it does well without needing to branch out into new features. I wonder if Rallly would ever incorporate an API...

Two options present themselves re. event deletion:

• We could simply set a time (say 3 months) after which Gathio sends an alert email warning that an event without an event time will be deleted. And if the event doesn't get an event time set after that point, it just gets deleted a month later.
• Events without an event time never get deleted. This is sort of possible already - simply set your event to a time far in the distant future and it never gets deleted!

[dev-nicolaos]

I wonder if Rallly would ever incorporate an API...

Are you referring to a Rallly API that gathio could hit or the other way around? Embedding a rallly poll isn't an option right now, but it'd be super cool.

Two options present themselves re. event deletion:

• We could simply set a time (say 3 months) after which Gathio sends an alert email warning that an event without an event time will be deleted. And if the event doesn't get an event time set after that point, it just gets deleted a month later.

• Events without an event time never get deleted. This is sort of possible already - simply set your event to a time far in the distant future and it never gets deleted!

From a UX perspective I think either approach works. My concern would be around scalability/sustainability. I don't know how much storage/DB spaces an event takes up, but if the service ever got popular enough there might be a point where these "phantom" events could be push up hosting costs if they are never deleted. Probably less of a concern for a self hosted instance, but maybe for the publicly hosted instance since it doesn't have a revenue stream outside of donations.