Re: Looking for a PMC member to help with website development
Thanks Pablo and Brian! We're moving into development phase and we'll be ready for some code reviews. Jakub will be tagging you on those! On 2020/11/06 18:08:25, Brian Hulette wrote: > Feel free to triage some reviews to me Pablo :) > For larger questions about dividing up contributions and code architecture > questions (items 2 and 3) - I think dev@ threads or the slack channel would > be a good place to discuss anything that can't happen in a GitHub review. > It's good for such discussions to be public and archived. > > Brian > > On Thu, Nov 5, 2020 at 12:45 PM Pablo Estrada wrote: > > > For code review / changes / merges, committers are all that's necessary, > > and I am happy to help with anything that requires extra PMC privileges > > (also happy to do code reviews). > > > > You can mention me in PRs, and I'm happy to try and triage to other active > > committers. > > Best > > -P. > > > > > > On Thu, Nov 5, 2020 at 12:02 PM Gris Cuevas wrote: > > > >> The reason why I was asking a PMC member was to minimize dependencies in > >> permissions needed for code/reviews, commits, etc. > >> > >> I don't have full visibility to confirm that any committer could help > >> here. If that is the case then we can cast a broader net. > >> > >> Even if I am a committer, I can't help the team since I don't have enough > >> bandwidth nor extensive experience developing websites. > >> > >> On 2020/11/04 17:27:53, Austin Bennett > >> wrote: > >> > And, @Griselda Cuevas -- not meaning to change focus > >> of > >> > thread. It seemed you might have the ability to cast a wider net. > >> But, I > >> > also might be off on the differences in roles/rights/responsibilities. > >> > > >> > On Wed, Nov 4, 2020 at 9:26 AM Austin Bennett < > >> whatwouldausti...@gmail.com> > >> > wrote: > >> > > >> > > To understand differences in PMC vs committer --> would like to > >> understand > >> > > why a committer doesn't suffice for the listed requests (and @Griselda > >> > > Cuevas you are a committer, but it seems you'd > >> > > potentially just want another committer to also review). > >> > > > >> > > It seems the website is less about shifting the direction of the > >> project > >> > > or exposing APIs that we may feel compelled to support long term, > >> which is > >> > > why I naively assume PMC not especially needed (and it does look like > >> this > >> > > is being done with full visibility to PMC at a high level). > >> > > > >> > > > >> > > On Wed, Nov 4, 2020 at 8:35 AM Gris Cuevas wrote: > >> > > > >> > >> Hi folks, > >> > >> > >> > >> We're going to move into development phase for the new website and we > >> > >> need a point of contact in the PMC who could help us with the > >> following: > >> > >> - Review of contribution > >> > >> - Input on implementation questions such as how to divide > >> contributions > >> > >> to make them easier to review/edit > >> > >> - Code architecture questions > >> > >> > >> > >> And other questions that come up from the development, would anyone > >> > >> volunteer to help us with this? > >> > >> > >> > >> Gris > >> > >> > >> > > > >> > > >> > > >
Add your use case to the "Powered By" Page
Hi folks, As part of the Beam Website redesign, we're going to revamp the "Powered By" page, and this is an opportunity for you to add your use case to the list of projects using Apache Beam. If you'd wish to add your project, please add a subtask in jira: BEAM-11225 [1] with the following information: - Company or project name - One sentence description of your company/project - One short paragraph of your use case (150 words max) - Logo to display - (optional) Links to any public presentation, blog or publication If you don't have a Jira account, you can reply to this thread with this information. Thank you! [1] https://issues.apache.org/jira/browse/BEAM-11225
Re: Looking for a PMC member to help with website development
The reason why I was asking a PMC member was to minimize dependencies in permissions needed for code/reviews, commits, etc. I don't have full visibility to confirm that any committer could help here. If that is the case then we can cast a broader net. Even if I am a committer, I can't help the team since I don't have enough bandwidth nor extensive experience developing websites. On 2020/11/04 17:27:53, Austin Bennett wrote: > And, @Griselda Cuevas -- not meaning to change focus of > thread. It seemed you might have the ability to cast a wider net. But, I > also might be off on the differences in roles/rights/responsibilities. > > On Wed, Nov 4, 2020 at 9:26 AM Austin Bennett > wrote: > > > To understand differences in PMC vs committer --> would like to understand > > why a committer doesn't suffice for the listed requests (and @Griselda > > Cuevas you are a committer, but it seems you'd > > potentially just want another committer to also review). > > > > It seems the website is less about shifting the direction of the project > > or exposing APIs that we may feel compelled to support long term, which is > > why I naively assume PMC not especially needed (and it does look like this > > is being done with full visibility to PMC at a high level). > > > > > > On Wed, Nov 4, 2020 at 8:35 AM Gris Cuevas wrote: > > > >> Hi folks, > >> > >> We're going to move into development phase for the new website and we > >> need a point of contact in the PMC who could help us with the following: > >> - Review of contribution > >> - Input on implementation questions such as how to divide contributions > >> to make them easier to review/edit > >> - Code architecture questions > >> > >> And other questions that come up from the development, would anyone > >> volunteer to help us with this? > >> > >> Gris > >> > > >
Looking for a PMC member to help with website development
Hi folks, We're going to move into development phase for the new website and we need a point of contact in the PMC who could help us with the following: - Review of contribution - Input on implementation questions such as how to divide contributions to make them easier to review/edit - Code architecture questions And other questions that come up from the development, would anyone volunteer to help us with this? Gris
Requesting Jira contributor access for Website revamp project team
Hi folks, could someone in the PMC provide "Contributor" roles to the following folks who will be working on the website revamp? Usernames: nam.bui, Milka, AgnieszkaSell, kasiazjc
Re: [Proposal] Website Revamp project
Hi Everyone, We're ready to start work on the revamp of the website, we'll use the PRD shared in this thread previously. Polidea will be the team working on this revamp and we'll be bringing designs and proposals to the community for review as the project progresses. Thank you! Gris On 2020/09/09 18:14:18, Gris Cuevas wrote: > Hi Beam community, > > In a previous thread [1] I mentioned that I was going to work on product > requirements document (PRD) for a project to address some of the requests and > ideas collected by Aizhamal, Rose and David in previous efforts. > > The PRD is ready [2], and I'd like to get your feedback before moving forward > into implementation. Please add you comments by Sunday Septermber 13, 2020. > > We're looking to start work on this project in around 2 weeks. > > Thank you! > Gris > > [1] > https://lists.apache.org/thread.html/r1a4cea1e8b53bef73c49f75df13956024d8d78bc81b36e54ef71f8a9%40%3Cdev.beam.apache.org%3E > > [2] https://s.apache.org/beam-site-revamp >
[Proposal] Website Revamp project
Hi Beam community, In a previous thread [1] I mentioned that I was going to work on product requirements document (PRD) for a project to address some of the requests and ideas collected by Aizhamal, Rose and David in previous efforts. The PRD is ready [2], and I'd like to get your feedback before moving forward into implementation. Please add you comments by Sunday Septermber 13, 2020. We're looking to start work on this project in around 2 weeks. Thank you! Gris [1] https://lists.apache.org/thread.html/r1a4cea1e8b53bef73c49f75df13956024d8d78bc81b36e54ef71f8a9%40%3Cdev.beam.apache.org%3E [2] https://s.apache.org/beam-site-revamp
[Proposal] State of Apache Beam Document
Hi Folks, Hoping to add more transparency and visibility to the efforts of all contributors to Apache Beam, Kenn Knowles (PMC Chair) and I have drafted a State of the Project document [1], which collects an overview of the project's components: (Beam Model, SDKs, Runners, Connectors, etc.) in three timeframes: What's been recently done, What's currently happening and What's happening next. The idea we had is to provide an artifact that give visibility to users and contributors of what's happening in the project. Proposal 1. Adopt this document to present an overview of the project to our community and publish it in our wiki, GitHub project repo and website. 2. Adopt a quarterly updating cadence aligned with the timeframe we send updates to the ASF board If you agree with this proposal, I'd like to move forward with the publication in the afore mentioned channels. [1] https://docs.google.com/document/d/1qvjnpSj_5MXBmhPI70BJYdrUPVXZR9nAFGf6zqNigek/edit?ts=5f21c30a&pli=1#
Re: Welcome Sruthi Sree Kumar - Season of Docs tech writer
Welcome Sruthi! On 2020/08/17 20:56:40, Aizhamal Nurmamat kyzy wrote: > Hi all, > > > Apache Beam was selected as one of the finalists for the Season of Docs > program and we have been assigned 1 technical writer [1]! > > > And it is my pleasure to welcome Sruthi Sree Kumar to the Beam community, > who will be working with us on improving the runner comparison page and > capability matrix [2]. > > > Documentation development opens officially on September 14 and runs through > November 30, until then Sruthi will be getting to know the community and > contribution processes better, and refine the goals of their technical > writing projects directly working with their assigned mentor - Pablo > Estrada. > > Welcome, Sruthi! Really looking forward to working with you! > > > [1] https://developers.google.com/season-of-docs/docs/participants/ > > [2] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs >
Re: Making reporting bugs/feature request easier
Thanks for the input folks, I'm reading your contributions, I will look into proposing a solution summarizing the conversation at the end of the week, so if you have other ideas share them here. Thanks! On 2020/08/04 18:42:15, Alex Amato wrote: > May I suggest we print a URL(and a message) you can use to file bugs at, in > the command line when you run a beam pipeline. (And in any other user > interface we use for beam, some of the runner specific UIs may want to link > to this as well). > > On Tue, Aug 4, 2020 at 9:16 AM Alexey Romanenko > wrote: > > > Great topic, thanks Griselda for raising this question. > > > > I’d prefer to keep Jira as the only one main issue tracker and use other > > suggested ways, like emails, Git issues, web form or dedicated Slack > > channel, as different interfaces designed to simplify a way how users can > > submit an issue. But in any case it will require an attention of Beam > > contributors to properly create Jira issue and send back a link that can be > > followed for updates. > > > > On 31 Jul 2020, at 20:22, Robert Burke wrote: > > > > I do like the idea of the "mwrong way to raise issues point to the correct > > ways. > > > > On Fri, Jul 31, 2020, 10:57 AM Brian Hulette wrote: > > > >> I think I'd prefer continuing to use jira, but GitHub issues are > >> certainly much more discoverable for our users. The Arrow project uses > >> GitHub issues as a way to funnel users to the mailing lists and JIRA. When > >> users go to file an issue they're first given two options [1]: > >> > >> - Ask a question -> Please ask questions at u...@arrow.apache.org > >> - Report an issue -> Please report bugs and request features on JIRA. > >> > >> With accompanying links for each option. The user@ link actually > >> takes you to the new issue page, with a template strongly encouraging you > >> to file a jira or subscribe to the mailing lists. > >> Despite all these barriers people do still file github issues, and they > >> need to be triaged (usually they just receive a comment asking the reporter > >> to file a jira or linking to an existing jira), but the volume isn't that > >> high. > >> > >> Maybe we could consider something like that? > >> > >> Brian > >> > >> [1] https://github.com/apache/arrow/issues/new/choose > >> > >> On Thu, Jul 30, 2020 at 2:45 PM Robert Bradshaw > >> wrote: > >> > >>> On Wed, Jul 29, 2020 at 7:12 PM Kenneth Knowles wrote: > >>> > > On Wed, Jul 29, 2020 at 11:08 AM Robert Bradshaw > wrote: > > > +1 to a simple link that fills in most of the fields in JIRA, though > > this doesn't solve the issue of having to sign up just to submit a bug > > report. Just using the users list isn't a bad idea either--we could > > easily > > create a script that ensures all threads that have a message like "we > > should file a JIRA for this" are followed up with a message like "JIRA > > filed at ...". (That doesn't mean it won't language on the tracker.) > > > > I think it's worth seriously considering just using Github's issue > > tracker, since that's where our users are. Is there anything in we > > actually > > use in JIRA that'd be missing? > > > > Pretty big question. Just noting to start that Apache projects > certainly can and do use GitHub issues. Here is a quick inventory of > things > that are used in a meaningful way: > > - Priorities (with GitHub Issues I think you roll your own with labels) > - Issue types (with GitHub Issues I think you roll your own with > labels) > - Distinct "Triage Needed" state (also labels; anything lacking the > "triaged" label) > - Distinguishing "Open" and "In Progress" (also labels? can use > Projects/Milestones - I forget exactly which - to keep a kanban-ish > status) > > >>> > >>> Yes, basically everything can is done with labels. Whether having one > >>> hammer is good, well, there are pros and cons. > >>> > >>> > - Our new automation: "stale-assigned" and subsequent unassign; > "stale-P2" and subsequent downgrade > > >>> > >>> Github has a very nice ReST API, making things like this very easy. > >>> > >>> > - Fix Version for associating fixes with releases > > >>> > >>> This information is typically intrinsic with when the commits were > >>> applied and the bug closed. It's pretty typical to use milestones for a > >>> release, and then tag "blockers" to it. (IMHO, this is better than having > >>> the default always be the next release, and bumping all open bugs every > >>> release that comes out.) Milestones can be used to track other work as > >>> well. > >>> > >>> > - Affect Version, while not used much, is still helpful to have > - Components, since our repo is really a mini mono repo. Again, labels. > - Kanban boards (milestones/projects maybe kinda) > - Reports (not really same level, but maybe OK?) > >
[Discuss] Beam Jira Dashboards
Hi folks, I recently created a few public Dashboards in Jira, the intention is to bring visibility into reported bugs, feature request, development opportunities and effort distribution. Having visibility into these items can help us make informed decisions to guide things like: roadmap updates, surface known issues to users, and make it easy for new contributors to get started. I'd like to discuss two topics: - How to keep Jira's input fresh to make these Dashboards more useful - How to adopt these dashboards to make decisions for the project. And I'd love feedback on the dashboards themselves: - Are they useful? How could they be more useful? - Suggestion on what other views/filters to use - Ideas to keep improving them Here's the list and description of the Dashboards I made: Backlog [1]: Aims to help make decisions on project roadmap. Pulls tickets opened in the last 26w (6m), and orders them by votes. The view offers: On the side panel: - A pie chart of the distribution of tickets (excluding java and python core*) - A label heat map to help identify biggest opportunities (exc. python and java core*) - Two filter windows to pull tickets related to Spark and Flink runners On main panel: - A summary of the tickets by component and issue type (to identify critical issues pero component) - A filter publishing all issues - A view of ticket statistics by status and issue type (to help us understand effort and opportunity dist.) * I excluded python and java core components because they dwarf other components, so exclusion helps provide better view of other components distribution. Need triage and Stale [2]: Aims to help organize newly opened tickets and keep tickets fresh. This dashboard shows the issues that need triage or have been marked as stale, and have been created in the last 12w (3m). The view offers: On the left panel: - A list of all tickets that need triage or are stale On the right panel: - A heat map of components - A pie chart of issue type - A view of all labels to help with triage Starter Tasks [3]: Aims to help potential contributors identify opportunities to make their first contribution. This view pulls all tickets marked with labels used for starter tickets, for all time. It orders the tickets by votes, priority, date created, and reporter. The view offers: On the side panel: - A pie chart of the distribution of tickets by component - A component heat map On the main panel: - A view of all starter tickets by component and issue type, to help make decisions on urgency/importance - A view by reporter, to help identify who to reach out with clarifying questions - The full list of all available starter issues Links: [1] https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335849 [2] https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335923 [3] https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335926
Re: [ANNOUNCE] New committer: Aizhamal Nurmamat kyzy
Congrats and Welcome Aizhamal!!! Well deserved and very thankful for all you have done for the Beam community :) On 2020/06/29 16:56:04, Kenneth Knowles wrote: > Please join me and the rest of the Beam PMC in welcoming a new committer: > Aizhamal Nurmamat kyzy > > Over the last 15 months or so, Aizhamal has driven many efforts in the Beam > community and contributed to others. Aizhamal started by helping with the > Beam newsletter [1] then continued by contributing to meetup planning [2] > [3] and Beam Summit planning [4]. Aizhamal created Beam's system for > managing social media [5] and contributed many tweets, coordinated the vote > and design of Beam's mascot [6] [7], drove migration of Beam's site to a > more i18n-friendly infrastructure [8], kept on top of Beam's enrollment in > Season of Docs [9], and even organized remote Beam Webinars during the > pandemic [10]. > > In consideration of Aizhamal's contributions, the Beam PMC trusts her with > the responsibilities of a Beam committer [11]. > > Thank you, Aizhamal, for your contributions and looking forward to many > more! > > Kenn, on behalf of the Apache Beam PMC > > [1] > https://lists.apache.org/thread.html/447ae9fdf580ad88522aabc8a0f3703c51acd8885578bb422389a4b0%40%3Cdev.beam.apache.org%3E > [2] > https://lists.apache.org/thread.html/ebeeae53a64dca8bb491e26b8254d247226e6d770e33dbc9428202df%40%3Cdev.beam.apache.org%3E > [3] > https://lists.apache.org/thread.html/rc31d3d57b39e6cf12ea3b6da0e884f198f8cbef9a73f6a50199e0e13%40%3Cdev.beam.apache.org%3E > [4] > https://lists.apache.org/thread.html/99815d5cd047e302b0ef4b918f2f6db091b8edcf430fb62e4eeb1060%40%3Cdev.beam.apache.org%3E > [5] > https://lists.apache.org/thread.html/babceeb52624fd4dd129c259db8ee9017cb68cba069b68fca7480c41%40%3Cdev.beam.apache.org%3E > [6] > https://lists.apache.org/thread.html/60aa4b149136e6aa4643749731f4b5a041ae4952e7b7e57654888bed%40%3Cdev.beam.apache.org%3E > [7] > https://lists.apache.org/thread.html/r872ba2860319cbb5ca20de953c43ed7d750155ca805cfce3b70085b0%40%3Cdev.beam.apache.org%3E > [8] > https://lists.apache.org/thread.html/rfab4cc1411318c3f4667bee051df68f37be11846ada877f3576c41a9%40%3Cdev.beam.apache.org%3E > [9] > https://lists.apache.org/thread.html/r4df2e596751e263a83300818776fbb57cb1e84171c474a9fd016ec10%40%3Cdev.beam.apache.org%3E > [10] > https://lists.apache.org/thread.html/r81b93d700fedf3012b9f02f56b5d693ac4c1aac1568edf9e0767b15f%40%3Cuser.beam.apache.org%3E > [11] > https://beam.apache.org/contribute/become-a-committer/#an-apache-beam-committer >
Website redesign next steps
Hi Beam Community, Aizhamal shared with us a plan to revamp the current Beam Website[1] a few weeks back. This plan was split into three phases: Phase I: Migrate the Apache Beam website content to Docsy, Phase II: Identify the areas of improvement and develop artifacts and Phase III: Designing and implementing solutions. Phase I and II were recently completed, and phase II produced a document in which the community suggested improvements and made request for the new website design [2]. I'll be working on phase III of the redesign, and this is how I plan to do it: 1) Write a Product Requirements Document based on the input provided in [2] 2) I will share with the community for feedback 3) Once the PRD is approved, I'll form a working team to implement the redesign. If you're interested in being part of this team, by either contributing with some of the work (we'll need tech writers, designers, front end developers, etc.) or by sponsoring the team that works on this, please let us know. The target for project completion will be end of September. Thanks everyone! G [1] https://docs.google.com/document/d/1HlRHfmc9MvKkFEf2gfIL3RYVxTmBXQL4sXjAGGOjeiI/edit# [2] https://docs.google.com/document/d/1btXMkQGqYaU9pUjYh0iCNrbXf4pAHe3tBFsLQ_cLYHg/edit
Re: Contributor permission for beam jira tickets
Welcome! On 2020/05/27 09:12:52, Aaron Tillekeratne wrote: > Hi, > > I'm Aaron, I'm a newbie go developer and beam but i'm interested in getting > involved and helping out with the beam go SDK. > > I want to start with just the started tasks and slowly tackle bigger > problems. My jira id is codeBehindMe and i'd be able to assign tasks to > myself as a contributor. > > Cheers, > Aaron > > > -- > Aaron Tillekeratne > Software Engineer / Data Scientist > BEng, GDip (Data Science) >
Re: [VOTE] Accept the Firefly design donation as Beam Mascot - Deadline Mon April 6
+1 On 2020/04/02 17:18:47, Julian Bruno wrote: > Hello Apache Beam Community, > > Please vote on the acceptance of the final design of the Firefly as Beam's > mascot [1]. Please share your input no later than Monday, April 6, at noon > Pacific Time. > > [ ] +1, Accept the donation of the Firefly design as Beam Mascot > > [ ] -1, Decline the donation of the Firefly design as Beam Mascot > > Vote is adopted by at least 3 PMC +1 approval votes, with no PMC -1 > disapproval > > votes. Non-PMC votes are still encouraged. > > PMC voters, please help by indicating your vote as "(binding)" > > The vote and input phase will be open until Monday, April 6, at 12 pm > Pacific Time. > > Thank you very much for your feedback and ideas, > > Julian > > [1] > https://docs.google.com/document/d/1zK8Cm8lwZ3ALVFpD1aY7TLCVNwlyTS3PXxTV2qQCAbk/edit?usp=sharing > > > -- > Julian Bruno // Visual Artist & Graphic Designer > (510) 367-0551 / SF Bay Area, CA > www.instagram.com/julbro.art >
Re: [VOTE] Beam Mascot animal choice: vote for as many as you want
My vote: [X] Beaver [ ] Hedgehog [ ] Lemur [X] Owl [ ] Salmon [ ] Trout [ ] Robot dinosaur [X] Firefly [ ] Cuttlefish [X] Dumbo Octopus [ ] Angler fish
Re: [Discuss] Beam mascot
Hi everyone, so exciting to see this convo taking off! I loved Alex's firefly! -- it can have so many cool variations, and as a stuffed animal is very original. Other ideas I had are a caterpillar because it looks like a data pipeline, lol or the beaver! Feedback on the current sketches. - They resemble a lot either the Octocat or Totoro [1] - I'd like to see something that is completely new and original, pancakes from gRPC is an example[2] - Something more caricaturesque is better, since we can dress it up and modify it To move forward, it seems that the animals that were winners in this thread are: Beaver (3) Firefly (3) Lemur or votes on sketches (3) Cuttlefish (2) Hedgehog (1) Salmon (1) So let's focus the design proposals on the three winners: beaver, firefly and lemur. I'd like to see more options on beavers and fireflies, the current sketch options I think are based on the cuttlefish and the lemur (?) I think it's a good idea to get sketches from multiple designers, since like someone else pointed out, we'll get variations based on their personal styles, and someone else mentioned here that we have teams/companies with designers in their teams, so let's take advantage of that as well :) I'd suggest to fork the conversation into a call for sketched and we vote on that. [1] https://www.google.com/search?q=totoro&sxsrf=ACYBGNTFW6vq76cHp05g4vBaR-SVJNI1iw:1573674471669&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiTwICf-uflAhUKHqwKHVtzAykQ_AUIEigB&biw=1440&bih=735 [2] https://www.google.com/search?q=pancakes+grpc&tbm=isch&ved=2ahUKEwixgqjV-uflAhUBOawKHX2pAfsQ2-cCegQIABAA&oq=pancakes+grpc&gs_l=img.3...13774.22674..22826...10.0..0.112.1818.13j6..01..gws-wiz-img.10..35i39j0j0i67j35i362i39j0i10j0i5i30j0i8i30.hNtaBfSYNv8&ei=WV7MXfHxIYHysAX90obYDw&bih=735&biw=1440
Re: [Proposal] Requesting PMC approval to start planning for Beam Summits 2019
On 2019/01/19 16:58:52, Davor Bonaci wrote: > I'd say these matters are generally private between the organizer(s) and > the PMC. This thread should continue on the PMC-private mailing list. Last time we checked (back in October), people who are not part of the PMC couldn't send emails to the private mailing list nor read the responses. The organization of the last London Summit occurred in the private list with me and Matthias directly cc'ed in our individual emails. Additionally a few of the other organizers didn't get visibility on how decisions were formed and this obstructed the planning. I'd suggest we continue with the initial discussion here in order to offer transparency, if a sensitive matter needs to be discussed, we can call it out here and set context that a specific conversation will be moved to private, bringing the decision made back to this thread. Also, I'd recommend we keep the discussion focused on the main matter: Summit planning. If you have a proposal to revise what communications need to be had in specific channels, you can start the conversation in a new separate thread, I see a lot of value in having it. @PMC members, we'd love to get an outline of what needs to be done to continue with the planning. We have a few people interested in helping out and we'd love to keep the momentum going. > > On Fri, Jan 18, 2019 at 4:06 PM Ahmet Altay wrote: > > > Thank you Joana. > > > > Kenn and PMC members could you comment on what needs to be done to move > > this forward? > > > > On Thu, Jan 17, 2019 at 3:40 PM joanafil...@google.com < > > joanafil...@google.com> wrote: > > > >> Dear Project Management Committee, > >> > >> > >> The Beam Summits are community events funded by a Sponsoring Committee > >> and organized by an Organizing Committee. I’d like to get the following > >> approvals: > >> > >> To organize and host the Summits under the name of Beam Summit > >> , i.e. Beam Summit North America 2019, Beam Summit Europe 2019 and > >> Beam Summit Asia 2019. > >> > >> To form organizing committees for each edition > >> > >> Approval to host each edition on the following dates and locations: > >> > >> - Beam Summit North America, on April 3rd, San Francisco, CA. (150 > >> attendees) > >> > >> - Beam Summit Europe, on June 19th, Berlin, Germany. (150 attendees) > >> > >> - Beam Summit Asia, October (exact date tbc), Tokyo, Japan. (150 > >> attendees) > >> > >> The events will provide educational content selected by the Organizing > >> Committee, and will be a not-for-profit event, however, we might charge a > >> fee to support the organization and logistics costs. This matter will be > >> decided by the Organizing Committee and will be brought back to the PMC if > >> needed. The events will be advertised on various channels, including the > >> Apache Beam’s and Summit sponsor’s social media accounts. > >> > >> > >> The Organizing Committee will acknowledge the Apache Software > >> Foundation's ownership of the Apache Beam trademark and will add > >> attribution required by the foundation’s policy on all marketing channels. > >> The Apache Beam branding will be used in accordance with the foundation’s > >> trademark and events policies specifically as outlined in Third Party Event > >> Branding Policy. The Organizing Committee does not request the ASF to > >> become a Community Partner of the event. > >> > >> > >> Please feel free to request further information if needed. > >> > >> > >> Kind Regards, > >> > >> Joana Carrasqueira > >> > > >
