On Tue, 23 Sept 2025 at 23:43, sebb <[email protected]> wrote: > > 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.
An alternative for the ASF website would be to add the URL to asfdata.yaml which can generate extra metadata for processing by ezt. > 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]
