Thanks for filing this, @OrlinVasilev!

I'll copy my thoughts from Slack for better permanence (and keeping the discussion all together): ❤️

Daylight Savings Time doing what it does and inadvertently moving the meeting from 6am PT to 5am PT is what caused my attendance to drop off completely (6am is painful, but doable; 5am is just a bit too far). 🙈

There used to be two meetings (as evidenced by vestiges like the banner at the top of https://github.com/goharbor/harbor#readme), and one problem the US meetings suffered with frequently was folks joining hoping to discuss their open contributions with developers on the project, but not having those folks available in that time slot (which is understandable given the time zone difference).

So, I think if we're going to successfully restart those "US timezone" meetings, we need to find a way to resolve that issue first (otherwise it ends up being a meeting of essentially two completely disparate groups, one being at a significant disadvantage). In other words, I think the current situation (with a meeting that's at a time that's only really uncomfortable for US Pacific Time and Australia + NZ at 5am, midnight, and 2am respectively) is a more healthy situation until there are more active developers on the project that are in a US friendly timezone (folks like Vadim are probably close, but still off by a bit for a proper "US timezone" meeting that's still comfortable for him too 😄❤️).

As a newcomer to the project, I'm finding the lack of support in PT daunting. I'd be okay with 24 hour response cycles, but I think there's definitely project culture here that I don't understand. I'd be eager to join a community meeting, at least once to get started, but I'm with @tianon - 5am is more than I can likely manage.

The issue that expertise is locally concentrated, so that even if there were a PT friendly meeting, that group would be largely in the dark, strikes me as a bigger deal.

Again, from the perspective of an outsider, I'm finding it hard to get traction understanding how the project is run. My early experience is that documentation and reality don't align, and neither line up my general experience, which makes getting started really slow going.

Is there a way we can bridge that gap? Maybe it's a matter of finding better ways to communicate asynchronously - currently there's Slack, Github Issues, Discussions, a mailing list... probably other channels? I'm still unclear where to ask questions effectively.

Getting better at async is great, but there is an immediacy and connection to sync meetings, even on Zoom, that is hard to beat. I'd like us to start a North America friendly meeting cadence too - maybe biweekly, maybe monthly, at a time that is not too inconvenient for China. It need not have the whole team - but some representation.

@OrlinVasilev Did something change, or is this WONTFIX?

Hi @nyarly, as that topic staled for quite some time decided to close it.
I'll be super happy to open it again for discussion if someone from the US friendly time zone is willing to lead that meeting as the majority of the maintainers are in China and Europe.

Orlix

Are there any US maintainers at all? I'm not sure how useful it would be to have a Harbor meetings without core members attending.

Here's my motivation, which I think at this point is entirely stymied:

• We would like to use Harbor as an entirely cluster native image hosting solution.
• We use CockroachDB for our databases.
• We'd like to see a CockroachDB compatible version of Harbor, and this is a longstanding issue on the project.
• I was happy to take a swing at this, and started the process of opening a PR
• I encountered the Harbor policy on dependencies (only core team members can update them) - I opened a ticket to update the ORM, which got marked "good first issue" and went stale.
• In the meantime, a WG was created for database compatibility, but with a focus on MySQL and which seems to have gotten hung up on DB migration tools. It meets in China time.

Briefly, I feel like a feature critical to my usage of Harbor might be straightforward to add (AFAICT, it would mean using the released version of the ORM instead of the Harbor "stripped" version, and a little bit of configuration plumbing), and I was willing to do the work, but access to the core team has been a) more necessary than most open source projects (because of the dependency policy) and b) less available, because communication seems to happen in person or in meetings that happen at infeasible times.

Hi @nyarly no US maintainers as of now
are you going to attend KubeCon NA in two weeks we can chat about that there!

Orlix

@nyarly can we get in touch in Slack as well, please

@nyarly are you attending KubeCon we may discuss that there :)

@OrlinVasilev I tried to reach out on Slack - I can't make Kubecon this year