There have been several overlapping conversations lately regarding Fedora meetings and events, all of which have generally indicated, “Our technology isn’t ideal / isn’t fully serving our needs.”
I thought I would try to gather (not debate here) the community’s ideas about what the perfect system would do additionally or differently.
What are your complaints and/or daydreams? What effect would that have? Please drop it here, and try your best to turn a blind eye to what others want. The goal is to gather.
Here’s a summary of the convos I’ve seen so far:
IMPROVE:
Make it easier to add regional events (ala Meetups) and discover those.
Make the calendar more visible to the community and friendlier.
Specifically, in Discourse
Make it more adaptable to changes in the project, e.g. remove old calendars and/or switch to a tag-based system.
The current Fedocal theme looks very dated and is off-putting to newcomers.
FIX:
The iCal feeds seem to be unusable in recent versions of Thunderbird
KEEP:
Fedora Messaging integration
Respect the user’s time zone settings from FAS
The ability to obtain a live feed for an entire calendar (not just individual events)
Is the calendar plugin of Discourse matured enough to replace Fedocal, @gwmngilfen? And should we do that @kevin? I don’t think Fedocal’s code is in a state where it is worth adding enhancements too without making major changes to its foundations.
P.S. Of course, I belong to the “do not fix it if it is not broken” camp now, but I am all for innovation (and helping it happen, for that matter).
I think the short answer is “no, it isn’t” but that’s because of 2 specific items:
you cannot subscribe to the whole calendar, only to events on it.
The event recurrance model can be a bit limited sometimes.
2 isn’t that big a deal most of the time (it only bites really when you want “2nd-last Thursday of the month” or something.
1 is worse, although I could argue that many don’t want to see every event that might be Fedora-related worldwide. I’d be quute happy to (a) add the ICS for events I want to be in, and (b) follow the forum to catch new events that may be relevant. This works better if events are in one category, of course, but judicious use of tags probably works too.
So either these flaws aren’t too bad, and we can use it now, or they are - but in that case, I might wonder if fixing the plugin is easier than fixing Fedocal…?
Also, as @josephpointed out, it looks like the plugin (in part at least) is already enabled, as we have some in-topic calendars already. That’s not what we’re considering here (the plugin has two functions), but it shows that we have it, and can use it if we want to trial it.
Yeah, when I read the 1st one before your preface, I was almost like “Why would anyone want to do that?”. Like, surely it is in the SIGs’ and subprojects’ best interests to “publish” their event in a way if they want more hands-on deck but I do not necessarily see this as a deal breaker per-se. Discourse does provide us with the medium to do so as I distinctly recall having asked you during your Flock 2025 AMA session on this.
I would preface this by saying that I do not know just how easy (or difficult) it would be to migrate stuff over from Fedocal to the Discourse calendar plugin and as such, I would hate to be seen all hand-wavy on this. But if you’re asking about the Fedocal code - it works just fine at the moment but adding features without major changes would result in both poor development experience and potential breaking risks.
Some bug fixes on the top and keep it rolling for a few more years is how I would want to roll with Fedocal at the moment but given that we have the tools for the move - I wonder if we should do that
Fair, and neither do I - but some might, so I want to note it.
I feel we’ve been round this carousel a couple of times, so I would propose we test the plugin for this usecase and then we can compare them side by side and decide?
I want to understand the higher-level goal behind using the Discourse Calendar plugin.
Is it simply “Make the calendar more visible to the community” as I outlined earlier? Or is there something else it provides that I’m missing?
There are many ways to get a calendar into Discourse. And if I’m understanding correctly, the plug-in as it stands today also isn’t the ideal technology – we would be trading one non-ideal solution for another, and making some people happier while disappointing others. Not to mention, now we would have two non-ideal solutions instead of one.
That’s why my goal in this thread is to understand: what is the ideal solution? (Ideally, before we deploy even more non-ideal solutions.)
Perhaps this is helpful:
Imagine a world where neither Fedocal nor Discourse Calendar existed. How would we describe the tool that we want? What do we want to accomplish with this tool? And how do we picture that happening?
I personally really like the idea of regional events. So I’ll add my own feature requests here:
ADD:
The ability to subscribe / be notified of events by geography. Examples: “Within 200km of Munich”, or “Within 100 miles of Boise”.
The ability to have multiple geographic subscriptions. E.g, both of the above examples because you travel between those locations frequently.
The ability to mark a calendar item as “Help Wanted” or “Tentative” and adjust my subscriptions / notifications accordingly.
Explanation: Some people may be willing to facilitate events within a certain geography. They could opt-in to these “new tentative event” notifications and contact the organizer to join the event team. Others may wish to not be notified until an event is no longer tentative.
@gwmngilfen Fair enough. If you have some time in your bandwidth, let’s do it. Please feel free to let me know where and when I can be of help with that too, if we are trying this on the Fedora Project instance.
@theprogram I would say that it is a little too early for doing that, given that we are unsure just how this “experiment” would turn out to be. I think, it would be useful to post our views there once we have some actionable information from this experience about how the Discourse calendar plugin could be useful in your proposal. I mean, after all - it might turn out to be nothing so I would rather not get the hopes up.
For starters, this implementation can help us either circumvent or resolve the pain points that we have had (and you seem to have listed in the OP) with Fedocal without having to (like I have mentioned before) worry about poor development experience and potential breaking risks. I cannot comment on the visibility aspect of it because I have not yet tested how Discourse calendar plugin brings things to more front and center.
Sounds handwavy. Do you mind listing some of the ways with which we can introduce calendar to Discourse that are supported by the community? Also, please elaborate with examples how this maintained plugin is not ideal for our usecases and what we could use for this in its stead. Atop that, with the proper implementation of calendar in here, we do plan on migrating things over from Fedocal (like I have stated before).
Of course, we are not certain yet about the Discourse calendar plugin to be the ideal solution (like @gwmngilfenhas stated before) and we are more than willing to take it for a spin, record our observations (preferably as an ARC investigation) and then, think about if we want to bring down and replace completely the current deployment of Fedocal which works but has pain with its maintenance and experience.
This is not helpful. In a world where none of these existed, we would have to resort to maintaining yet another service for calendaring, thus adding one more incoherent technology to be maintained in Fedora Infrastructure, atop easily a hundred others that we do. We could use some more volunteers, and we want to make things better but not at the cost of starting from zero, because that seems rather wasteful.
@t0xic0der: We don’t seem to have the same goal in this thread, so let me directly and indirectly address your points by re-stating my assumptions and goal:
If we were to make an exhaustive list of all available calendaring libraries and fully-built solutions, it would number in the hundreds or thousands. Calendaring is not a difficult or unique technology problem, it’s a matter of having an implementation that fits your specific needs perfectly.
In any evaluation, whether Fedocal vs. Discourse Calendar vs. solution number 725 from the list above, we would need to know what we want. Call it a list of checkboxes, or a scoring system.
Even in “knowing what we want”, it’s easy to get lost in the details. Do we want iCal or CalDav? Well, we want “an easy way to subscribe to a calendar”, and realistically either solution will solve that problem. I believe that prematurely diving into the technology specifics is a way to ensure that the selection process never ends.
So my goal for this thread is to surface everyone’s goals at a high-enough level that we can evaluate solutions without getting lost in the technology specifics.
(And yes, the debate of whether to use the Discourse Calendar plugin or not is, to me, clearly a technology-specific debate.)
I’ll +1 @theprogram here - I want this in Discourse because that’s where the users are, and they (well, some of them) are the developers-of-tomorrow. We need to engage with them where they are at. I think Discourse does that, and the (possibly perceived) drawbacks are worth it.
Sadly it requires an admin to help out here, as the required plugin config is on the admin side. Once configured, we can allow others to play with it, of course, it’s just the initial setup that is admin-reserved. Thanks though
Speaking to the wider audience here: I also feel like people are not understanding that there are many ways to get something into Discourse, and that using the less-than-ideal existing plugin is not the only option. We frankly seem to be too hyperfixated on acquiring that one specific non-ideal implementation to think about solving the full problem (or even defining the full problem, which was the point of this thread.)
I think you were asked earlier to expand on this - I’d like to ask for that too. My thinking is that there is:
Native UI implementations (i.e plugins)
Creating event topics via the API
I don’t think there’s anything else? I suspect (but, please correct me) that what you’re thinking of is the latter. That’s OK-ish, but I really want events to be a first-class citizen here, where our users are - and because we’re on a hosting plan for our forum, we cannot install any-old plugin we desire, it has to be supported … which leaves us with the plugin I’m supporting.
So, yes, I agree we can write anything we want - but that comes with development effort and time costs. The plugin I’ve suggested (and is already enabled, just not fully configured) gives us the best experience in Discourse right now. Now, if your premise is that events should exist somewhere else, with a secondary surfacing in Discourse, that’s a different point, and we’ll have to disagree on where the source-of-truth should be.
I’m hearing this as “overruled”. Correct me if I’m wrong about that.
I think it’s entirely possible to A) solve the full problem B) in a way that integrates well with the Fedora ecosystem (e.g. FAS) C) in a not-unreasonable timeline.
If only we could have that conversation.
But it sounds like people are too impatient to consider that, and are willing to alienate community members like myself who depend on Fedocal features not present in the Discourse plugin.
10 lives to save 200? I guess those are odds we will live with.
I’m late to this discussion. But the sentence above worries me. Of course, we need something which is perfectly integrated in our Fedora infrastructure. And the core of it is FAS. Not yet another experiment as with GitLab and its cumbersome integration in Fedora. It took us much too long to fix it and get something which works perfectly again. And not yet another time where we try to adapt to some hoster’s regulations.
I want something which works perfectly in our environment! I can’t understand that Discourse hype, The universal remedy for everything?
The problem is not creating event topics via API, but rather to create, manage, and conduct events. We (unfortunately) don’t have so many events that we need a fully automated API. And the reason for our lack of events is not the lack of an API.
And when we have an event, our biggest problem is not to put it in some calendar, but to put it on our website, share it on our social media channels, etc.
