On Tue, 23 Sept 2025 at 22:01, Melissa Logan <[email protected]> wrote: > > Helpful context, thank you both. > > I'll reconnect with Sebb to get more context, as well as Paul who created > the new website, to see if we can find a good solution.
It's not complicated: the site build process uses a script to download up to 20 future events into a JSON file which is stored in the repo. This becomes part of the deployed website, and is read by Javascript to populate the events on various pages. One advantage of using Google Calendar to store the data is that it makes it easy for users to add it to their calendar. For example on the following page there are links to the calendar itself, and one can download all the events as an ICS file which can be imported. https://events.apache.org/event/calendar.html However at present the event data is very limited compared with what is shown on the ASF website. If that could be addressed, there would be no need for a separate datafile. The ASF site also links to webp image files under images/events; if there was a suitable naming convention these could be derived from the calendar data, e.g. using the Google Calendar event id. > On Tue, Sep 23, 2025 at 12:26 PM Mark Thomas <[email protected]> wrote: > > > I'm very flexible about the format / location / technology of what I > > update. I am happy to continue to update something that is roughly the > > same effort as adding an event to a Google calendar. Whether that > > continues to be a Google calendar, becomes a file in a git repo or > > something else, I don't have a strong view. My only concern is the level > > of effort required to add an event. > > > > Mark > > > > > > On 23/09/2025 19:54, Rich Bowen wrote: > > > > > > > > >> On Sep 23, 2025, at 2:39 PM, Melissa Logan <[email protected]> > > wrote: > > >> > > >> This is directed to ComDev members who maintain the events.apache.org > > site. > > >> > > >> ASF Marketing & Publicity is exploring the possibility of migrating > > content > > >> from *events.apache.org <http://events.apache.org>* to the main site > > >> (i.e. *apache.org/events > > >> <http://apache.org/events>*). The current /events page is orphaned, > > >> unlinked, and contains outdated information. > > >> > > >> *Why this change?* Hosting events directly on the main website would > > >> provide a more consistent user experience, strengthen branding, and > > raise > > >> visibility among prospective attendees. With the recent website update, > > >> events are now featured on the homepage, making it even more important > > to > > >> ensure accuracy and consistency. > > >> > > >> Migrating content from events.apache.org would also make it easier to > > keep > > >> the homepage listings current, while avoiding the need to maintain a > > >> separately branded subdomain. > > >> > > >> We recognize that there is an existing approval process for events being > > >> published and would like to better understand how that workflow > > intersects > > >> with this idea. > > >> > > >> To start the discussion: are there historical reasons or practical > > >> considerations that make this change difficult? > > >> > > >> For context, see the thread here [private list]: > > >> https://lists.apache.org/thread/cojbknzr44hcq2yl91dhdjy0q1pmch9r > > > > > > > > > Yes, there are practical considerations. They are, of course, possible > > to overcome, I expect, but they are there. As Sebb mentions in that thread, > > the content of events.a.o is generated dynamically from calendar content > > which is maintained by multiple individuals (primarily Mark Thomas, when > > Trademarks approves an event) and, as such, was split into a separate host > > where that tooling could run. That runs each time the calendar is updated > > and generates the relevant pages. Note that it does *NOT* just directly > > include content from a Google Calendar, since that violates our guidance > > from VP Privacy. > > > > > > That could, of course, be moved/replicated/whatever, but I don’t know > > how to do that. Sebb is our current expert on that front, having created > > the process that site currently uses. > > > > > > Much of the rest of the content of events.a.o can, and probably should, > > go away. In particular, the content about Roadshows is probably no longer > > accurate. > > > > > > — > > > Rich Bowen > > > [email protected] > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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]
