Ok, so, first of all, this is awesome and you’re awesome for doing it. Regarding the *where*, I would love to see this replace bits of events.apache.org <http://events.apache.org/> but note that there’s more on that site than just the calendar, like the community event pages like https://events.apache.org/events/2026/community-over-code/index.html
There’s also stuff about how to run events - although to be fair that all needs to be updated or rewritten. So a straight swap out of the old site for the new site would lose some stuff. However, I’m very open to rebooting events.apache.org <http://events.apache.org/> once again, and putting that per-event content elsewhere - it’s only the one event on there so far, and has just been used as a working site for the hackathon and other content of that type. Regarding features, as I mentioned in Slack already, having a way for certain people (Conferences, Marketing, and Brand come to mind) be able to create events in any project. The current workflow for project events is that they request approval from the Trademarks@ list, and then that gets added to the Google Calendar, which then populates events.apache.org <http://events.apache.org/>, and we would need a way to do that same workflow with the new site. > On Sep 10, 2026, at 10:07 AM, Daniel Gruno <[email protected]> wrote: > > Hello, fellow comdev folks, > > At the weekly office hours yesterday, Rich brought up his perennial wish for > a foundation-run calendar tool that we could use for our events, both for the > wider foundation as well as the individual projects. > > To that end, we've set up a work-in-progress service to see if we can finally > scratch that itch. > > The source repo is at: https://github.com/apache/comdev-calendar > The demo site is live at: https://home.apache.org/calendar/ > > Do take it for a spin and see what you think. > > # Features > > The calendar is tied to our OAuth portal, granting people access to entries > based on the projects they belong to and the tiers within those, as well as a > personal calendar feature that only that person can see. > > Projects are able to manage (create, edit, remove) events for their own > projects, and PMC members can manage private events, should they have a need > for those. Ditto, ASF members can manage the foundation events and see > private events (this could be board meeting info, members meeting, operations > calls, etc) > > All public events are visible to anyone, no login required. There are > shortlinks[1] and ICS import/export as well as several other bog-standard > features of any modern calendar app. > > The site has an extensive help page, as well as OpenAPI specs for making API > calls. > > Suggested new features, ideas, tweaks, whatever, should be opened as a PR or > issue in the repo. > > > # Location > > The WIP demo runs at https://home.apache.org/calendar/ but this will likely > not be the final address for the calendar site. One suggestion has been to > replace events.apache.org with the calendar, another has been to set up > calendar.apache.org. More ideas, as well as opinions on the existing ones, > are highly encouraged in this thread. > > > # Maintenance and Disaster Recovery Plans > > The demo is currently hosted on our comdev1-ec2-va instance, and the app > itself is designed to be a turn-key application (you download it, run it, job > done), so we can move it anywhere we like. > > We would likely request that infrastructure backs up the calendar database on > a daily basis, and I think we would need one or two linux-savvy people in > comdev to be prepared to help out with basic tasks like restarting the app if > it is down. > > # Timeline > > Assuming there is a general positive vibe about this initiative, the > intention is to trial it for a few weeks, at its current location, while we > iron out any kinks still in there and tweak other things to our liking, and > then move it to a production environment at a new, fixed location. > > > > Let me know what you think about the tool and the general idea of us hosting > an event calendar of our own, as well as any other thoughts that may cross > your mind on this topic, either here in this thread, on slack, or through > issues/PRs in the repo. > > Some generic questions to get you thinking: > > - What is your overall impression of the idea? > - Are there features you'd like added or changed? > - Where do you think we should host this? (address-wise) > - Any social or technical concerns? > > > With regards, > Daniel. > > > > [1] While shortlinks are neat/helpful, I do want to stress that we should not > place much importance on the permanence of these links. Events can come and > go, or be deleted. We don't have any requirements to keep history here. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
