I generally like the idea of removing the hardcoding to ease the maintainability over a long duration.
I am also in favour of the idea of having some role such as community manager(s) who can regularly perform such tasks, keep the site aware of such events happening and update the devlist/community about the same. One way to avoid the non vendor neutrality problem would be to keep this (future) team/role have one / two members from various stakeholders. Thanks for bringing this up, Michael. Thanks & Regards, Amogh Desai On Fri, Jan 5, 2024 at 5:21 AM Jarek Potiuk <[email protected]> wrote: > I am in. And would even like to see this more "live" over time. > > But.... Maybe a proposal here. > > Looking at things like https://airflow.apache.org/survey/ I - for one > - would be perfectly fine if someone - you and Briana - take more > "stewardship' for those pages > > Maybe that's a good idea that we introduce a role of community > manager(s) - similarly as we have Issue Triage team / Collaborator who > can just manage it and just let the community know about proposed > changes and follow that through without waiting for too much of a > discussion. And possibly describe a bit what such people would do, > Explain that such a role will have to be open for others to join a > team of Community Managers - some really lightweight description. > > Of course that requires trust that no vendor neutrality rules are > broken. You are both from Astronomer - and I think we need to be > rather transparent here and be able to also get others from other > stakeholders to be able to take similar roles - without much of a > hassle and with a clear "it's open to others" approach and trust that > when there is a doubt if sth is still OK - you will raise it. > > If this could be the approach that we generally agree on the devlist > here that we would rather get notified about any significant changes > rather than having devlist discussion, so that we have a chance to > react but it should generally be based on similar approach like > LAZY_CONSENSUS - if no objections, things are fine. > > Of course that would be for some major/structural changes. Small > regular changes would go through a PR process basically where > committers will approve and merge any such changes as usual. > > I think - with the ASF rules and vendor neutrality, having it hashed > out and explained and explaining the way how/when devlist gets > involved that would be - (for me) more than enough to just mostly > trust you and the regular PR review process to do a great job there. > > I am not sure what others think ? > > J. > > On Wed, Jan 3, 2024 at 6:45 AM Michael Robinson > <[email protected]> wrote: > > > > Hello all, > > > > Much of the community content on the landing pages has not been updated > in a long time. > > > > Also, the approach taken to display upcoming meetups relies on > hardcoding, which is hard to maintain. > > > > I’ve opened a PR to address these issues with the landing pages and > would appreciate input and feedback. > > > > For example, which recent videos should be included? Do you agree that > we should move away from hardcoding the upcoming meetups? > > > > Here’s the PR: https://github.com/apache/airflow-site/pull/914 > > > > Thanks, > > Michael > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
