Thank you for starting this conversation, Russell! And thank you to everyone else chiming in on this topic. Enabling more meetups globally is something I'd love to help steward. It's great to see the amount of interest here on the devlist and also in the various #meetup-(location) channels on Slack.
I agree that we should clarify the expectations and requirements for hosting meetups and publicize them for everyone in the community. Adding these to a centralized location, such as the Community section of the website, is a great idea. I really like what Danica listed, these are important for the meetups to be transparent, community-focused and vendor-neutral. For some historical context, a few of us have been working with the PMC and other community members to organize meetups in different locations since May 2024. We have helped organize meetups in Seattle, SF/Bay Area, Japan, Singapore, and parts of Europe; with more locations planned for this year. The proper usage of the project's mark has been our priority since day 1. We've got permission from the VP of Brand Management to use the mark for "Apache Iceberg Community Meetups @ (location)" and have been working with the local organizers to ensure its compliance. We also work with the organizers to ensure that events are vendor-neutral and community-focused. Here's the previous devlist discussion thread I've raised to formalize some of the community meetup guidelines, https://lists.apache.org/thread/79l173jq32wjrkof732qf23cckhtrvmo Happy to continue the conversation in this thread. In addition to hosting local meetups, we also help distribute the talks on Youtube so the broader community can benefit from the content. This is done through the @IcebergMeetup Youtube channel ( https://www.youtube.com/@IcebergMeetup). Here's the previous devlist thread on this topic, https://lists.apache.org/thread/0rpj3w0bj9ny0phvmkh00cys1grxf11y In general, I would love to encourage more community members to feel empowered to create these localized meetups. It would be great to lower the barriers of entry by helping to clarify some of the requirements and expectations. As always, happy to be a resource here. :) Looking forward to hearing more on this topic! Best, Kevin Liu On Thu, May 29, 2025 at 1:02 PM Ryan Blue <rdb...@gmail.com> wrote: > I agree with Russell here. The goal is to clarify how to run a meetup that > meets our requirements, rather than approving them individually. I like > Max's addition to make anyone starting one aware of the brand guidelines. > > I also like Danica's suggestions so that we state that we expect meetups > to generally be neutral. > > On Thu, May 29, 2025 at 8:28 AM Russell Spitzer <russell.spit...@gmail.com> > wrote: > >> We definitely should not abdicate our responsibilities to the trade mark, >> I just want to shift away from a pre-clearance model which we have done so >> far. I know I >> always try to help folks out if I see something which I think may be >> inappropriate >> >> >> On Thu, May 29, 2025 at 7:50 AM Rich Bowen <rbo...@apache.org> wrote: >> >>> >>> >>> On 2025/05/23 19:24:28 Russell Spitzer wrote: >>> > Hey Y'all >>> > >>> > Basically I would like to get the PMC out of the meetup approval >>> business >>> ... >>> > Please let me know what you think, >>> >>> (Board hat) >>> >>> A critical role of a PMC is being stewards of the project's >>> brands/marks. So while it's not necessary that the PMC micromanage each >>> individual meetup, it is important that they are *aware* of them, and are >>> doing due dilligence to ensure that those brands are being used >>> appropriately. >>> >>> I don't think that necessarily means that there is an approval vote for >>> each one. That is, indeed, too much micromanagement. But I would encurage >>> project members (whether PMC or not) who attend these events to be aware of >>> the brand policy, and point out to meetup organizers when they're being >>> violated (which I would expect to be very infrequent!). >>> >>> That is to say, +1 in general to your proposal here, with the >>> understanding that the project as a whole owns the project's brands, and >>> should be diligent about ensuring that they are not abused. >>> >>
