An AI/ML landing page for Beam is available now

[Aizhamal Nurmamat kyzy]

Hi Beam community!

We are happy to announce the release of new resources for AI/ML workflows
in Apache Beam [1].

A number of community members have been working on a series of
documentation guides and end-to-end examples to showcase various common
patterns to perform ML tasks with Apache Beam.

These patterns include data preprocessing with Dataframes, multi-model
inference, anomaly detection, and others. All of these guides come with
corresponding Jupyter notebooks [2] for users to easily try them out.
Please check them out and let us know if they have been useful.


We’ll continue to expand on this work, building guides for more use cases,
such as very large models (>30GB!), complex streaming inference,
cross-language inference, and more. Stay tuned!

Thanks,

Aizhamal

[1] https://beam.apache.org/documentation/ml/overview/
[2] https://github.com/apache/beam/tree/master/examples/notebooks/beam-ml

Re: [CFP] In-person Beam meetups

[Aizhamal Nurmamat kyzy]

Hi all,

In person Beam meetup is taking place in NYC tomorrow Nov 9. There will be
some good talks and pizza :)

 RSVP here: https://www.meetup.com/aittg-nyc/events/289399458/

On Tue, Oct 25, 2022 at 1:56 PM Aizhamal Nurmamat kyzy 
wrote:

> Hi all,
>
> In-person Beam meetup is taking place in the Bay Area on Nov 2. RSVP here:
> https://www.meetup.com/aittg-sfsv/events/288939880/
>
> We will share the details on NYC and Bangalore meetups soon!
>
>
> On Tue, Oct 11, 2022 at 10:24 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Hey Beam community,
>>
>> We are organizing a few in-person community meetups for Apache Beam and
>> opening up calls for proposals. Please send me directly the topics / ideas
>> you'd like to present at the following dates and locations:
>>
>> November 2, Santa Clara, CA
>> November 10, NYC
>> November 12, Bangalore, India
>>
>> The typical agenda will look as follows:
>> 5:30pm~6pm: check in and food
>> 6:00pm~8pm: 2~3 tech talks
>> 8pm~8:30pm: mingle and close
>>
>> Thanks!
>>
>

Re: [CFP] In-person Beam meetups

[Aizhamal Nurmamat kyzy]

Hi all,

In-person Beam meetup is taking place in the Bay Area on Nov 2. RSVP here:
https://www.meetup.com/aittg-sfsv/events/288939880/

We will share the details on NYC and Bangalore meetups soon!


On Tue, Oct 11, 2022 at 10:24 AM Aizhamal Nurmamat kyzy 
wrote:

> Hey Beam community,
>
> We are organizing a few in-person community meetups for Apache Beam and
> opening up calls for proposals. Please send me directly the topics / ideas
> you'd like to present at the following dates and locations:
>
> November 2, Santa Clara, CA
> November 10, NYC
> November 12, Bangalore, India
>
> The typical agenda will look as follows:
> 5:30pm~6pm: check in and food
> 6:00pm~8pm: 2~3 tech talks
> 8pm~8:30pm: mingle and close
>
> Thanks!
>

FOSDEM 2023 is back as in person event

[Aizhamal Nurmamat kyzy]

Hi Beam community!

FOSDEM 2023  is back as an in person event! I
have heard only great things about the event where thousands of developers
get together to talk all about open source!

Is anyone from the Beam community planning to attend? The event takes place
in Brussels on February 4 & 5, 2023. I believe it is also free to attend
but don't quote me on this.

As an open source project we can also have
- a stand for free https://fosdem.org/2023/news/2022-09-26-stands-cfp/
- a Devroom https://fosdem.org/2023/news/2022-09-29-call_for_devrooms/

Anyone interested?

[CFP] In-person Beam meetups

[Aizhamal Nurmamat kyzy]

Hey Beam community,

We are organizing a few in-person community meetups for Apache Beam and
opening up calls for proposals. Please send me directly the topics / ideas
you'd like to present at the following dates and locations:

November 2, Santa Clara, CA
November 10, NYC
November 12, Bangalore, India

The typical agenda will look as follows:
5:30pm~6pm: check in and food
6:00pm~8pm: 2~3 tech talks
8pm~8:30pm: mingle and close

Thanks!

Re: [ANNOUNCE] New committer: Steven Niemitz

[Aizhamal Nurmamat kyzy]

Congrats, Steve!

On Wed, Jul 20, 2022 at 3:10 AM Jan Lukavský  wrote:

> Congrats Steve!
> On 7/20/22 06:20, Reuven Lax via dev wrote:
>
> Welcome Steve!
>
> On Tue, Jul 19, 2022 at 1:05 PM Connell O'Callaghan via dev <
> dev@beam.apache.org> wrote:
>
>>
>> +++1 Woohoo! Congratulations Steven (and to the BEAM community) on this
>> announcement!!!
>>
>> Thank you Luke for this update
>>
>>
>> On Tue, Jul 19, 2022 at 12:34 PM Robert Burke  wrote:
>>
>>> Woohoo! Welcome and congratulations Steven!
>>>
>>> On Tue, Jul 19, 2022, 12:40 PM Luke Cwik via dev 
>>> wrote:
>>>
 Hi all,

 Please join me and the rest of the Beam PMC in welcoming a new
 committer: Steven Niemitz (sniemitz@)

 Steven started contributing to Beam in 2017 fixing bugs and improving
 logging and usability. Stevens most recent focus has been on performance
 optimizations within the Java SDK.

 Considering the time span and number of contributions, the Beam PMC
 trusts Steven with the responsibilities of a Beam committer. [1]

 Thank you Steven! And we are looking to see more of your contributions!

 Luke, on behalf of the Apache Beam PMC

 [1] https://beam.apache.org/contribute/become-a-committer
 /#an-apache-beam-committer

>>>

Re: Clean Up GitHub Labels

[Aizhamal Nurmamat kyzy]

Thank you, Danny!

On Wed, Jun 15, 2022 at 8:31 AM Danny McCormick 
wrote:

> Given the general consensus here, I put up a PR to enforce this for new
> issues here - https://github.com/apache/beam/pull/21888.
>
> Once that's in, I'll run a script to update all the existing labels to the
> new preferred scheme and we can delete the old labels that we don't need
> anymore.
>
> Thanks,
> Danny
>
> On Tue, Jun 14, 2022 at 4:53 PM Kenneth Knowles  wrote:
>
>> +1 sounds good to me
>>
>> One thing I did a lot of when triaging Jiras was moving them from one
>> component to another, after which people who cared about those components
>> would go through them. Making the labels more straightforward for users
>> would streamline that.
>>
>> Kenn
>>
>> On Sun, Jun 12, 2022 at 9:04 PM Chamikara Jayalath 
>> wrote:
>>
>>> +1 for this in general. Also, as noted in the proposal, decomposing
>>> labels should be done on a case by case basis since in some cases that
>>> might result in creating labels that do not have proper context.
>>>
>>> Thanks,
>>> Cham
>>>
>>> On Fri, Jun 10, 2022 at 8:35 AM Robert Burke  wrote:
>>>
 +1. I like this consolidation proposal, but i also like thinking
 through conjunctions. :)

 On Fri, Jun 10, 2022, 6:42 AM Danny McCormick <
 dannymccorm...@google.com> wrote:

> Hey everyone,
>
> After migrating over from Jira, our labels are somewhat messy and not
> as helpful as they could be. Specifically, there are 2 sets of problems:
>
>
> 1. There is significant overlap between the labels imported from Jira
> and the labels we already had in GitHub for our PRs. For example, there 
> was
> already a “Go” GitHub label, and as part of the migration we imported a
> “sdk-go” label.
>
>
> 2. Because GitHub doesn’t provide an OR syntax in its searching, it is
> much harder to search for things like “all io labels” because the io 
> issues
> are sharded across a number of io tags (e.g. io-java-aws,
> io-java-amqp, io-py-avro, etc…). This applies to other areas like runner
> issues, portability issues, and issues by language as well.
>
> I put together a quick 1 page proposal on how we can remove the label
> duplication and make searching easier by decomposing our labels into their
> smallest components. Please let me know if you have any thoughts or
> suggestions!
> https://docs.google.com/document/d/14S5coM_vfRrwygoQ9_NClJWmY5s30_L_J5yCurLW-XU/edit?usp=sharing
>
> Thanks,
> Danny
>

Re: Beam Website Add New Case Study

[Aizhamal Nurmamat kyzy]

Hi Nick,

It is great to hear from you, and I am very excited to learn about your use
case. I will follow up privately with the next steps :)

On Wed, May 4, 2022 at 9:23 AM Ahmet Altay  wrote:

> Hi Nick,
>
> Thank you for reaching out. It would be great to highlight your Beam use
> case.
>
> @Aizhamal Nurmamat kyzy  is the person who is
> coordinating the writing and publishing of case studies, she can work with
> you to get something started.
>
> Ahmet
>
> On Wed, May 4, 2022 at 10:19 AM Hwang, Nick 
> wrote:
>
>> Hello,
>>
>> We'd love to have Intuit featured as a prominent user of Beam. We have
>> built our entire self-serve Stream Processing Platform around Beam running
>> on top of Flink at Intuit, and have currently over 300 pipelines using
>> Beam. Please let us know what we can do to get featured, happy to share
>> more details.
>>
>> *Nick Hwang*
>>
>> Engineering Manager
>>
>> Data Infra, Stream Processing Platform
>>
>

Re: [DISCUSS] Migrate Jira to GitHub Issues?

[Aizhamal Nurmamat kyzy]

Thank you for putting this together, Danny! I can help with the label
creation task.

Anyone else want to help?

On Thu, Mar 17, 2022 at 11:55 AM Danny McCormick 
wrote:

> Here's a spreadsheet to sign up if you'd like to help with the migration!
> https://docs.google.com/spreadsheets/d/1hqztI7ECf8NjcmfQ8ZfUj6OU0U-6orJzhG6OMufmTFE/edit?usp=sharing
>
> Thanks,
> Danny
>
> On Thu, Mar 17, 2022 at 1:59 PM Danny McCormick 
> wrote:
>
>> Hey everyone,
>>
>> Aizhamal is currently out for a little bit and asked me to start to put
>> together a more detailed plan for migrating from Jira to GitHub since we
>> seem to have consensus here (or close to it). Here's my proposal on a plan
>> to migrate -
>> https://docs.google.com/document/d/1powrXGbjMLMYl9ibRzMda5o5HM_p44XvBy5MZu75Q5E/edit?usp=sharing
>> - I'd really appreciate any feedback or recommendations you have! In
>> particular, I imagine people will have thoughts on the plan to migrate
>> Jiras to Issues - I included that as a section and think its worth it, but
>> others may disagree (or disagree on the fields we care about keeping).
>>
>> If anyone is interested in helping with the migration itself, please
>> chime in as well! We will almost certainly need PMC help for some of the
>> settings level work, but there's also a decent bit of parallelizable work
>> available to update templates/documentation, update automation, and help
>> build/design the issue migrator!
>>
>> Thanks,
>> Danny
>>
>> On Thu, Feb 17, 2022 at 5:28 PM Sachin Agarwal 
>> wrote:
>>
>>> Thank you!  I believe the benefits to make it easier for folks to
>>> contribute to Beam will pay significant dividends quickly.
>>>
>>> On Thu, Feb 17, 2022 at 2:09 PM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
>>>> Awesome, thanks for the feedback everyone. Then I will go ahead, and
>>>> start documenting the plan in detail and share it here afterwards.
>>>>
>>>> On Tue, Feb 15, 2022 at 3:17 PM Alexey Romanenko <
>>>> aromanenko@gmail.com> wrote:
>>>>
>>>>> First of all, many thanks for putting the details into this design doc
>>>>> and sorry for delay with my response.
>>>>>
>>>>> I’m still quite neutral with this migration because of several
>>>>> concerns:
>>>>>
>>>>> - Imho, Github Issues is still not well enough mature as an issue
>>>>> tracker and it doesn’t provide the solutions for all needs as, for 
>>>>> example,
>>>>> Jira and other tracker do (though, seems that there are many features
>>>>> upcoming). For example, many things in GH Issues still can be resolved 
>>>>> only
>>>>> with “labels" and we can potentially end up with a huge bunch of them with
>>>>> a different naming policy, mixed purposes and so on.
>>>>>
>>>>> - If we won’t do a transfer of the issues/users/filters/etc from Jira
>>>>> to GH Issues then, it looks, that we will live with two trackers for some
>>>>> (unknown) amount of time which is not very convenient (I believe that we
>>>>> need to specify our workflows with having this).
>>>>>
>>>>> - If we do a transfer then what kind of tools are going to be used,
>>>>> how much time it will take - so, we’d need a detailed plan on this.
>>>>>
>>>>> On the other positive hand, for sure, GH Issues has, by design, a
>>>>> solid integration with other Github services which is, obviously, a huge
>>>>> advantage for the long term as well.
>>>>>
>>>>> In any case, adding (or substitute) a new tool should help us to make
>>>>> the development process, in general, easier and faster. So I hope we can
>>>>> achieve this with Github Issues.
>>>>>
>>>>> —
>>>>> Alexey
>>>>>
>>>>> On 15 Feb 2022, at 06:52, Aizhamal Nurmamat kyzy 
>>>>> wrote:
>>>>>
>>>>> Very humbly, I think the benefits of moving to GitHub Issues
>>>>> outweigh the shortcomings.
>>>>>
>>>>> Jan, Kenn, Alexey, JB: adding you directly as you had some concerns.
>>>>> Please, let us know if they were addressed by the options that we 
>>>>> described
>>>>> in the doc [1]?
>>>>>
>>>>> If noone objects, I can st

Re: [ANNOUNCE] New committer: Evan Galpin

[Aizhamal Nurmamat kyzy]

Congratulations, Evan! And thank you for all your contributions!

On Fri, Mar 11, 2022 at 10:14 AM Alexey Romanenko 
wrote:

> Congratulations, Evan! Well deserved!
>
> —
> Alexey
>
> On 10 Mar 2022, at 21:17, Evan Galpin  wrote:
>
> Thanks Etienne and Sachin!  I'm thrilled to be joining as a committer! :-)
>
> - Evan
>
> On Thu, Mar 10, 2022 at 12:41 PM Sachin Agarwal 
> wrote:
>
>> Congratulations Evan!!
>>
>> On Thu, Mar 10, 2022 at 8:59 AM Etienne Chauchot 
>> wrote:
>>
>>> Hi all,
>>>
>>> Please join me and the rest of the Beam PMC in welcoming
>>> a new committer: Evan Galpin
>>>
>>> Since joining the Beam community Evan has done lots of contributions to
>>> IOs mainly Elasticsearch, but also to SDK transforms. He also gave support
>>> on the ML and tested releases.
>>> Considering these highlighted contributions and the rest, the Beam PMC
>>> trusts Evan with the responsibilities of a Beam committer [1].
>>>
>>> Thank you, Evan, for your contributions.
>>>
>>> [1]
>>> https://beam.apache.org/contribute/become-a-committer/#what-are-the-traits-of-an-apache-beam-committer
>>>
>>> Etienne, on behalf of the Apache Beam PMC
>>>
>>>
>

Re: [ANNOUNCE] Apache Beam 2.37.0 Released

[Aizhamal Nurmamat kyzy]

Thank you, Brian!

On Wed, Mar 9, 2022, 9:42 AM Ahmet Altay  wrote:

> Thank you Brian!
>
> On Wed, Mar 9, 2022 at 7:59 AM Brian Hulette  wrote:
>
>> The Apache Beam team is pleased to announce the release of version 2.37.0.
>>
>> Apache Beam is an open source unified programming model to define and
>> execute data processing pipelines, including ETL, batch and stream
>> (continuous) processing. See https://beam.apache.org
>>
>> You can download the release here:
>>
>> https://beam.apache.org/get-started/downloads/
>>
>> This release includes bug fixes, features, and improvements detailed on
>> the Beam blog: https://beam.apache.org/blog/beam-2.37.0/
>>
>> Thanks to everyone who contributed to this release, and we hope you enjoy
>> using Beam 2.37.0.
>>
>> -- Brian Hulette, on behalf of The Apache Beam team
>>
>

Beam Contributor of the Month: It's That Time Again!

[Aizhamal Nurmamat kyzy]

Hi everyone,

I hope you all had a great week thus far! I wanted to reach out to give a
congratulations to Tamir Yardeni as our January Contributor of the month!
Yardeni was chosen by popular vote for their excellent work on different
parts of Beam.

Let's continue the gratitude thread by nominating your coworkers for
February! Please continue the submissions in the form below [1] or reply to
me via email with the person you are nominating, their contact address and
one sentence explaining why they are your chosen nomination.

Thank you :)

[1]
https://docs.google.com/forms/d/1377tB5RWeON2Fxn3CgHdO_hcXkpMGG6qNNGASSqrz8U/viewform?edit_requested=true=1757680734868150072

Re: [DISCUSS] Migrate Jira to GitHub Issues?

[Aizhamal Nurmamat kyzy]

Awesome, thanks for the feedback everyone. Then I will go ahead, and start
documenting the plan in detail and share it here afterwards.

On Tue, Feb 15, 2022 at 3:17 PM Alexey Romanenko 
wrote:

> First of all, many thanks for putting the details into this design doc and
> sorry for delay with my response.
>
> I’m still quite neutral with this migration because of several concerns:
>
> - Imho, Github Issues is still not well enough mature as an issue tracker
> and it doesn’t provide the solutions for all needs as, for example, Jira
> and other tracker do (though, seems that there are many features upcoming).
> For example, many things in GH Issues still can be resolved only with
> “labels" and we can potentially end up with a huge bunch of them with a
> different naming policy, mixed purposes and so on.
>
> - If we won’t do a transfer of the issues/users/filters/etc from Jira to
> GH Issues then, it looks, that we will live with two trackers for some
> (unknown) amount of time which is not very convenient (I believe that we
> need to specify our workflows with having this).
>
> - If we do a transfer then what kind of tools are going to be used, how
> much time it will take - so, we’d need a detailed plan on this.
>
> On the other positive hand, for sure, GH Issues has, by design, a solid
> integration with other Github services which is, obviously, a huge
> advantage for the long term as well.
>
> In any case, adding (or substitute) a new tool should help us to make the
> development process, in general, easier and faster. So I hope we can
> achieve this with Github Issues.
>
> —
> Alexey
>
> On 15 Feb 2022, at 06:52, Aizhamal Nurmamat kyzy 
> wrote:
>
> Very humbly, I think the benefits of moving to GitHub Issues outweigh the
> shortcomings.
>
> Jan, Kenn, Alexey, JB: adding you directly as you had some concerns.
> Please, let us know if they were addressed by the options that we described
> in the doc [1]?
>
> If noone objects, I can start working with some of you on Migration TODOs
> outlined in the doc I am referencing.
>
>
> [1]
> https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#bookmark=id.izn35w5gsjft
>
> On Thu, Feb 10, 2022 at 1:12 PM Danny McCormick 
> wrote:
>
>> I'm definitely +1 on moving to help make the bar for entry lower for new
>> contributors (like myself!)
>>
>> Thanks,
>> Danny
>>
>> On Thu, Feb 10, 2022 at 2:32 PM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Hi all,
>>>
>>> I think we've had a chance to discuss shortcomings and advantages. I
>>> think each person may have a different bias / preference. My bias is to
>>> move to Github, to have a more inclusive, approachable project despite the
>>> differences in workflow. So I'm +1 on moving.
>>>
>>> Could others share their bias? Don't think of this as a vote, but I'd
>>> like to get a sense of people's preferences, to see if there's a
>>> strong/slight feeling either way.
>>>
>>> Again, the sticky points are summarized here [1], feel free to add to
>>> the doc.
>>>
>>> [1]
>>> https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#
>>>
>>>
>>> On Mon, Jan 31, 2022 at 7:23 PM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
>>>> Welcome to the Beam community, Danny!
>>>>
>>>> We would love your help if/when we end up migrating.
>>>>
>>>> Please add your comments to the doc I shared[1], in case we missed some
>>>> cool GH features that could be helpful. Thanks!
>>>>
>>>> [1]
>>>> https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#
>>>>
>>>> On Mon, Jan 31, 2022, 10:06 AM Danny McCormick <
>>>> dannymccorm...@google.com> wrote:
>>>>
>>>>> > Then (this is something you'd have to code) you could easily write
>>>>> or use an existing GithubAction or bot that will assign the labels based 
>>>>> on
>>>>> the initial selection done by the user at entry. We have not done it yet
>>>>> but we might.
>>>>>
>>>>> Hey, new contributor here - wanted to chime in with a shameless plug
>>>>> because I happen to have written an action that does pretty much exactly
>>>>> what you're describing[1] and could be extensible to the use case 
>>>>> discussed
>>>>> here - it should basically 

Re: [DISCUSS] Migrate Jira to GitHub Issues?

[Aizhamal Nurmamat kyzy]

Very humbly, I think the benefits of moving to GitHub Issues outweigh the
shortcomings.

Jan, Kenn, Alexey, JB: adding you directly as you had some concerns.
Please, let us know if they were addressed by the options that we described
in the doc [1]?

If noone objects, I can start working with some of you on Migration TODOs
outlined in the doc I am referencing.


[1]
https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#bookmark=id.izn35w5gsjft

On Thu, Feb 10, 2022 at 1:12 PM Danny McCormick 
wrote:

> I'm definitely +1 on moving to help make the bar for entry lower for new
> contributors (like myself!)
>
> Thanks,
> Danny
>
> On Thu, Feb 10, 2022 at 2:32 PM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Hi all,
>>
>> I think we've had a chance to discuss shortcomings and advantages. I
>> think each person may have a different bias / preference. My bias is to
>> move to Github, to have a more inclusive, approachable project despite the
>> differences in workflow. So I'm +1 on moving.
>>
>> Could others share their bias? Don't think of this as a vote, but I'd
>> like to get a sense of people's preferences, to see if there's a
>> strong/slight feeling either way.
>>
>> Again, the sticky points are summarized here [1], feel free to add to the
>> doc.
>>
>> [1]
>> https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#
>>
>>
>> On Mon, Jan 31, 2022 at 7:23 PM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Welcome to the Beam community, Danny!
>>>
>>> We would love your help if/when we end up migrating.
>>>
>>> Please add your comments to the doc I shared[1], in case we missed some
>>> cool GH features that could be helpful. Thanks!
>>>
>>> [1]
>>> https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#
>>>
>>> On Mon, Jan 31, 2022, 10:06 AM Danny McCormick <
>>> dannymccorm...@google.com> wrote:
>>>
>>>> > Then (this is something you'd have to code) you could easily write or
>>>> use an existing GithubAction or bot that will assign the labels based on
>>>> the initial selection done by the user at entry. We have not done it yet
>>>> but we might.
>>>>
>>>> Hey, new contributor here - wanted to chime in with a shameless plug
>>>> because I happen to have written an action that does pretty much exactly
>>>> what you're describing[1] and could be extensible to the use case discussed
>>>> here - it should basically just require writing some config (example in
>>>> action[2]). In general, automated management of labels based on the initial
>>>> issue description + content isn't too hard, it does get significantly
>>>> trickier (but definitely still possible) if you try to automate labels
>>>> based on responses or edits.
>>>>
>>>> Also, big +1 that the easy integration with Actions is a significant
>>>> advantage of using issues since it helps keep your automations in one place
>>>> (or at least fewer places) and gives you a lot of tools out of the box both
>>>> from the community and from the Actions org. *Disclaimer:* I am
>>>> definitely biased. Until 3 weeks ago I was working on the Actions team at
>>>> GitHub.
>>>>
>>>> I'd be happy to help with some of the issue automation if we decide
>>>> that would be helpful, whether that's reusing existing work or tailoring it
>>>> more exactly to the Beam use case.
>>>>
>>>> [1] https://github.com/damccorm/tag-ur-it
>>>> [2] https://github.com/microsoft/azure-pipelines-tasks/issues/15839
>>>>
>>>> Thanks,
>>>> Danny
>>>>
>>>> On Mon, Jan 31, 2022 at 12:49 PM Zachary Houfek 
>>>> wrote:
>>>>
>>>>> > You can link PR to the issue by just mentioning #Issue in the commit
>>>>> message. If you do not prefix it with "Closes:" "Fixes:" or similar it 
>>>>> will
>>>>> be just linked
>>>>>
>>>>> Ok, thanks for the clarification there.
>>>>>
>>>>> Regards,
>>>>> Zach
>>>>>
>>>>> On Mon, Jan 31, 2022 at 12:43 PM Cristian Constantinescu <
>>>>> zei...@gmail.com> wrote:
>>>>>
>>>>>> I've been semi-following this thread, apologies if thi

Re: [DISCUSS] Migrate Jira to GitHub Issues?

[Aizhamal Nurmamat kyzy]

Hi all,

I think we've had a chance to discuss shortcomings and advantages. I think
each person may have a different bias / preference. My bias is to move to
Github, to have a more inclusive, approachable project despite the
differences in workflow. So I'm +1 on moving.

Could others share their bias? Don't think of this as a vote, but I'd like
to get a sense of people's preferences, to see if there's a strong/slight
feeling either way.

Again, the sticky points are summarized here [1], feel free to add to the
doc.

[1]
https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#


On Mon, Jan 31, 2022 at 7:23 PM Aizhamal Nurmamat kyzy 
wrote:

> Welcome to the Beam community, Danny!
>
> We would love your help if/when we end up migrating.
>
> Please add your comments to the doc I shared[1], in case we missed some
> cool GH features that could be helpful. Thanks!
>
> [1]
> https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#
>
> On Mon, Jan 31, 2022, 10:06 AM Danny McCormick 
> wrote:
>
>> > Then (this is something you'd have to code) you could easily write or
>> use an existing GithubAction or bot that will assign the labels based on
>> the initial selection done by the user at entry. We have not done it yet
>> but we might.
>>
>> Hey, new contributor here - wanted to chime in with a shameless plug
>> because I happen to have written an action that does pretty much exactly
>> what you're describing[1] and could be extensible to the use case discussed
>> here - it should basically just require writing some config (example in
>> action[2]). In general, automated management of labels based on the initial
>> issue description + content isn't too hard, it does get significantly
>> trickier (but definitely still possible) if you try to automate labels
>> based on responses or edits.
>>
>> Also, big +1 that the easy integration with Actions is a significant
>> advantage of using issues since it helps keep your automations in one place
>> (or at least fewer places) and gives you a lot of tools out of the box both
>> from the community and from the Actions org. *Disclaimer:* I am
>> definitely biased. Until 3 weeks ago I was working on the Actions team at
>> GitHub.
>>
>> I'd be happy to help with some of the issue automation if we decide that
>> would be helpful, whether that's reusing existing work or tailoring it more
>> exactly to the Beam use case.
>>
>> [1] https://github.com/damccorm/tag-ur-it
>> [2] https://github.com/microsoft/azure-pipelines-tasks/issues/15839
>>
>> Thanks,
>> Danny
>>
>> On Mon, Jan 31, 2022 at 12:49 PM Zachary Houfek 
>> wrote:
>>
>>> > You can link PR to the issue by just mentioning #Issue in the commit
>>> message. If you do not prefix it with "Closes:" "Fixes:" or similar it will
>>> be just linked
>>>
>>> Ok, thanks for the clarification there.
>>>
>>> Regards,
>>> Zach
>>>
>>> On Mon, Jan 31, 2022 at 12:43 PM Cristian Constantinescu <
>>> zei...@gmail.com> wrote:
>>>
>>>> I've been semi-following this thread, apologies if this has been raised
>>>> already.
>>>>
>>>> From a user point of view, in some corporate environments (that I've
>>>> worked at), Github is blocked. That includes the issues part. The Apache
>>>> Jira is not blocked and does at times provide value while investigating
>>>> issues.
>>>>
>>>> Obviously, users stuck in those unfortunate circonstances can just use
>>>> their personal device. Not advocating any direction on the matter, just
>>>> putting this out there.
>>>>
>>>> On Mon, Jan 31, 2022 at 12:21 PM Zachary Houfek 
>>>> wrote:
>>>>
>>>>> I added a suggestion that I don't think was discussed here:
>>>>>
>>>>> I know that we currently can link multiple PRs to a single Jira, but
>>>>> GitHub assumes a PR linked to an issue fixes the issue. You also need 
>>>>> write
>>>>> access to the repository to link the PR outside of using a "closing
>>>>> keyword". (For reference: Linking a pull request to an issue
>>>>> <https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue>
>>>>> )
>>>>>
>>>>> I'm not sure how much this could sway the decisions but thought it was
>>>>> worth bringing up.
>>>&g

Re: Thoughts from a first time contributor

[Aizhamal Nurmamat kyzy]

Welcome to the community Danny, and thanks for the feedback!

With some of our planned improvements on Beam's landing page, we are hoping
to address the 1st friction point you mentioned. We have received
similar feedback in the past a few times.

Regarding the 3rd feedback, I am hoping we can continue the discussion on
GH vs Jira issues, and some improvements will be introduced there as well.

Thanks again for the write up!

On Thu, Feb 3, 2022 at 3:27 PM Kenneth Knowles  wrote:

> Thanks for writing all this up and for putting up PRs to improve things!
>
> Kenn
>
> On Mon, Jan 31, 2022 at 12:17 PM Danny McCormick <
> dannymccorm...@google.com> wrote:
>
>>  Hey folks, my name is Danny - I recently completed my first Beam
>> PR[1] (a small extension to the Go Dataflow runner) and am planning on
>> becoming a more regular part of the community. As such, I wanted to use my
>> fresh newbie eyes and share some of what was nice and where there was
>> friction about getting started.
>>
>> Disclaimer: this is coming from the perspective of someone who is pretty
>> used to open source development, but has minimal experience with the Apache
>> way, Beam, and the languages my change came in. I'm hoping my experience is
>> helpful to those of you who have been around for a while and haven't seen
>> things as a newcomer in a long time, but it may not be reflective of the
>> experience of others.
>>
>> *Things that were really nice:*
>>
>> - The community has been really welcoming and encouraging of
>> contributions, something I saw in my first code review, my first pr, and
>> even the tone of the docs. Special thanks to @lostluck and @jrmccluskey for
>> making my first interactions welcoming and prompt. That experience can be
>> the difference between one time and repeat contributors.
>>
>> - Getting started writing my first pipeline, and then ramping up to more
>> complex concepts was surprisingly easy - in particular, the docs, examples,
>> and Katas made for a reasonably smooth process. It wasn't always clear how
>> to go from that to more complex transforms and there's of course room for
>> more clarity, but I appreciate the work that's gone into the getting
>> started experience.
>>
>> - Overall, the code base is pretty easily understood/reasoned about, and
>> the high quality of code made it pretty easy to make my first change. I'm
>> pretty impressed at how simple/well composed this system is even as it
>> approaches a tricky problem space (hopefully I'm saying the same thing
>> after I make some bigger changes :))
>>
>> *Friction Points:*
>>
>> - It was harder than expected for me to figure out what made Beam
>> different/special from other tools in the space out there for users.
>> Specifically, it wasn't immediately obvious why I would use Beam instead of
>> just running my jobs directly on Spark or Flink or one of the other
>> runners. One pretty big challenge here was that I didn't really get how
>> easy it was to switch runner types/how powerful the portability (and
>> unified streaming/batch) model was. I'm not sure exactly what would make
>> this easier for someone new to the space, but some sort of graphic or brief
>> statement of "this is where Beam adds value over most other frameworks" in
>> the Readme would be cool.
>>
>> - There were some small paper cut usability things in the repo.
>> Specifically, it looks like the labeler is broken (issue[2] and pr[3] added
>> to address this) and there isn't a CONTRIBUTING.md (issue[4] and pr[5]
>> added to address this), though the contribution guide is linked elsewhere.
>> Both of these are probably non-issues for experienced contributors, but add
>> a small amount of friction for people who are trying to get involved,
>> especially those who navigate a fair amount of OSS repos, and they're
>> pretty easy to fix.
>>
>> - I know there's some separate discussion about this in a different
>> thread[6], but the use of Jira instead of GitHub issues added a layer of
>> friction to getting started. Concretely, I would've put up my first pull
>> request and created my first issue earlier if I didn't need to go through
>> the process of creating a Jira account and getting permissions to assign
>> tickets, and it was harder to find a good first issue to contribute to. I
>> can imagine others might not have pushed through that.
>>
>> With all that said, I'm really excited to be joining the community and
>> get to add to Beam, and I hope it was helpful or interesting to get a
>> newbies perspective.
>>
>> [1] https://github.com/apache/beam/pull/16643
>> [2] https://issues.apache.org/jira/browse/BEAM-13779
>> [3] https://github.com/apache/beam/pull/16665
>> [4] https://issues.apache.org/jira/browse/BEAM-13780
>> [5] https://github.com/apache/beam/pull/1
>> [6] https://lists.apache.org/thread/q5nbwxqvfkzlz664c4kchzkbj26c3r89
>>
>> Thanks,
>> Danny
>>
>

Re: [DISCUSS] Migrate Jira to GitHub Issues?

[Aizhamal Nurmamat kyzy]

>>>> Thanks to that, it is much easier to agree on the common "conventions"
>>>>> to use and avoid creating new ones accidentally.
>>>>>
>>>>> We have quite a success with using the labels in Airflow as we use
>>>>> some of the stuff below:
>>>>>
>>>>> Re - some fancy enforcement/management, yeah. There are good
>>>>> techniques to control how/when the labels are attached:
>>>>>
>>>>> 1) You can create separate templates for Bugs/Features that can have
>>>>> different labels pre-assigned. See here:
>>>>> https://github.com/apache/airflow/tree/main/.github/ISSUE_TEMPLATE -
>>>>> this way you can delegate to the users to make basic "label choice" when
>>>>> they enter issues (though limited - 4-5 types of issues to choose from is
>>>>> really maximum what is reasonable).
>>>>> 2) The same "Issue Templates" already have the option to choose
>>>>> "selectable fields" at entry - you can define free-form entries, 
>>>>> drop-down,
>>>>> checkboxes and a few others. This is as close as it can get to "fields".
>>>>> Then (this is something you'd have to code) you could easily write or use
>>>>> an existing GithubAction or bot that will assign the labels based on the
>>>>> initial selection done by the user at entry. We have not done it yet but 
>>>>> we
>>>>> might.
>>>>> 3) In PRs you can (and we do that in Airflow) write your bot or use
>>>>> existing GitHub Actions to automatically select the labels based on the
>>>>> "files" that have been changed in the PR: We are doing precisely that in
>>>>> airflow and it works pretty well:
>>>>> https://github.com/apache/airflow/blob/main/.github/boring-cyborg.yml
>>>>>
>>>>> You are in full control, and you can choose the convention and
>>>>> approach for the project.
>>>>> There are literally hundreds of GitHub Actions out there and you can
>>>>> easily write a new one to manage it and you do not need anything but PR
>>>>> merged to the repository to enable and configure those actions.
>>>>> As maintainers, you do not have to create an INFRA JIRA(ehm!) tickets
>>>>> to manage them. You do not have to share anything with other projects.
>>>>>
>>>>> That's my 2 cents :)
>>>>>
>>>>> J.
>>>>>
>>>>>
>>>>> On Mon, Jan 31, 2022 at 5:45 PM Kenneth Knowles 
>>>>> wrote:
>>>>>
>>>>>> Maybe controversial: I think some things implemented "via labels"
>>>>>> shouldn't get full credit so I suggested changing them from green to 
>>>>>> yellow
>>>>>> :-)
>>>>>>
>>>>>> There's a really big difference between a free-form label and a field
>>>>>> where you know that there is exactly one value and the value is from a
>>>>>> limited set of options. For example priorities could be missing, 
>>>>>> duplicate
>>>>>> (both "P1" and "P2") or invented ("P8") unless labels have the ability to
>>>>>> have some fancy enforcement (I haven't looked at this). Same for 
>>>>>> resolution
>>>>>> status (is "Not a problem" just a label added as commentary or is it a
>>>>>> resolution status?) and issue type (something could be marked "bug" and
>>>>>> "feature request").
>>>>>>
>>>>>> Kenn
>>>>>>
>>>>>> On Mon, Jan 31, 2022 at 8:38 AM Kenneth Knowles 
>>>>>> wrote:
>>>>>>
>>>>>>> Great. I added a few items to the "summary of discussion" even
>>>>>>> though they weren't discussed here just to identify things that I care
>>>>>>> about and how you might do them in GitHub Issues.
>>>>>>>
>>>>>>> Kenn
>>>>>>>
>>>>>>> On Sat, Jan 29, 2022 at 6:20 PM Aizhamal Nurmamat kyzy <
>>>>>>> aizha...@apache.org> wrote:
>>>>>>>
>>>>>>>> Hey all,
>>>>>>>>
>>>>>>>> I summarized the discus

Re: [DISCUSS] Migrate Jira to GitHub Issues?

[Aizhamal Nurmamat kyzy]

Hey all,

I summarized the discussion in this document[1].

IMO a lot of the concerns raised can be worked around (multiple milestones,
components, tags, sub-issues), while the biggest benefit will be decreasing
the barrier for new users to contribute and have better discoverability and
linkage between code, issues and PRs.

Please assign your priority levels for the various features in the
comparison table. I left it out because I have a clear bias here : )

Next steps would be to decide whether (1) to move, and (2) to copy over
JIRA issues. IMO, Airflow's approach to not copy everything will be the
right choice.

[1]
https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#

On Fri, Jan 28, 2022 at 2:30 PM Brian Hulette  wrote:

> Thanks for volunteering to pick this up Aizhamal, while I'm interested in
> this change happening I don't have the bandwidth to push it along.
>
> I think there was another point where we're missing consensus: how would
> we deal with existing jiras. Do we write some automation to port
> everything, or just flip the switch and encourage users/devs to port active
> jiras over to GitHub?
>
> Manual porting pros:
> - Ambiguous situations get human attention.
> - Tickets with no interested parties will be implicitly cleared out of the
> backlog.
> - No need to write automation for porting tools.
> Manual porting cons:
> - Unambiguous situations get (unnecessary) human attention.
>
> A compromise might be to build a simple tool for porting jiras, but don't
> automatically run it on everything.
>
> On Tue, Jan 18, 2022 at 6:04 AM Kenneth Knowles  wrote:
>
>> I also think that we are at the point where a document describing them
>> side-by-side is needed. I would very much like to help. I strongly support
>> moving to GitHub Issues.
>>
>> I'm less concerned about pros/cons (I think the one big pro of "everyone
>> knows it and already has an account" outweighs almost any con) but I want
>> to build a very clear plan of how we will map Jira features to GitHub
>> features. I use quite a lot of Jira's features. In particular, a lot of
>> things seem like they'll become conventions around labels, which I expect
>> to often be low enough data quality that we would just not bother, unless
>> we can control it a bit.
>>
>> I eagerly await the link! Feel free to share very early :-)
>>
>> Kenn
>>
>> On Thu, Jan 13, 2022 at 1:48 PM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> I think I am enthusiastic enough to help with the doc :) will share the
>>> link soon.
>>>
>>> On Thu, Jan 13, 2022 at 10:12 AM Robert Bradshaw 
>>> wrote:
>>>
>>>> I don't know if we have consensus, but it seems that some people are
>>>> quite supportive (myself included), and some are ambivalent. The only
>>>> major con I can see is that github doesn't support tagging an issue to
>>>> multiple milestones (but it's unclear how important that is).
>>>>
>>>> I would suggest that someone enthusiastic about this proposal put
>>>> together a doc where we can enumerate the pros and cons and once the
>>>> list seems complete we can bring it back to the list for further
>>>> discussion and/or a vote (if needed, likely not).
>>>>
>>>> On Thu, Jan 13, 2022 at 9:27 AM Alexey Romanenko
>>>>  wrote:
>>>> >
>>>> > I’m not sure that we have a consensus on this. Since this thread
>>>> initially was started to discuss and gather some feedback then I think it
>>>> would be great to have a summary with pros and cons of this migration.
>>>> >
>>>> > —
>>>> > Alexey
>>>> >
>>>> > On 13 Jan 2022, at 00:11, Aizhamal Nurmamat kyzy 
>>>> wrote:
>>>> >
>>>> > Hi all,
>>>> >
>>>> > Is there a consensus to migrate to GitHub?
>>>> >
>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette 
>>>> wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles 
>>>> wrote:
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>> j...@nanthrax.net> wrote:
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> No problem for me. The only thing I don’t like wi

Re: Nominate Beam Contributor of the Month - January

[Aizhamal Nurmamat kyzy]

A kind reminder to nominate people who have been doing an awesome job on
Beam by filling out the form for Contributor of the Months [1]. It really
takes 2 min max :)

[1]
https://docs.google.com/forms/d/1377tB5RWeON2Fxn3CgHdO_hcXkpMGG6qNNGASSqrz8U/viewform?edit_requested=true=1757680734868150072

On Wed, Jan 19, 2022 at 2:56 PM Aizhamal Nurmamat kyzy 
wrote:

> Hey everybody,
>
> I thought it would be great if we celebrated each other's work even more
> by selecting Contributor of the Month by a popular vote. I'd really
> encourage everyone to participate (even though it is optional) and let us
> know who is doing excellent work on different parts of Beam. The winner
> will get a small "Thank you" gift from Google's open source programs office.
>
> It will be a very simple process: each month, I will start a thread asking
> you to nominate someone you know by either filling out this form [1] or
> just replying to me via email with the name of the person you are
> nominating, their contact address and one sentence explaining why you are
> nominating them.
>
> Treat this as a January thread and start sending us the names!
>
> Thank you :)
>
> [1]
> https://docs.google.com/forms/d/1377tB5RWeON2Fxn3CgHdO_hcXkpMGG6qNNGASSqrz8U/viewform?edit_requested=true=1757680734868150072
>
>

Nominate Beam Contributor of the Month - January

[Aizhamal Nurmamat kyzy]

Hey everybody,

I thought it would be great if we celebrated each other's work even more by
selecting Contributor of the Month by a popular vote. I'd really encourage
everyone to participate (even though it is optional) and let us know who is
doing excellent work on different parts of Beam. The winner will get a
small "Thank you" gift from Google's open source programs office.

It will be a very simple process: each month, I will start a thread asking
you to nominate someone you know by either filling out this form [1] or
just replying to me via email with the name of the person you are
nominating, their contact address and one sentence explaining why you are
nominating them.

Treat this as a January thread and start sending us the names!

Thank you :)

[1]
https://docs.google.com/forms/d/1377tB5RWeON2Fxn3CgHdO_hcXkpMGG6qNNGASSqrz8U/viewform?edit_requested=true=1757680734868150072

Re: [DISCUSS] Migrate Jira to GitHub Issues?

[Aizhamal Nurmamat kyzy]

I think I am enthusiastic enough to help with the doc :) will share the
link soon.

On Thu, Jan 13, 2022 at 10:12 AM Robert Bradshaw 
wrote:

> I don't know if we have consensus, but it seems that some people are
> quite supportive (myself included), and some are ambivalent. The only
> major con I can see is that github doesn't support tagging an issue to
> multiple milestones (but it's unclear how important that is).
>
> I would suggest that someone enthusiastic about this proposal put
> together a doc where we can enumerate the pros and cons and once the
> list seems complete we can bring it back to the list for further
> discussion and/or a vote (if needed, likely not).
>
> On Thu, Jan 13, 2022 at 9:27 AM Alexey Romanenko
>  wrote:
> >
> > I’m not sure that we have a consensus on this. Since this thread
> initially was started to discuss and gather some feedback then I think it
> would be great to have a summary with pros and cons of this migration.
> >
> > —
> > Alexey
> >
> > On 13 Jan 2022, at 00:11, Aizhamal Nurmamat kyzy 
> wrote:
> >
> > Hi all,
> >
> > Is there a consensus to migrate to GitHub?
> >
> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette 
> wrote:
> >>
> >>
> >>
> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles  wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre 
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> No problem for me. The only thing I don’t like with GitHub issues is
> that fact that it’s not possible to “assign” several milestones to an issue.
> >>>> When we maintain several active branch/version, it sucks (one issue
> == one milestone), as we have to create several issue.
> >>>
> >>>
> >>> This is a good point to consider. In Beam we often create multiple
> issues anyhow when we intend to backport/cherrypick a fix. One issue for
> the original fix and one each targeted cherrypick. This way their
> resolution status can be tracked separately. But it is nice for users to be
> able to go back and edit the original bug report to say which versions are
> affected and which are not.
> >>
> >>
> >> I looked into this a little bit. It looks like milestones don't have to
> represent a release (e.g. they could represent some abstract goal), but
> they are often associated with releases. This seems like a reasonable field
> to map to "Fix Version/s" in jira, but jira does support specifying
> multiple releases. So one issue == one milestone would be a regression.
> >> As Kenn pointed out though we often create a separate jira to track
> backports anyway (even though we could just specify multiple fix versions),
> so I'm not sure this is a significant blocker.
> >>
> >> If we want to use milestones to track abstract goals, I think we'd be
> out of luck. We could just use labels, but the GitHub UI doesn't present a
> nice burndown chart for those. See
> https://github.com/pandas-dev/pandas/milestones vs.
> https://github.com/pandas-dev/pandas/labels. FWIW jira doesn't have great
> functionality here either.
> >>
> >>>
> >>>
> >>> Kenn
> >>>
> >>>>
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> > Le 10 déc. 2021 à 01:28, Kyle Weaver  a écrit
> :
> >>>> >
> >>>> > I’m in favor of switching to Github issues. I can’t think of a
> single thing jira does better.
> >>>> >
> >>>> > Thanks Jarek, this is a really great resource [1]. For another
> reference, the Calcite project is engaged in the same discussion right now
> [2]. I came up with many of the same points independently before I saw
> their thread.
> >>>> >
> >>>> > When evaluating feature parity, we should make a distinction
> between non-structured (text) and structured data. And we don’t need a
> strict mechanical mapping for everything unless we’re planning on
> automatically migrating all existing issues. I don’t see the point in
> automatic migration, though; as Jarek pointed out, we’d end up perpetuating
> a ton of obsolete issues.
> >>>> >
> >>>> >   • We use nested issues and issue relations in jira, but as
> far as I know robots don’t use them and we don’t query them much, so we’re
> not losing anything by moving from an API to plain English descriptions:
> “This issue is blocked by issue #n.” Mentions show up automatically on
>

Re: [DISCUSS] Migrate Jira to GitHub Issues?

[Aizhamal Nurmamat kyzy]

Hi all,

Is there a consensus to migrate to GitHub?

On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette  wrote:

>
>
> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles  wrote:
>
>>
>>
>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre 
>> wrote:
>>
>>> Hi,
>>>
>>> No problem for me. The only thing I don’t like with GitHub issues is
>>> that fact that it’s not possible to “assign” several milestones to an issue.
>>> When we maintain several active branch/version, it sucks (one issue ==
>>> one milestone), as we have to create several issue.
>>>
>>
>> This is a good point to consider. In Beam we often create multiple issues
>> anyhow when we intend to backport/cherrypick a fix. One issue for the
>> original fix and one each targeted cherrypick. This way their resolution
>> status can be tracked separately. But it is nice for users to be able to go
>> back and edit the original bug report to say which versions are affected
>> and which are not.
>>
>
> I looked into this a little bit. It looks like milestones don't have to
> represent a release (e.g. they could represent some abstract goal), but
> they are often associated with releases. This seems like a reasonable field
> to map to "Fix Version/s" in jira, but jira does support specifying
> multiple releases. So one issue == one milestone would be a regression.
> As Kenn pointed out though we often create a separate jira to track
> backports anyway (even though we could just specify multiple fix versions),
> so I'm not sure this is a significant blocker.
>
> If we want to use milestones to track abstract goals, I think we'd be out
> of luck. We could just use labels, but the GitHub UI doesn't present a nice
> burndown chart for those. See
> https://github.com/pandas-dev/pandas/milestones vs.
> https://github.com/pandas-dev/pandas/labels. FWIW jira doesn't have great
> functionality here either.
>
>
>>
>> Kenn
>>
>>
>>>
>>> Regards
>>> JB
>>>
>>> > Le 10 déc. 2021 à 01:28, Kyle Weaver  a écrit :
>>> >
>>> > I’m in favor of switching to Github issues. I can’t think of a single
>>> thing jira does better.
>>> >
>>> > Thanks Jarek, this is a really great resource [1]. For another
>>> reference, the Calcite project is engaged in the same discussion right now
>>> [2]. I came up with many of the same points independently before I saw
>>> their thread.
>>> >
>>> > When evaluating feature parity, we should make a distinction between
>>> non-structured (text) and structured data. And we don’t need a strict
>>> mechanical mapping for everything unless we’re planning on automatically
>>> migrating all existing issues. I don’t see the point in automatic
>>> migration, though; as Jarek pointed out, we’d end up perpetuating a ton of
>>> obsolete issues.
>>> >
>>> >   • We use nested issues and issue relations in jira, but as far
>>> as I know robots don’t use them and we don’t query them much, so we’re not
>>> losing anything by moving from an API to plain English descriptions: “This
>>> issue is blocked by issue #n.” Mentions show up automatically on other
>>> issues.
>>> >   • For component, type, priority, etc., we can use Github labels.
>>> >   • Version(s) affected is used inconsistently, and as far as I
>>> know only by humans, so a simple English description is fine. We can follow
>>> the example of other projects and make the version affected a part of the
>>> issue template.
>>> >   • For fix version, which we use to track which issues we want to
>>> fix in upcoming releases, as well as automatically generate release notes:
>>> Github has “milestones,” which can be marked on PRs or issues, or both.
>>> >   • IMO the automatically generated JIRA release notes are
>>> not especially useful anyway. They are too detailed for a quick summary,
>>> and not precise enough to show everything. For a readable summary, we use
>>> CHANGES.md to highlight changes we especially want users to know about. For
>>> a complete list of changes, there’s the git commit log, which is the
>>> ultimate source of truth.
>>> >   • We’d only want to preserve reporter and assignee if we’re
>>> planning on migrating everything automatically, and even then I think it’d
>>> be fine to compile a map of active contributors and drop the rest.
>>> >
>>> > As for the advantages of switching (just the ones off the top of my
>>> head):
>>> >   • As others have mentioned, it’s less burden for new
>>> contributors to create new issues and comment on existing ones.
>>> >   • Effortless linking between issues and PRs.
>>> >   • Github -> jira links were working for a short while,
>>> but they seem to be broken at the moment.
>>> >   • Jira -> github links only show: “links to GitHub Pull
>>> Request #x”. They don’t say the status of the PR, so you have to follow
>>> the link to find out. Especially inconvenient when one jira maps to several
>>> PRs, and you have to open all the links to get a summary of what work was
>>> done.
>>> > 

[RFC][design/idea] Beam Playground - Interactive Learning for Apache Beam

[Aizhamal Nurmamat kyzy]

TL:DR: We want to develop a Beam Playground. Please review the design[1]
and fill up this survey [2] to help us
prioritize features.

Hi all,

I along with a few community members thought of an idea to develop an
interactive environment to try out Beam transforms and examples. We are
calling it Beam Playground. The vision for the Playground is to be a *web
application where users can try out Beam without having to install /
initialize a Beam environment*.

We hope that this new tool will make it easier for new users to evaluate
and adopt Apache Beam, and provide positive developer experience.

The backend architecture and implementation details are described in the
design document[1].

We would be grateful if you filled out this poll[2] to help us prioritize
Beam Playground’s features.

Please share your feedback both on the idea and the design doc, and via the
survey.

We hope to build the Beam Playground in the next few months (see the
general timeline[3]), and your feedback would be very valuable to make sure
we develop a useful application.

Thanks!

Aizhamal

[1]
https://docs.google.com/document/d/1uf58Auags4DBqSU3nZWxfaDH2BcBvKxhmy0Ug-xoewQ/edit?usp=sharing

[2] https://forms.gle/ieknXjFSezqbAmFd6

[3]
https://docs.google.com/presentation/d/13ETJItGH3QV9hlQXce-47ZEDjOZUNNCJc5PyUUI1EIw/edit#slide=id.gef11b54893_0_0

Re: [Register] Allyship workshop for open source communities

[Aizhamal Nurmamat kyzy]

The Allyship workshop for open source communities is scheduled for next
week Thursday Sep 16th!

If interested, sign up via
https://docs.google.com/forms/d/1DM7KNyd7QQKiCRrepQTIDAChvtC6QERCt1JUNO5R3Fc/edit

Feel free to forward to other communities that might be interested. Thanks
a lot!

On Sun, Aug 22, 2021 at 11:38 AM Michael Sokolov  wrote:

> Thanks for the invitation. I'm interested, but will be unavailable on
> that day. Please do let us know if another opportunity comes around
>
> -Mike
>
> On Fri, Aug 20, 2021 at 1:03 PM Aizhamal Nurmamat kyzy
>  wrote:
> >
> > Hi everyone,
> >
> > I am helping to organize an allyship training for open source
> contributors
> > sponsored by Google's OSPO. Few folks have expressed interest in this
> > workshop, so I am extending the invite to all of you.
> >
> > Workshop date: Thursday, September 16th, 2021 at 8:30am PST or 5:30 PM
> > CEST.
> > Please register by filling out the form linked below[1]
> >
> > Here are more details:
> >
> > The training led by Dr. Kim Tran (https://www.kimtranphd.com/) aims to
> > position people of color and those in solidarity with us to develop the
> > necessary skills to build bridges across race, ability, gender, sexuality
> > and class.
> >
> > Participants will leave:
> > - With the capacity to identify marginalization in real time in the open
> > source community
> > - Knowing how to address and respond to marginalization at individual and
> > systemic levels
> > - With a strong, critical understanding of the allyship framework
> > - Intersectional lenses, examining dynamics around gender, class, ability
> > and race
> > - A toolkit for recognizing and combating marginalization in real time
> >
> > Format:
> > - Large groups will engage in a *90 minute*, remote learning session.
> > - Participants will be capped at 45 to enable engaging interactive
> > participation and responsiveness to participant questions and concerns.
> > - Session will include webinar style portion as well as breakouts for
> > hypothetical scenarios.
> >
> >
> > [1]
> >
> https://docs.google.com/forms/d/1DM7KNyd7QQKiCRrepQTIDAChvtC6QERCt1JUNO5R3Fc/edit
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

[Register] Allyship workshop for open source communities

[Aizhamal Nurmamat kyzy]

Hi everyone,

I am helping to organize an allyship training for open source contributors
sponsored by Google's OSPO. Few folks have expressed interest in this
workshop, so I am extending the invite to all of you.

Workshop date: Thursday, September 16th, 2021 at 8:30am PST or 5:30 PM
CEST.
Please register by filling out the form linked below[1]

Here are more details:

The training led by Dr. Kim Tran (https://www.kimtranphd.com/) aims to
position people of color and those in solidarity with us to develop the
necessary skills to build bridges across race, ability, gender, sexuality
and class.

Participants will leave:
- With the capacity to identify marginalization in real time in the open
source community
- Knowing how to address and respond to marginalization at individual and
systemic levels
- With a strong, critical understanding of the allyship framework
- Intersectional lenses, examining dynamics around gender, class, ability
and race
- A toolkit for recognizing and combating marginalization in real time

Format:
- Large groups will engage in a *90 minute*, remote learning session.
- Participants will be capped at 45 to enable engaging interactive
participation and responsiveness to participant questions and concerns.
- Session will include webinar style portion as well as breakouts for
hypothetical scenarios.


[1]
https://docs.google.com/forms/d/1DM7KNyd7QQKiCRrepQTIDAChvtC6QERCt1JUNO5R3Fc/edit

Re: Allyship workshops for open source contributors

[Aizhamal Nurmamat kyzy]

Sorry. Here is the link:
https://doodle.com/poll/d57tcpt46tkvtvay?utm_source=poll_medium=link

On Wed, Aug 4, 2021 at 3:32 PM Aizhamal Nurmamat kyzy 
wrote:

> Hi all,
>
> I will get this workshop scheduled for September. I am trying to figure
> out which day/time works best considering the US and EU timezone
> participants. I suggest we start at 8am PST, which is 5pm CEST. Would that
> work for most of you? Could you please indicate days you would prefer by
> voting in this poll too?
>
> Thanks a lot!
>
> On Mon, Jun 14, 2021 at 12:00 PM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Thank you all! Based on the feedback, I will set up a session for a
>> couple open source groups. Will share more details soon. Stay tuned.
>>
>> On Mon, Jun 7, 2021 at 4:42 PM Kenneth Knowles  wrote:
>>
>>> Yes please!
>>>
>>> On Thu, Jun 3, 2021, 18:32 Ratnakar Malla  wrote:
>>>
>>>> +1
>>>>
>>>>
>>>> --
>>>> *From:* Austin Bennett 
>>>> *Sent:* Thursday, June 3, 2021 6:20:25 PM
>>>> *To:* u...@beam.apache.org 
>>>> *Cc:* dev 
>>>> *Subject:* Re: Allyship workshops for open source contributors
>>>>
>>>> +1, assuming timing can work.
>>>>
>>>> On Wed, Jun 2, 2021 at 2:07 PM Aizhamal Nurmamat kyzy <
>>>> aizha...@apache.org> wrote:
>>>>
>>>> If we have a good number of people who express interest in this thread,
>>>> I will set up training for the Airflow community.
>>>>
>>>>
>>>> I meant Beam ^^' I am organizing it for the Airflow community as well.
>>>>
>>>>

Re: Allyship workshops for open source contributors

[Aizhamal Nurmamat kyzy]

Hi all,

I will get this workshop scheduled for September. I am trying to figure out
which day/time works best considering the US and EU timezone participants.
I suggest we start at 8am PST, which is 5pm CEST. Would that work for most
of you? Could you please indicate days you would prefer by voting in this
poll too?

Thanks a lot!

On Mon, Jun 14, 2021 at 12:00 PM Aizhamal Nurmamat kyzy 
wrote:

> Thank you all! Based on the feedback, I will set up a session for a couple
> open source groups. Will share more details soon. Stay tuned.
>
> On Mon, Jun 7, 2021 at 4:42 PM Kenneth Knowles  wrote:
>
>> Yes please!
>>
>> On Thu, Jun 3, 2021, 18:32 Ratnakar Malla  wrote:
>>
>>> +1
>>>
>>>
>>> --
>>> *From:* Austin Bennett 
>>> *Sent:* Thursday, June 3, 2021 6:20:25 PM
>>> *To:* u...@beam.apache.org 
>>> *Cc:* dev 
>>> *Subject:* Re: Allyship workshops for open source contributors
>>>
>>> +1, assuming timing can work.
>>>
>>> On Wed, Jun 2, 2021 at 2:07 PM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
>>> If we have a good number of people who express interest in this thread,
>>> I will set up training for the Airflow community.
>>>
>>>
>>> I meant Beam ^^' I am organizing it for the Airflow community as well.
>>>
>>>

Re: Allyship workshops for open source contributors

[Aizhamal Nurmamat kyzy]

Thank you all! Based on the feedback, I will set up a session for a couple
open source groups. Will share more details soon. Stay tuned.

On Mon, Jun 7, 2021 at 4:42 PM Kenneth Knowles  wrote:

> Yes please!
>
> On Thu, Jun 3, 2021, 18:32 Ratnakar Malla  wrote:
>
>> +1
>>
>>
>> --
>> *From:* Austin Bennett 
>> *Sent:* Thursday, June 3, 2021 6:20:25 PM
>> *To:* u...@beam.apache.org 
>> *Cc:* dev 
>> *Subject:* Re: Allyship workshops for open source contributors
>>
>> +1, assuming timing can work.
>>
>> On Wed, Jun 2, 2021 at 2:07 PM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>> If we have a good number of people who express interest in this thread, I
>> will set up training for the Airflow community.
>>
>>
>> I meant Beam ^^' I am organizing it for the Airflow community as well.
>>
>>

Re: Allyship workshops for open source contributors

[Aizhamal Nurmamat kyzy]

>
> If we have a good number of people who express interest in this thread, I
> will set up training for the Airflow community.
>

I meant Beam ^^' I am organizing it for the Airflow community as well.

Allyship workshops for open source contributors

[Aizhamal Nurmamat kyzy]

Hi Beamers,

Would this community be interested in taking the Allyship Training? It
requires a 90min commitment for remote session learning. If we have a good
number of people who express interest in this thread, I will set up
training for the Airflow community. If we don't have the critical mass, I
might invite people from other open source projects, but the format and
learning will be the same!

Here are more details:

The training is led by Dr. Kim Tran (https://www.kimtranphd.com/), it aims
to position people of color and those in solidarity with us to develop the
necessary skills to build bridges across race, ability, gender, sexuality
and class.

Participants will leave:
- With the capacity to identify marginalization in real time in the open
source community
- Knowing how to address and respond to marginalization at individual and
systemic levels
- With a strong, critical understanding of the allyship framework
- Intersectional lenses, examining dynamics around gender, class, ability
and race
- A toolkit for recognizing and combating marginalization in real time

Format:
- Large groups will engage in a *90 minute*, remote learning session.
- Participants will be capped at 45 to enable engaging interactive
participation and responsiveness to participant questions and concerns.
- Session will include webinar style portion as well as breakouts for
hypothetical scenarios.

If you'd like to participate, please leave +1 under this thread. The thread
will stay open for 1 week.

Thanks,
Aizhamal

Re: Hi Team

[Aizhamal Nurmamat kyzy]

Welcome, Uday!

On Mon, Mar 29, 2021 at 12:57 PM Ahmet Altay  wrote:

> Welcome Uday!
>
> On Mon, Mar 29, 2021 at 11:23 AM Uday Singh  wrote:
>
>> Hi Everyone,
>>
>> This is Uday and i will be working on Apache Beam from GCP dataflow team.
>> Looking forward to contributing to the community.
>>
>> Thanks
>> Uday
>>
>

Re: Builds Meeting this Thursday

[Aizhamal Nurmamat kyzy]

Hi all,
In case you may find this interesting / valuable: Airflow has configured
their own machines for Github actions.

Here's the PR https://github.com/apache/airflow/pull/13730

And here's the thread:
https://lists.apache.org/thread.html/r2e398f86479e4cbfca13c22e4499fb0becdbba20dd9d6d47e1ed30bd%40%3Cdev.airflow.apache.org%3E


On Mon, Feb 8, 2021 at 2:56 PM Ahmet Altay  wrote:

> Thank you for sharing this Ismaël.
>
> This 180 jobs limit across all Apache projects sounds like a problem for
> Beam, because we are running quite a bit of GH actions already. Following
> the Airflow suggestions, we can add VMs to apache-beam-testing projects to
> add Beam specifici private runners to address the issue. GHs suggestion
> against using private VMs in public projects [1] is related to the risk of
> unauthorized PRs running unexpected workloads in these VMs. As far as I
> remember, we did not have this problem with our jenkins machines and anyone
> being able to run code with their PRs. And Airflow has the suggestion of
> use preemptible machines. We can do the same and these machines are always
> recycled after 24 hours limiting the risks.
>
> /cc @Tyson Hamilton  @David Lu  @Alan
> Myrvold 
>
> [1]
> https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories
>
> On Mon, Feb 8, 2021 at 3:30 AM JB Onofré  wrote:
>
>> Hi Ismaël.
>>
>> Thanks for sharing. I started to evaluate GitHub actions on some other
>> Apache projects and the doc is interesting.
>>
>> Regards
>> JB
>>
>> > Le 8 févr. 2021 à 12:22, Ismaël Mejía  a écrit :
>> >
>> > Just for reference and related to this thread. It seems we may end up
>> > also having this queue issue (even if we don't fully move to Github
>> > actions).
>> > "For Apache projects, starting December 2020 we are experiencing a
>> > high strain of GitHub Actions jobs. All Apache projects are sharing
>> > 180 jobs and as more projects are using GitHub Actions the job queue
>> > becomes a serious bottleneck."
>> >
>> > An interesting document shared recently on builds@ goes deeper on how
>> > the Airflow project is dealing with this:
>> >
>> https://docs.google.com/document/d/1ZZeZ4BYMNX7ycGRUKAXv0s6etz1g-90Onn5nRQQHOfE/edit#
>> >
>> >> On Mon, Jan 18, 2021 at 1:28 PM Elliotte Rusty Harold
>> >>  wrote:
>> >>
>> >>> On Mon, Jan 18, 2021 at 10:49 AM Ismaël Mejía 
>> wrote:
>> >>>
>> >>> Thanks for sharing this Pablo, This looks super interesting. We should
>> >>> see if it could make sense to migrate our Jenkins infra to GitHub
>> >>> Actions given that it is free and quickly becoming the new 'standard',
>> >>> Good points it is 'free' because we will bring our machines and Google
>> >>> pays :) bad points we will become 100% github dependant.
>> >>>
>> >>
>> >> Github actions have a really big advantage over Jenkins: they run on
>> >> forks, not just branches. This is very useful to non-commmiter
>> >> contributors.
>> >>
>> >> On the minus side it's not clear if one can see the logs from the
>> >> integration tests, which is blocking some work in the
>> >> maven-site-plugin:
>> >>
>> >>
>> https://github.com/apache/maven-site-plugin/pull/34#issuecomment-762207488
>> >>
>> >> --
>> >> Elliotte Rusty Harold
>> >> elh...@ibiblio.org
>>
>>

Welcome Sruthi Sree Kumar - Season of Docs tech writer

[Aizhamal Nurmamat kyzy]

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: Season of Docs Interest

[Aizhamal Nurmamat kyzy]

Hey Sharon!

Thank you so much for your interest to contribute to Beam's documentation.
It is a big help that you have knowledge and experience with Spark and
Dataflow already.

In order to be considered for the program, you'll need to submit a proposal
with a summary of the documentation work that you would like to complete
while working with us on Apache Beam. I am adding +Pablo Estrada
 , assigned mentor for this project idea, if you have
specific questions regarding the capability matrix. You can also work with
me or Pablo if you want any feedback for your initial draft. For that
consider using Google Docs and share with us.

Also check out guides for technical writers provided by GSoD team [1]. It
has many tips on how to make your proposal to stand out.

Hope it helps, and let me know if you have any questions.
Aizhamal

[1]
https://developers.google.com/season-of-docs/docs/tech-writer-application-hints


On Wed, Jul 8, 2020 at 12:34 PM Sharon Lin  wrote:

> Hi Aizhamal,
>
> I'm a 4th year bachelors student at MIT studying computer science, and I'm
> interested in working with Apache Beam for Season of Docs! I recognize that
> it's close to the application deadline, but I'm an avid user of Apache
> Spark and would really love to help with documenting tools for developers.
>
> I'm interested in working on the update of the runner comparison page /
> capability matrix. I've set up Spark and Dataflow before, and I believe I
> have the necessary background to get started on the deliverables once the
> program begins.
>
> I've attached my resume if that's helpful. Thanks, and I hope to work with
> you!
>
> Best,
> Sharon Lin
> Department of EECS
> Massachusetts Institute of Technology
>
>

Re: [ANNOUNCE] New committer: Aizhamal Nurmamat kyzy

[Aizhamal Nurmamat kyzy]

Thanks everyone! It's been really nice to work with all of you :)

On Tue, Jun 30, 2020, 1:45 PM Ismaël Mejía  wrote:

> Congratulations Aizhamal!
> And thanks for all the dedication to the project.
>
> On Tue, Jun 30, 2020 at 8:08 PM Maximilian Michels  wrote:
> >
> > Congrats Aizhamal!
> >
> > On 30.06.20 17:34, Jan Lukavský wrote:
> > > Congratulations Aizhamal!
> > >
> > > On 6/30/20 1:35 PM, Alexey Romanenko wrote:
> > >> Congratulations!
> > >> Well deserved and thank you for your hard work, Aizhamal!
> > >>
> > >>> On 30 Jun 2020, at 13:31, Reza Rokni  > >>> <mailto:r...@google.com>> wrote:
> > >>>
> > >>> Congratulations !
> > >>>
> > >>> On Tue, Jun 30, 2020 at 2:46 PM Michał Walenia
> > >>> mailto:michal.wale...@polidea.com>>
> wrote:
> > >>>
> > >>> Congratulations, Aizhamal! :)
> > >>>
> > >>> On Tue, Jun 30, 2020 at 8:41 AM Tobiasz Kędzierski
> > >>>  > >>>     <mailto:tobiasz.kedzier...@polidea.com>> wrote:
> > >>>
> > >>> Congratulations Aizhamal! :)
> > >>>
> > >>> On Mon, Jun 29, 2020 at 11:50 PM Austin Bennett
> > >>>  > >>> <mailto:whatwouldausti...@gmail.com>> wrote:
> > >>>
> > >>> Congratulations, @Aizhamal Nurmamat kyzy
> > >>> <mailto:aizha...@google.com> !
> > >>>
> > >>> On Mon, Jun 29, 2020 at 2:32 PM Valentyn Tymofieiev
> > >>> mailto:valen...@google.com>>
> wrote:
> > >>>
> > >>> Congratulations and big thank you for all the hard
> > >>> work on Beam, Aizhamal!
> > >>>
> > >>> On Mon, Jun 29, 2020 at 9:56 AM Kenneth Knowles
> > >>> mailto:k...@apache.org>> 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://list

Re: [RESULT][VOTE] Accept the Firefly design donation as Beam Mascot - Deadline Mon April 6

[Aizhamal Nurmamat kyzy]

Thank you Ismael for reviewing and merging the pull request.

Now the mascot files can be found here
https://beam.apache.org/community/mascot/ on the website and here
https://github.com/apache/beam/tree/master/website/www/site/static/images/mascot
in
the repo.

This project is complete now, therefore closing this thread.

Thanks everyone!

On Thu, May 21, 2020 at 7:07 PM Aizhamal Nurmamat kyzy 
wrote:

> Hello everyone,
> Julian and I have created this pr[1] to create a page with the model
> sheet, and links to the mascot image files. Can someone please review?
> Thanks!
> Aizhamal
>
> [1] https://github.com/apache/beam/pull/11780
>
> On Mon, May 11, 2020 at 10:14 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> @Ismael, this is in my work items for as soon as we complete the
>> migration of the website.
>> @Kyle, thanks for filing Jira, I assigned it to myself.
>>
>> On Mon, May 11, 2020 at 10:03 AM Kyle Weaver  wrote:
>>
>>> > Now that the vote has passed maybe we should add the images somewhere
>>> > in the website so people can easily find the Firefly to use it
>>>
>>> +1 Maybe something to revisit after the website overhaul is complete. I
>>> filed https://jira.apache.org/jira/browse/BEAM-9948 if anyone wants to
>>> take it.
>>>
>>> On Mon, May 11, 2020 at 12:57 PM Ismaël Mejía  wrote:
>>>
>>>> Now that the vote has passed maybe we should add the images somewhere
>>>> in the website so people can easily find the Firefly to use it.
>>>> Something like what we do with our logos
>>>> https://beam.apache.org/community/logos/
>>>>
>>>> WDYT? any taker?
>>>>
>>>> On Tue, Apr 28, 2020 at 7:43 PM Pablo Estrada 
>>>> wrote:
>>>> >
>>>> > I'll be happy to as well!
>>>> >
>>>> > On Sun, Apr 26, 2020 at 4:18 AM Maximilian Michels 
>>>> wrote:
>>>> >>
>>>> >> Hey Maria,
>>>> >>
>>>> >> I can testify :)
>>>> >>
>>>> >> Cheers,
>>>> >> Max
>>>> >>
>>>> >> On 23.04.20 20:49, María Cruz wrote:
>>>> >> > Hi everyone!
>>>> >> > It is amazing to see how this process developed to collaboratively
>>>> >> > create Apache Beam's mascot. Thank you to everyone who got
>>>> involved!
>>>> >> > I would like to write a blogpost for the Beam website, and I
>>>> wanted to
>>>> >> > ask you: would anyone like to offer their testimony about the
>>>> process of
>>>> >> > creating the Beam mascot, and what this means to you? Everyone's
>>>> >> > testimony is welcome! If you witnessed the development of a mascot
>>>> for
>>>> >> > another open source project, even better =)
>>>> >> >
>>>> >> > Please feel free to express interest on this thread, and I'll
>>>> reach out
>>>> >> > to you off-list.
>>>> >> >
>>>> >> > Thanks,
>>>> >> >
>>>> >> > María
>>>> >> >
>>>> >> > On Fri, Apr 17, 2020 at 6:19 AM Jeff Klukas >>> >> > <mailto:jklu...@mozilla.com>> wrote:
>>>> >> >
>>>> >> > I personally like the sound of "Datum" as a name. I also like
>>>> the
>>>> >> > idea of not assigning them a gender.
>>>> >> >
>>>> >> > As a counterpoint on the naming side, one of the slide decks
>>>> >> > provided while iterating on the design mentions:
>>>> >> >
>>>> >> > > Mascot can change colors when it is “full of data” or has a
>>>> “batch
>>>> >> > of data” to process.  Yellow is supercharged and ready to
>>>> process!
>>>> >> >
>>>> >> > Based on that, I'd argue that the mascot maps to the concept
>>>> of a
>>>> >> > bundle in the beam execution model and we should consider a
>>>> name
>>>> >> > that's a play on "bundle" or perhaps a play on "checkpoint".
>>>> >> >
>>>> >> > On Thu, Apr 16, 2020 at 3:44 PM Julian Bruno <
>>>> juliangbr...@gmail.co

Re: Companies using Beam?

[Aizhamal Nurmamat kyzy]

Aizhamal, what is the plan for your document? Would it be fine if we add
> this powered_by page now, and edit as we go?
>
Yes. The document was created as a plan to add all those sections, but it
would be great to start adding them as soon as possible.



> Ahmet
>
> On Tue, May 26, 2020 at 2:30 PM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>>
>> Oops, just saw you linked it earlier Aizhamal. Is it still open for input?
>>>
>>> Yes, it is! Feel free to add suggestions right in the doc. The doc will
>> eventually need some cleanup/reorg, but now is a good time to add
>> suggestions. Thanks Matthias!
>>
>>
>>
>>> On Mon, 25 May 2020 at 09:20, Matthias Baetens <
>>> baetensmatth...@gmail.com> wrote:
>>>
>>>> I think this is a great idea. We could support the page with relevant
>>>> Meetup / Summit talks as well.
>>>>
>>>> Is there a place where we the website redesign is being planned and
>>>> where we can contribute ideas or discuss the structure of such a page?
>>>>
>>>> On Fri, 1 May 2020 at 20:00, Aizhamal Nurmamat kyzy <
>>>> aizha...@apache.org> wrote:
>>>>
>>>>> Another example of similar pages:
>>>>> https://www.instaclustr.com/resource-type/case-studies/. The whole
>>>>> resources section is very useful. It would be good for Beam to have links
>>>>> to webinars, meetups, books, whitepapers, etc. from the website where new
>>>>> users land.
>>>>> Simpler example: https://flink.apache.org/poweredby.html . It shows
>>>>> snippets and links to external (mostly) resources. Seems easier to manage.
>>>>>
>>>>>
>>>>> On Fri, May 1, 2020 at 6:28 AM Kenneth Knowles 
>>>>> wrote:
>>>>>
>>>>>> +1 to a "Powered By" style page. These are pretty common. Like
>>>>>> https://calcite.apache.org/docs/powered_by.html
>>>>>>
>>>>>> I think applying a designer's skills might result in something a bit
>>>>>> cooler looking...
>>>>>>
>>>>>> Kenn
>>>>>>
>>>>>> On Thu, Apr 30, 2020 at 9:24 AM Austin Bennett <
>>>>>> whatwouldausti...@gmail.com> wrote:
>>>>>>
>>>>>>> A first pass, something like:
>>>>>>>
>>>>>>> https://druid.apache.org/druid-powered
>>>>>>> https://spark.apache.org/powered-by.html
>>>>>>>
>>>>>>> or even as simple as:
>>>>>>> https://github.com/apache/airflow#who-uses-apache-airflow
>>>>>>>
>>>>>>> Would go a long way in the sorts of very high-level conversations
>>>>>>> I'm having around technology adoption/standardization.
>>>>>>>
>>>>>>> Getting into more specifics/testimonials/case-studies is also great,
>>>>>>> but I wouldn't expect those to get looked at by most, until passing the
>>>>>>> first bar of seeming to having a significant adoption.
>>>>>>>
>>>>>>> @Aizhamal Nurmamat kyzy   - happy to
>>>>>>> contribute as I can.
>>>>>>>
>>>>>>> On Tue, Apr 28, 2020 at 10:13 PM Jean-Baptiste Onofre <
>>>>>>> j...@nanthrax.net> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We already have some testimonials on Beam home page (I did the one
>>>>>>>> about Beam use at Talend).
>>>>>>>>
>>>>>>>> It makes sense to have a dedicated section as it gives ideas about
>>>>>>>> use case and production system running with Beam.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>> > Le 28 avr. 2020 à 23:42, Austin Bennett <
>>>>>>>> whatwouldausti...@gmail.com> a écrit :
>>>>>>>> >
>>>>>>>> > Hi All,
>>>>>>>> >
>>>>>>>> > Have we considered getting onto our website or our our GitHub
>>>>>>>> repo the ability for individuals to share that their company is using
>>>>>>>> Beam?  Seeing - what I believe to be a reasonable list of - companies
>>>>>>>> productively using Beam would be helpful to point others to.  For 
>>>>>>>> instance,
>>>>>>>> a common question I get is whether anyone or who is using?  I'm not 
>>>>>>>> sure
>>>>>>>> that's the best metric or datapoint in many cases for adoption, but a
>>>>>>>> heuristic that some rely upon.
>>>>>>>> >
>>>>>>>> > Naturally, we could ask for a roll-call, esp. via user list, but
>>>>>>>> imagining  a persistent web-list would be of interest.
>>>>>>>> >
>>>>>>>> > Cheers,
>>>>>>>> > Austin
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > P.S.  If putting such a list into our repo, that would also get
>>>>>>>> some people to submit PRs (so more contributors!) :-)
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>>

Re: Companies using Beam?

[Aizhamal Nurmamat kyzy]

> Oops, just saw you linked it earlier Aizhamal. Is it still open for input?
>
> Yes, it is! Feel free to add suggestions right in the doc. The doc will
eventually need some cleanup/reorg, but now is a good time to add
suggestions. Thanks Matthias!



> On Mon, 25 May 2020 at 09:20, Matthias Baetens 
> wrote:
>
>> I think this is a great idea. We could support the page with relevant
>> Meetup / Summit talks as well.
>>
>> Is there a place where we the website redesign is being planned and where
>> we can contribute ideas or discuss the structure of such a page?
>>
>> On Fri, 1 May 2020 at 20:00, Aizhamal Nurmamat kyzy 
>> wrote:
>>
>>> Another example of similar pages:
>>> https://www.instaclustr.com/resource-type/case-studies/. The whole
>>> resources section is very useful. It would be good for Beam to have links
>>> to webinars, meetups, books, whitepapers, etc. from the website where new
>>> users land.
>>> Simpler example: https://flink.apache.org/poweredby.html . It shows
>>> snippets and links to external (mostly) resources. Seems easier to manage.
>>>
>>>
>>> On Fri, May 1, 2020 at 6:28 AM Kenneth Knowles  wrote:
>>>
>>>> +1 to a "Powered By" style page. These are pretty common. Like
>>>> https://calcite.apache.org/docs/powered_by.html
>>>>
>>>> I think applying a designer's skills might result in something a bit
>>>> cooler looking...
>>>>
>>>> Kenn
>>>>
>>>> On Thu, Apr 30, 2020 at 9:24 AM Austin Bennett <
>>>> whatwouldausti...@gmail.com> wrote:
>>>>
>>>>> A first pass, something like:
>>>>>
>>>>> https://druid.apache.org/druid-powered
>>>>> https://spark.apache.org/powered-by.html
>>>>>
>>>>> or even as simple as:
>>>>> https://github.com/apache/airflow#who-uses-apache-airflow
>>>>>
>>>>> Would go a long way in the sorts of very high-level conversations I'm
>>>>> having around technology adoption/standardization.
>>>>>
>>>>> Getting into more specifics/testimonials/case-studies is also great,
>>>>> but I wouldn't expect those to get looked at by most, until passing the
>>>>> first bar of seeming to having a significant adoption.
>>>>>
>>>>> @Aizhamal Nurmamat kyzy   - happy to contribute
>>>>> as I can.
>>>>>
>>>>> On Tue, Apr 28, 2020 at 10:13 PM Jean-Baptiste Onofre 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We already have some testimonials on Beam home page (I did the one
>>>>>> about Beam use at Talend).
>>>>>>
>>>>>> It makes sense to have a dedicated section as it gives ideas about
>>>>>> use case and production system running with Beam.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> > Le 28 avr. 2020 à 23:42, Austin Bennett <
>>>>>> whatwouldausti...@gmail.com> a écrit :
>>>>>> >
>>>>>> > Hi All,
>>>>>> >
>>>>>> > Have we considered getting onto our website or our our GitHub repo
>>>>>> the ability for individuals to share that their company is using Beam?
>>>>>> Seeing - what I believe to be a reasonable list of - companies 
>>>>>> productively
>>>>>> using Beam would be helpful to point others to.  For instance, a common
>>>>>> question I get is whether anyone or who is using?  I'm not sure that's 
>>>>>> the
>>>>>> best metric or datapoint in many cases for adoption, but a heuristic that
>>>>>> some rely upon.
>>>>>> >
>>>>>> > Naturally, we could ask for a roll-call, esp. via user list, but
>>>>>> imagining  a persistent web-list would be of interest.
>>>>>> >
>>>>>> > Cheers,
>>>>>> > Austin
>>>>>> >
>>>>>> >
>>>>>> > P.S.  If putting such a list into our repo, that would also get
>>>>>> some people to submit PRs (so more contributors!) :-)
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>

Re: Interest

[Aizhamal Nurmamat kyzy]

Hi Dule,

Thank you for the introduction and your interest to work on Apache Beam
documentation with Season of Docs. To participate in the program you need
to follow the guides here [1] [2]. If you are new to the program, we
suggest:

   1.

   Start by studying our proposed project ideas and expected deliverables
   for each of them [3].
   2.

   Explore more in depth the existing related Beam documentation for each
   project idea. We provided links to the background material, known issues
   and current documentation for both project ideas [4] [5]. Choose one
   project you like the most.
   3.

   Start drafting a proposal with the gaps you have found and ideas for
   improvement, and how you would present the new/updated/full documentation.
   Here are more tips on how to make your proposal stronger [6]. Please,
   follow the guides and make sure you cover all points.
   4.

   Submit the project proposal to the Google program administrators during
   the technical writer application phase. It opens on June 9, 2020. If you
   want any  feedback for your initial draft, consider using Google Docs and
   share on dev@beam.apache.org, so the community members can leave their
   comments and suggestions (please check the access to the doc before sending
   to the mailing list).

If you have any ideas that you want to brainstorm about, don’t hesitate to
start a discussion in the community list or reach out on Slack channel to
discuss issues related to GSoD documentation [7]. Once you create an
account join #beam-gsod channel.

Project administrators will assess proposals based on these guidelines [8]

Hope it helps. Let us know if you have more questions.

Thanks,

Beam GSoD team


[1] https://developers.google.com/season-of-docs/docs/tech-writer-guide

[2] https://developers.google.com/season-of-docs/terms/tech-writer-terms

[3] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs

[4]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-1.DeploymentofaFlinkandSparkClusterswithPortableBeam

[5]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-2.Updateoftherunnercomparisonpage/capabilitymatrix

[6]
https://developers.google.com/season-of-docs/docs/tech-writer-application-hints

[7]
https://join.slack.com/t/seasonofdocs/shared_invite/enQtNTc0NDgyOTQ5Nzc4LTliZjVlZjRmNmU5ZmFiNmViNmNiMTM5NTdlNTJiYzIzZTk3MDlhMjM3NzE2MzIxNzIxNmZiMmMzNzRmZTI4NmU
[8]
https://developers.google.com/season-of-docs/docs/project-selection#assess-proposal



On Tue, May 26, 2020 at 9:09 AM dule martins 
wrote:

> Hello!
> Trust this mail meets you well, i went through your project idea and found
> interest in the following project idea:
> 2. Update of the runner comparison page / capability matrix
> 
>
>- Project description
>
> 
>- Project deliverables
>
> 
>- Project background
>
> 
>- Related resources:
>
> 
>
> i'm enthusiatic about technical writting with little experince, i work
> with a team and i have been writing for them.
> I publish most of our content on medium, will give my time in seeing that
> all content been given are develop and documented properly.
>
> Will be kind to receive a feedback from you
>
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Hi, Alexey,

Yes, now we can keep updating the website as before. Here is a contributor
guide: https://github.com/apache/beam/blob/master/website/CONTRIBUTE.md

Thanks for checking :)

Aizhamal


On Tue, May 26, 2020 at 8:39 AM Alexey Romanenko 
wrote:

> Thank you to everybody who worked on this migration.
>
> I just wanted to clarify - does it mean, since it’s finished now, we can
> update a website as before?
>
> On 15 May 2020, at 01:33, Aizhamal Nurmamat kyzy 
> wrote:
>
> Thank you Ahmet, Brian, Robert and everyone else who spent time working on
> this. The pull requests are now merged and the website seems to be working
> as expected [1].
>
> One minor issue that I have noticed is that the code blocks have a grey
> background, which makes it less accessible than before. I created a Jira
> issue for this [2], and will follow up to get it fixed. If you notice any
> other issues, please file Jira issues and let me know.
>
> Hope you are all safe,
> Aizhamal
>
> [1] https://beam.apache.org/
> [2] https://issues.apache.org/jira/browse/BEAM-10001
>
> On Thu, May 14, 2020 at 11:25 AM Pablo Estrada  wrote:
>
>> Here's a zipped-up tree from a staged sample of the website:
>> https://drive.google.com/file/d/1LKL936tBJ79jpjvlL5vC5uYYwTHsWXiJ/view?usp=sharing
>>
>> I'd also suggest tagging the commit, so we can find the fist commit later
>> on for reference. I can push the tag after the PR is merged.
>>
>> On Thu, May 14, 2020 at 10:43 AM Ahmet Altay  wrote:
>>
>>>
>>>
>>> On Thu, May 14, 2020 at 9:16 AM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
>>>> Thank you all for reviewing and validating this pull request. I see
>>>> that all tests are passing now, should we merge it?
>>>>
>>>
>>> +1 to merging now.
>>>
>>> Before the merge, please share a link to an archive copy of the old
>>> website. After the merge, please try out the live website see if it is
>>> working as expected.
>>>
>>>
>>>>
>>>> On Wed, May 13, 2020, 5:41 PM Ahmet Altay  wrote:
>>>>
>>>>> Thank you! Let's merge it once tests are done.
>>>>>
>>>>> On Wed, May 13, 2020 at 5:23 PM Robert Bradshaw 
>>>>> wrote:
>>>>>
>>>>>> I took a (non-comprehensive) look at these as well, and didn't see
>>>>>> any issues, so am happy to sign off on this. Thanks Nam, Brian, Ahmet, 
>>>>>> and
>>>>>> everyone else.
>>>>>>
>>>>>> On Wed, May 13, 2020 at 7:58 AM Nam Bui  wrote:
>>>>>>
>>>>>>> Hi Ahmet,
>>>>>>> "Does this mean the internal links (e.g. contribute/team) will
>>>>>>> disappear?"
>>>>>>> Yes, I'd like to get rid of them. And to make sure it won't appear
>>>>>>> to confuse people, I replaced all of the spots using "contribute/team" 
>>>>>>> with
>>>>>>> the external one. Currently, we only have 2 "redirect_to" links which 
>>>>>>> are
>>>>>>> "contribute/team" & "contribute/project/team", so this act won't have 
>>>>>>> any
>>>>>>> affects.
>>>>>>> Also, based on your question, I just added a section in the
>>>>>>> documentation (CONTRIBUTE.md), which mentions the replaced/removed 
>>>>>>> features
>>>>>>> of Jekyll in terms of writing a new blog post or documentation in Hugo.
>>>>>>>
>>>>>>
>>>>> Got it. The main effect will be any one has a bookmark/link to these
>>>>> pages, those links will no longer work. It is fine if it is only limited 
>>>>> to
>>>>> these 2 urls.
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, May 13, 2020 at 4:17 AM Ahmet Altay 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> - I reviewed the diff output with Nam's explanations. The change
>>>>>>>> looks minimal. Large diffs are primarily coming from index and redirect
>>>>>>>> files. codeblocks have differences but the content is seemingly 
>>>>>>>> preserved.
>>>>>>>> IIUC, the source of truth is snippet files anyway. (It would be good 
>>>>>>

Re: [DISCUSS] New process for proposing ApacheBeam tweets

[Aizhamal Nurmamat kyzy]

Sounds good! Let's try it out. I sent one post suggestion via the form,
let's see how the notification goes for people who are subscribed to the
spreadsheet.

I'll create a PR with the description of the new process next week.

On Mon, May 18, 2020 at 10:58 AM Ahmet Altay  wrote:

> I think this is a good idea.
>
> On Fri, May 15, 2020 at 5:50 PM Robert Bradshaw 
> wrote:
>
>> Sounds like a good plan to me, but I haven't been the one monitoring this
>> spreadsheet (or twitter for that matter). Spam is a concern, but
>> everything is moderated so I think we try it out and see if the volume is
>> really high enough to be an issue.
>>
>
> I agree with Robert. Google forms supports form validation. We can
> eliminate most botspam with that. Rest of it can be handled with moderation.
>
>
>>
>> On Fri, May 15, 2020 at 4:46 PM Kenneth Knowles  wrote:
>>
>>> I like having easier notifications. It would be great if the
>>> notifications had the content also. I get notifications on the spreadsheet,
>>> but since I have to click through to look at them there is a little bit of
>>> friction.
>>>
>>> 1. Is it still easy to add the other columns to record LGTM and when
>>> they have been sent?
>>> 2. Risk of spam?
>>>
>>> Kenn
>>>
>>> On Fri, May 15, 2020 at 2:56 PM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I wanted to propose some improvements to the existing process of
>>>> proposing tweets for the Apache Beam Twitter account.
>>>>
>>>> Currently the process requires people to request edit access, and then
>>>> add tweets on the spreadsheet [1]. I use it a lot because I know the
>>>> process well, but I think this may limit newcomers from proposing changes,
>>>> and can make things difficult for them.
>>>> I am proposing to use a Google Form (see example[2]), which will
>>>> populare the same spreadsheet. The advantages of this is that it will be
>>>> open for everyone, and it will be easier to subscribe to notifications
>>>> every time someone adds a new tweet proposal.
>>>>
>>>> The review process by the PMC would remain in place as-is.
>>>>
>>>> What does everyone think?
>>>> Thanks
>>>> Aizhamal
>>>>
>>>> [1] https://s.apache.org/beam-tweets
>>>> [2]
>>>> https://docs.google.com/forms/d/e/1FAIpQLSepI3zVZNmA9RUAzAnhH45IZU48uCt0qmPPYyZOEZCFONQZ6w/viewform
>>>>
>>>

Re: [RESULT][VOTE] Accept the Firefly design donation as Beam Mascot - Deadline Mon April 6

[Aizhamal Nurmamat kyzy]

Hello everyone,
Julian and I have created this pr[1] to create a page with the model sheet,
and links to the mascot image files. Can someone please review?
Thanks!
Aizhamal

[1] https://github.com/apache/beam/pull/11780

On Mon, May 11, 2020 at 10:14 AM Aizhamal Nurmamat kyzy 
wrote:

> @Ismael, this is in my work items for as soon as we complete the migration
> of the website.
> @Kyle, thanks for filing Jira, I assigned it to myself.
>
> On Mon, May 11, 2020 at 10:03 AM Kyle Weaver  wrote:
>
>> > Now that the vote has passed maybe we should add the images somewhere
>> > in the website so people can easily find the Firefly to use it
>>
>> +1 Maybe something to revisit after the website overhaul is complete. I
>> filed https://jira.apache.org/jira/browse/BEAM-9948 if anyone wants to
>> take it.
>>
>> On Mon, May 11, 2020 at 12:57 PM Ismaël Mejía  wrote:
>>
>>> Now that the vote has passed maybe we should add the images somewhere
>>> in the website so people can easily find the Firefly to use it.
>>> Something like what we do with our logos
>>> https://beam.apache.org/community/logos/
>>>
>>> WDYT? any taker?
>>>
>>> On Tue, Apr 28, 2020 at 7:43 PM Pablo Estrada 
>>> wrote:
>>> >
>>> > I'll be happy to as well!
>>> >
>>> > On Sun, Apr 26, 2020 at 4:18 AM Maximilian Michels 
>>> wrote:
>>> >>
>>> >> Hey Maria,
>>> >>
>>> >> I can testify :)
>>> >>
>>> >> Cheers,
>>> >> Max
>>> >>
>>> >> On 23.04.20 20:49, María Cruz wrote:
>>> >> > Hi everyone!
>>> >> > It is amazing to see how this process developed to collaboratively
>>> >> > create Apache Beam's mascot. Thank you to everyone who got involved!
>>> >> > I would like to write a blogpost for the Beam website, and I wanted
>>> to
>>> >> > ask you: would anyone like to offer their testimony about the
>>> process of
>>> >> > creating the Beam mascot, and what this means to you? Everyone's
>>> >> > testimony is welcome! If you witnessed the development of a mascot
>>> for
>>> >> > another open source project, even better =)
>>> >> >
>>> >> > Please feel free to express interest on this thread, and I'll reach
>>> out
>>> >> > to you off-list.
>>> >> >
>>> >> > Thanks,
>>> >> >
>>> >> > María
>>> >> >
>>> >> > On Fri, Apr 17, 2020 at 6:19 AM Jeff Klukas >> >> > <mailto:jklu...@mozilla.com>> wrote:
>>> >> >
>>> >> > I personally like the sound of "Datum" as a name. I also like
>>> the
>>> >> > idea of not assigning them a gender.
>>> >> >
>>> >> > As a counterpoint on the naming side, one of the slide decks
>>> >> > provided while iterating on the design mentions:
>>> >> >
>>> >> > > Mascot can change colors when it is “full of data” or has a
>>> “batch
>>> >> > of data” to process.  Yellow is supercharged and ready to
>>> process!
>>> >> >
>>> >> > Based on that, I'd argue that the mascot maps to the concept of
>>> a
>>> >> > bundle in the beam execution model and we should consider a name
>>> >> > that's a play on "bundle" or perhaps a play on "checkpoint".
>>> >> >
>>> >> > On Thu, Apr 16, 2020 at 3:44 PM Julian Bruno <
>>> juliangbr...@gmail.com
>>> >> > <mailto:juliangbr...@gmail.com>> wrote:
>>> >> >
>>> >> > Hi all,
>>> >> >
>>> >> > While working on the design of our Mascot
>>> >> > Some ideas showed up and I wish to share them.
>>> >> > In regard to Alex Van Boxel's question about the name of
>>> our Mascot.
>>> >> >
>>> >> > I was thinking about this yesterday night and feel it could
>>> be a
>>> >> > great idea to name the Mascot "*Data*" or "*Datum*". Both
>>> names
>>> >> > sound cute and make sense to me. I prefer the later. Datum
>>> means

Re: Wishing to contribute. Can I get access to JIRA to assign myself issues?

[Aizhamal Nurmamat kyzy]

Welcome, Brent!

On Wed, May 13, 2020, 6:39 PM Luke Cwik  wrote:

> Welcome, I have added you as a contributor.
>
> The Apache Beam contribution guide[1] has a lot of helpful links including
> a link to some starter tasks[2].
>
> 1: https://beam.apache.org/contribute/
> 2: https://s.apache.org/beam-starter-tasks
>
> On Wed, May 13, 2020 at 5:56 PM Brent Worden 
> wrote:
>
>> All,
>>
>> I was planning to spend some free time contributing where and when I
>> can.  I plan to start with simple website changes and work up from there.
>>
>> I'm a current ASF member with username brentworden.  Can I get access to
>> Beam's JIRA project so I can assign myself issues?
>>
>> Thanks,
>>
>> Brent
>>
>

Re: Google Season of Docs

[Aizhamal Nurmamat kyzy]

Hi,


Thank you for the introduction and your interest to work on Apache Beam
documentation with Season of Docs. To participate in the program you need
to follow the guides here [1] [2]. If you are new to the program, we
suggest:

   1.

   Start by studying our proposed project ideas and expected deliverables
   for each of them [3].
   2.

   Explore more in depth the existing related Beam documentation for each
   project idea. We provided links to the background material, known issues
   and current documentation for both project ideas [4] [5]. Choose one
   project you like the most.
   3.

   Start drafting a proposal with the gaps you have found and ideas for
   improvement, and how you would present the new/updated/full documentation.
   Here are more tips on how to make your proposal stronger [6]. Please,
   follow the guides and make sure you cover all points.
   4.

   Submit the project proposal to the Google program administrators during
   the technical writer application phase. It opens on June 9, 2020. If you
   want any  feedback for your initial draft, consider using Google Docs and
   share on dev@beam.apache.org, so the community members can leave their
   comments and suggestions (please check the access to the doc before sending
   to the mailing list).

If you have any ideas that you want to brainstorm about, don’t hesitate to
start a discussion in the community list or reach out on Slack channel to
discuss issues related to GSoD documentation [7]. Once you create an
account join #beam-gsod channel.

Project administrators will assess proposals based on these guidelines [8]

Hope it helps. Let us know if you have more questions.

Thanks,

Beam GSoD team

[1] https://developers.google.com/season-of-docs/docs/tech-writer-guide

[2] https://developers.google.com/season-of-docs/terms/tech-writer-terms

[3] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs

[4]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-1.DeploymentofaFlinkandSparkClusterswithPortableBeam

[5]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-2.Updateoftherunnercomparisonpage/capabilitymatrix

[6]
https://developers.google.com/season-of-docs/docs/tech-writer-application-hints

[7] https://join.slack.com/share/zt-eaml657m-KMamnNZfRF2BB7eQpmvveg

[8]
https://developers.google.com/season-of-docs/docs/project-selection#assess-proposal



On Thu, May 14, 2020, 10:14 AM Shalini Mukhopadhyay <
mukhopadhyayshali...@gmail.com> wrote:

> Respected sir/madam
> I want to apply with your org for the Google Season of Docs. Here's my CV:
> Can we talk about your ideas please?thanks
>
>
>
> [image: Mailtrack]
> 
>  Sender
> notified by
> Mailtrack
> 
>  14/05/20,
> 12:39:06
>

Re: Regarding Google Season of Docs

[Aizhamal Nurmamat kyzy]

Hi Arun,


Thank you for the introduction and your interest to work on Apache Beam
documentation with Season of Docs. To participate in the program you need
to follow the guides here [1] [2]. If you are new to the program, we
suggest:

   1.

   Start by studying our proposed project ideas and expected deliverables
   for each of them [3].
   2.

   Explore more in depth the existing related Beam documentation for each
   project idea. We provided links to the background material, known issues
   and current documentation for both project ideas [4] [5]. Choose one
   project you like the most.
   3.

   Start drafting a proposal with the gaps you have found and ideas for
   improvement, and how you would present the new/updated/full documentation.
   Here are more tips on how to make your proposal stronger [6]. Please,
   follow the guides and make sure you cover all points.
   4.

   Submit the project proposal to the Google program administrators during
   the technical writer application phase. It opens on June 9, 2020. If you
   want any  feedback for your initial draft, consider using Google Docs and
   share on dev@beam.apache.org, so the community members can leave their
   comments and suggestions (please check the access to the doc before sending
   to the mailing list).

If you have any ideas that you want to brainstorm about, don’t hesitate to
start a discussion in the community list or reach out on Slack channel to
discuss issues related to GSoD documentation [7]. Once you create an
account join #beam-gsod channel.

Project administrators will assess proposals based on these guidelines [8]

Hope it helps. Let us know if you have more questions.

Thanks,

Beam GSoD team

[1] https://developers.google.com/season-of-docs/docs/tech-writer-guide

[2] https://developers.google.com/season-of-docs/terms/tech-writer-terms

[3] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs

[4]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-1.DeploymentofaFlinkandSparkClusterswithPortableBeam

[5]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-2.Updateoftherunnercomparisonpage/capabilitymatrix

[6]
https://developers.google.com/season-of-docs/docs/tech-writer-application-hints

[7] https://join.slack.com/share/zt-eaml657m-KMamnNZfRF2BB7eQpmvveg

[8]
https://developers.google.com/season-of-docs/docs/project-selection#assess-proposal


On Thu, May 14, 2020, 10:22 AM Arun Prakash  wrote:

> Hi,
>
> Greetings!
>
> I am an MSc Computer Science Student at the Chalmers University of
> Technology, Sweden! I would love to be a participant in Google Season of
> Docs 2020. I have explored a lot about Apache Beam. I was part of the GSoC
> Community to Implement a Hazlecast Portable Runner Support to Apache Beam
> but last minute, the project was called off . But I never felt that the
> invested hours are of vain, I loved the product! Now I want to contribute
> making a doc for this awesome community. Could you please guide me further?
>
> Following is the proposal I submitted for GSoC 2020
>
>
> https://drive.google.com/file/d/1TJF6j3LoN5kB7rKB3yakBSpTozEajwoI/view?usp=sharing
>
> Thank You !
>
>
> Regards,
> Arun Prakash Jothimani,
> Msc Computer Science Student,
> Chalmers University Of Technology, Sweden.
> http://in.linkedin.com/pub/arunprakash-jothimani/24/aa2/924
>

Re: Interested in applying to GSoD project

[Aizhamal Nurmamat kyzy]

Hi Deepak,


Thank you for the introduction and your interest to work on Apache Beam
documentation with Season of Docs. To participate in the program you need
to follow the guides here [1] [2]. If you are new to the program, we
suggest:

   1.

   Start by studying our proposed project ideas and expected deliverables
   for each of them [3].
   2.

   Explore more in depth the existing related Beam documentation for each
   project idea. We provided links to the background material, known issues
   and current documentation for both project ideas [4] [5]. Choose one
   project you like the most.
   3.

   Start drafting a proposal with the gaps you have found and ideas for
   improvement, and how you would present the new/updated/full documentation.
   Here are more tips on how to make your proposal stronger [6]. Please,
   follow the guides and make sure you cover all points.
   4.

   Submit the project proposal to the Google program administrators during
   the technical writer application phase. It opens on June 9, 2020. If you
   want any  feedback for your initial draft, consider using Google Docs and
   share on dev@beam.apache.org, so the community members can leave their
   comments and suggestions (please check the access to the doc before sending
   to the mailing list).

If you have any ideas that you want to brainstorm about, don’t hesitate to
start a discussion in the community list or reach out on Slack channel to
discuss issues related to GSoD documentation [7]. Once you create an
account join #beam-gsod channel.

Project administrators will assess proposals based on these guidelines [8]

Hope it helps. Let us know if you have more questions.

Thanks,

Beam GSoD team

[1] https://developers.google.com/season-of-docs/docs/tech-writer-guide

[2] https://developers.google.com/season-of-docs/terms/tech-writer-terms

[3] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs

[4]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-1.DeploymentofaFlinkandSparkClusterswithPortableBeam

[5]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-2.Updateoftherunnercomparisonpage/capabilitymatrix

[6]
https://developers.google.com/season-of-docs/docs/tech-writer-application-hints

[7] https://join.slack.com/share/zt-eaml657m-KMamnNZfRF2BB7eQpmvveg

[8]
https://developers.google.com/season-of-docs/docs/project-selection#assess-proposal



On Thu, May 14, 2020, 2:46 PM Deepak Vohra  wrote:

> Aizhamal,
>
> I am interested in applying as a technical writer to the Apache Beam
> project in Google Season of Docs. In the project exploration phase I would
> like to introduce myself as a potential applicant (when the application
> opens). I have experience using several data processing frameworks and have
> published dozens of articles and a few books on the same. Some books on
> similar topics :
>
> 1.Practical Hadoop Ecosystem
>
> https://www.amazon.com/gp/product/B01M0NAHU3/ref=dbs_a_def_rwt_hsch_vapi_tkin_p1_i5
>
> 2. Apache HBase Primer
> https://www.amazon.com/gp/product/B01MTOSTAB/ref=dbs_a_def_rwt_bibl_vppi_i1
>
> I have also published 3 other books on Kubernetes; Kubernetes being a
> commonly used deployment platform for Apache Beam.
>
> Please let me know about any   potential topics other than those already
> listed and what I could do to get started.
>
> regards,
> Deepak
>
>
>
>

Re: regarding Google Season of Docs

[Aizhamal Nurmamat kyzy]

Hi Yuvraj,
Thank you for the introduction and your interest to work on Apache Beam
documentation with Season of Docs. To participate in the program you need
to follow the guides here [1] [2]. If you are new to the program, we
suggest:

   1.

   Start by studying our proposed project ideas and expected deliverables
   for each of them [3].
   2.

   Explore more in depth the existing related Beam documentation for each
   project idea. We provided links to the background material, known issues
   and current documentation for both project ideas [4] [5]. Choose one
   project you like the most.
   3.

   Start drafting a proposal with the gaps you have found and ideas for
   improvement, and how you would present the new/updated/full documentation.
   Here are more tips on how to make your proposal stronger [6]. Please,
   follow the guides and make sure you cover all points.
   4.

   Submit the project proposal to the Google program administrators during
   the technical writer application phase. It opens on June 9, 2020. If you
   want any  feedback for your initial draft, consider using Google Docs and
   share on dev@beam.apache.org, so the community members can leave their
   comments and suggestions (please check the access to the doc before sending
   to the mailing list).

If you have any ideas that you want to brainstorm about, don’t hesitate to
start a discussion in the community list or reach out on Slack channel to
discuss issues related to GSoD documentation [7]. Once you create an
account join #beam-gsod channel.

Project administrators will assess proposals based on these guidelines [8]

Hope it helps. Let us know if you have more questions.

Thanks,

Beam GSoD team

[1] https://developers.google.com/season-of-docs/docs/tech-writer-guide

[2] https://developers.google.com/season-of-docs/terms/tech-writer-terms

[3] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs

[4]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-1.DeploymentofaFlinkandSparkClusterswithPortableBeam

[5]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-2.Updateoftherunnercomparisonpage/capabilitymatrix

[6]
https://developers.google.com/season-of-docs/docs/tech-writer-application-hints

[7] https://join.slack.com/share/zt-eaml657m-KMamnNZfRF2BB7eQpmvveg

[8]
https://developers.google.com/season-of-docs/docs/project-selection#assess-proposal



On Fri, May 15, 2020, 10:29 AM Yuvraj Manral 
wrote:

> Respected sir/mam,
>
> I came around the projects proposed by Apache Beam for Season of Docs 2020.
> I am a newbie to organisation but really liked the ideas of projects and
> would love to start contributing and prepare my proposal for Season of Docs.
>
> Please guide me through. Where should I start and then proceed ?
> Thanking you in anticipation
>
> Yuvraj Manral 
> RSVP
>

Re: Google Season of Docs

[Aizhamal Nurmamat kyzy]

Hi Amr,


Thank you for the introduction and your interest to work on Apache Beam
documentation with Season of Docs. To participate in the program you need
to follow the guides here [1] [2]. If you are new to the program, we
suggest:

   1.

   Start by studying our proposed project ideas and expected deliverables
   for each of them [3].
   2.

   Explore more in depth the existing related Beam documentation for each
   project idea. We provided links to the background material, known issues
   and current documentation for both project ideas [4] [5]. Choose one
   project you like the most.
   3.

   Start drafting a proposal with the gaps you have found and ideas for
   improvement, and how you would present the new/updated/full documentation.
   Here are more tips on how to make your proposal stronger [6]. Please,
   follow the guides and make sure you cover all points.
   4.

   Submit the project proposal to the Google program administrators during
   the technical writer application phase. It opens on June 9, 2020. If you
   want any  feedback for your initial draft, consider using Google Docs and
   share on dev@beam.apache.org, so the community members can leave their
   comments and suggestions (please check the access to the doc before sending
   to the mailing list).

If you have any ideas that you want to brainstorm about, don’t hesitate to
start a discussion in the community list or reach out on Slack channel to
discuss issues related to GSoD documentation [7]. Once you create an
account join #beam-gsod channel.

Project administrators will assess proposals based on these guidelines [8]

Hope it helps. Let us know if you have more questions.

Thanks,

Beam GSoD team

[1] https://developers.google.com/season-of-docs/docs/tech-writer-guide

[2] https://developers.google.com/season-of-docs/terms/tech-writer-terms

[3] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs

[4]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-1.DeploymentofaFlinkandSparkClusterswithPortableBeam

[5]
https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs#GoogleSeasonofDocs-2.Updateoftherunnercomparisonpage/capabilitymatrix

[6]
https://developers.google.com/season-of-docs/docs/tech-writer-application-hints

[7] https://join.slack.com/share/zt-eaml657m-KMamnNZfRF2BB7eQpmvveg

[8]
https://developers.google.com/season-of-docs/docs/project-selection#assess-proposal


On Fri, May 15, 2020, 9:31 AM Amr Maghraby  wrote:

> Dear Apace,
> My name is Amr Maghraby, I am a new graduate from AAST college got the
> first rank on my class with CGPA 3.92 and joined the international
> competition in the US called ROV got the second worldwide and last summer I
> have involved in Google Summer of code 2019 and did good work also, I
> participated in problem-solving competitions ACM ACPC and Hash Code. I was
> asking if I could apply for GSOD?
> Waiting for your reply.
> Thanks,
> Amr Maghraby
>
>

Re: [ANNOUNCE] New committer: Robin Qiu

[Aizhamal Nurmamat kyzy]

Congratulations, Robin! Thank you for your contributions!

On Mon, May 18, 2020, 7:18 PM Boyuan Zhang  wrote:

> Congrats~~
>
> On Mon, May 18, 2020 at 7:17 PM Reza Rokni  wrote:
>
>> Congratulations!
>>
>> On Tue, May 19, 2020 at 10:06 AM Ahmet Altay  wrote:
>>
>>> Hi everyone,
>>>
>>> Please join me and the rest of the Beam PMC in welcoming a new committer:
>>> Robin Qiu .
>>>
>>> Robin has been active in the community for close to 2 years, worked
>>> on HyperLogLog++ [1], SQL [2], improved documentation, and helped with
>>> releases(*).
>>>
>>> In consideration of his contributions, the Beam PMC trusts him with the
>>> responsibilities of a Beam committer [3].
>>>
>>> Thank you for your contributions Robin!
>>>
>>> -Ahmet, on behalf of the Apache Beam PMC
>>>
>>> [1] https://www.meetup.com/Zurich-Apache-Beam-Meetup/events/265529665/
>>> [2] https://www.meetup.com/Belgium-Apache-Beam-Meetup/events/264933301/
>>> [3] https://beam.apache.org/contribute/become-a-committer
>>> /#an-apache-beam-committer
>>> (*) And maybe he will be a release manager soon :)
>>>
>>>

Re: Apache Beam application to Season of Docs 2020

[Aizhamal Nurmamat kyzy]

@all

We are receiving a few emails from interested applicants - feel no pressure
to respond to them. I will be monitoring the dev list and respond
accordingly. If they have specific questions regarding either of the
projects, I will direct them to the mentors.

Stay safe,
Aizhamal

On Mon, May 11, 2020 at 6:55 PM Pablo Estrada  wrote:

> I'll be happy to mentor for improvements to the Capability Matrix. There
> had been some discussions about that earlier.
> +Kenneth Knowles  +Robert Bradshaw  
> +Thomas
> Weise   I may set a quick meeting with each of you to get
> your thoughts about Capability Matrix improvements. (also happy to welcome
> an extra mentor if you feel up to it : ))
>
> On Mon, May 11, 2020 at 5:16 PM Kyle Weaver  wrote:
>
>> Cool! I signed up as a mentor.
>>
>> On Mon, May 11, 2020 at 4:56 PM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> PS: I am registered as a mentor too, happy to onboard the tech
>>> writers to The Apache Way and Beam community processes when time comes.
>>>
>>> On Mon, May 11, 2020 at 1:52 PM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
>>>> Apache Beam got accepted into Season of Docs, yay! [1]
>>>>
>>>> @Kyle/Pablo, could you please fill out the mentor registration form by
>>>> tomorrow morning [2]?
>>>>
>>>> Is there anyone else interested in becoming a mentor for either
>>>> of the 2 projects [3]? The program requires at least two open source
>>>> mentors for each technical writer in case we get 2.
>>>>
>>>> [1] https://developers.google.com/season-of-docs/docs/participants/
>>>> [2]
>>>> https://docs.google.com/forms/d/e/1FAIpQLSfMZ3yCf24PFUbvpSOkVy4sZUJFY5oS7HbGyXTNXzFg2btp4Q/viewform
>>>> [3]
>>>> https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs
>>>>
>>>>
>>>> On Tue, May 5, 2020 at 5:31 PM Pablo Estrada 
>>>> wrote:
>>>>
>>>>> I think I am willing to help with Project 2.
>>>>>
>>>>> On Tue, May 5, 2020 at 2:01 PM Aizhamal Nurmamat kyzy <
>>>>> aizha...@apache.org> wrote:
>>>>>
>>>>>> Thank you, Kyle! really appreciate it! I will add you as a mentor
>>>>>> into the cwiki page, and let you know if Beam gets accepted to the 
>>>>>> program
>>>>>> on May 11th.
>>>>>>
>>>>>> On Tue, May 5, 2020 at 12:55 PM Kyle Weaver 
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks Aizhamal! I would be willing to help with project 1.
>>>>>>>
>>>>>>> On Mon, May 4, 2020 at 5:04 PM Aizhamal Nurmamat kyzy <
>>>>>>> aizha...@apache.org> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I have submitted the application to the Season of Docs program with
>>>>>>>> the project ideas we have developed last year [1]. I learnt about its
>>>>>>>> deadline a few hours ago and didn't want to miss it.
>>>>>>>>
>>>>>>>> Feel free to add more project ideas (or edit the current ones)
>>>>>>>> until May 7th.
>>>>>>>>
>>>>>>>> If Beam gets approved, we will get 1 or 2 experienced technical
>>>>>>>> writers to help us document community processes or some Beam features. 
>>>>>>>> Is
>>>>>>>> anyone else willing to mentor for these projects?
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs
>>>>>>>>
>>>>>>>

[DISCUSS] New process for proposing ApacheBeam tweets

[Aizhamal Nurmamat kyzy]

Hi all,

I wanted to propose some improvements to the existing process of proposing
tweets for the Apache Beam Twitter account.

Currently the process requires people to request edit access, and then add
tweets on the spreadsheet [1]. I use it a lot because I know the process
well, but I think this may limit newcomers from proposing changes, and can
make things difficult for them.
I am proposing to use a Google Form (see example[2]), which will populare
the same spreadsheet. The advantages of this is that it will be open for
everyone, and it will be easier to subscribe to notifications every time
someone adds a new tweet proposal.

The review process by the PMC would remain in place as-is.

What does everyone think?
Thanks
Aizhamal

[1] https://s.apache.org/beam-tweets
[2]
https://docs.google.com/forms/d/e/1FAIpQLSepI3zVZNmA9RUAzAnhH45IZU48uCt0qmPPYyZOEZCFONQZ6w/viewform

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Thank you Ahmet, Brian, Robert and everyone else who spent time working on
this. The pull requests are now merged and the website seems to be working
as expected [1].

One minor issue that I have noticed is that the code blocks have a grey
background, which makes it less accessible than before. I created a Jira
issue for this [2], and will follow up to get it fixed. If you notice any
other issues, please file Jira issues and let me know.

Hope you are all safe,
Aizhamal

[1] https://beam.apache.org/
[2] https://issues.apache.org/jira/browse/BEAM-10001

On Thu, May 14, 2020 at 11:25 AM Pablo Estrada  wrote:

> Here's a zipped-up tree from a staged sample of the website:
> https://drive.google.com/file/d/1LKL936tBJ79jpjvlL5vC5uYYwTHsWXiJ/view?usp=sharing
>
> I'd also suggest tagging the commit, so we can find the fist commit later
> on for reference. I can push the tag after the PR is merged.
>
> On Thu, May 14, 2020 at 10:43 AM Ahmet Altay  wrote:
>
>>
>>
>> On Thu, May 14, 2020 at 9:16 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Thank you all for reviewing and validating this pull request. I see that
>>> all tests are passing now, should we merge it?
>>>
>>
>> +1 to merging now.
>>
>> Before the merge, please share a link to an archive copy of the old
>> website. After the merge, please try out the live website see if it is
>> working as expected.
>>
>>
>>>
>>> On Wed, May 13, 2020, 5:41 PM Ahmet Altay  wrote:
>>>
>>>> Thank you! Let's merge it once tests are done.
>>>>
>>>> On Wed, May 13, 2020 at 5:23 PM Robert Bradshaw 
>>>> wrote:
>>>>
>>>>> I took a (non-comprehensive) look at these as well, and didn't see any
>>>>> issues, so am happy to sign off on this. Thanks Nam, Brian, Ahmet, and
>>>>> everyone else.
>>>>>
>>>>> On Wed, May 13, 2020 at 7:58 AM Nam Bui  wrote:
>>>>>
>>>>>> Hi Ahmet,
>>>>>> "Does this mean the internal links (e.g. contribute/team) will
>>>>>> disappear?"
>>>>>> Yes, I'd like to get rid of them. And to make sure it won't appear to
>>>>>> confuse people, I replaced all of the spots using "contribute/team" with
>>>>>> the external one. Currently, we only have 2 "redirect_to" links which are
>>>>>> "contribute/team" & "contribute/project/team", so this act won't have any
>>>>>> affects.
>>>>>> Also, based on your question, I just added a section in the
>>>>>> documentation (CONTRIBUTE.md), which mentions the replaced/removed 
>>>>>> features
>>>>>> of Jekyll in terms of writing a new blog post or documentation in Hugo.
>>>>>>
>>>>>
>>>> Got it. The main effect will be any one has a bookmark/link to these
>>>> pages, those links will no longer work. It is fine if it is only limited to
>>>> these 2 urls.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> On Wed, May 13, 2020 at 4:17 AM Ahmet Altay  wrote:
>>>>>>
>>>>>>> - I reviewed the diff output with Nam's explanations. The change
>>>>>>> looks minimal. Large diffs are primarily coming from index and redirect
>>>>>>> files. codeblocks have differences but the content is seemingly 
>>>>>>> preserved.
>>>>>>> IIUC, the source of truth is snippet files anyway. (It would be good to 
>>>>>>> get
>>>>>>> one more set of eyes on this.)
>>>>>>> - Brian and I reviewed the infrastructure changes. They look
>>>>>>> reasonable.
>>>>>>>
>>>>>>> I think PR is very close to a mergeable state. Especially if we can
>>>>>>> get an archive copy of the current website, I will be comfortable with 
>>>>>>> the
>>>>>>> merge.
>>>>>>>
>>>>>>> And, thank you Nam for your work so far.
>>>>>>>
>>>>>>> On Tue, May 12, 2020 at 4:13 PM Nam Bui  wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> A new commit covers Robert's script is pushed [1], and also the
>>>>>>>> script output is attached in this email.
>>>>>>>>
>>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

.html (mentioned in “redirect_to” below)
>>>>>
>>>>> - “redirect_to”:
>>>>> In Jekyll, there is a feature called “redirect_to”. For instance, you
>>>>> click on an internal link “contribute/team/” to reach the markdown
>>>>> “team.md”, then from the markdown file, it redirects you to the external
>>>>> URL “https://example.com”.
>>>>> However, there is no such feature in Hugo. My solution is to directly
>>>>> replace “contribute/team/” with “https://example.com”.
>>>>>
>>>>
>>>> Does this mean the internal links (e.g. contribute/team) will disappear?
>>>>
>>>>
>>>>>
>>>>> [1] https://github.com/apache/beam/pull/11554
>>>>>
>>>>> On Mon, May 11, 2020 at 7:34 PM Nam Bui  wrote:
>>>>>
>>>>>> Updates for today:
>>>>>> - Thanks Brian & Ahmet for your reviews. I left my comments for some
>>>>>> of the questions and also adapted new changes to the reviews [1].
>>>>>> - I see that the new blog post was merged yesterday, so I added it to
>>>>>> the PR as well.
>>>>>>
>>>>>> I briefly tried the script from Robert with the input of build files
>>>>>> from old and new websites. It seemed to work well in terms of detecting
>>>>>> missing files (or probably wrong links leading to missing files). I will
>>>>>> push another commit to fix all that up, hope can be tomorrow.
>>>>>>
>>>>>> [1] https://github.com/apache/beam/pull/11554#issuecomment-626792031
>>>>>>
>>>>>> Best regards,
>>>>>> Nam
>>>>>>
>>>>>>
>>>>>> On Mon, May 11, 2020 at 9:01 AM Nam Bui  wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> @Ahmet: Yeah, it's all clear to me. :)
>>>>>>> @Robert: Thanks for your ideas and also the script. It really helps
>>>>>>> me to serve my works.
>>>>>>>
>>>>>>> Best regard!
>>>>>>>
>>>>>>> On Sat, May 9, 2020 at 2:10 AM Ahmet Altay  wrote:
>>>>>>>
>>>>>>>> This sounds reasonable to me. Thank you. Nam, does it make sense to
>>>>>>>> you?
>>>>>>>>
>>>>>>>> On Fri, May 8, 2020 at 11:53 AM Robert Bradshaw <
>>>>>>>> rober...@google.com> wrote:
>>>>>>>>
>>>>>>>>> I'd really like to not see this work go to waste, both the
>>>>>>>>> original revision, the further efforts Nam has done in making it more
>>>>>>>>> manageable to review, and the work put into reviewing this so far, so 
>>>>>>>>> we
>>>>>>>>> can get the benefits of being on Hugo. How about this for a
>>>>>>>>> concrete proposal:
>>>>>>>>>
>>>>>>>>> (1) We get "standard" approval from one or more committers for the
>>>>>>>>> infrastructure changes, just as with any other PR. Brian has
>>>>>>>>> already started this, but if others could step up as well that'd be 
>>>>>>>>> great.
>>>>>>>>>
>>>>>>>>> (2) Reviewers (and authors) typically count on (or request)
>>>>>>>>> sufficient automated test coverage to augment the fact that their 
>>>>>>>>> eyeballs
>>>>>>>>> are fallible, which is something that is missing here (and given the 
>>>>>>>>> size
>>>>>>>>> of the change not easily compensated for by a more detailed manual 
>>>>>>>>> review).
>>>>>>>>> How about we use the script above (or similar) as an automated test to
>>>>>>>>> validate the website's contents haven't (materially) changed. I feel 
>>>>>>>>> we've
>>>>>>>>> validated enough that the style looks good via spot checking (which is
>>>>>>>>> something that should work on all pages if it works on one). The diff
>>>>>>>>> between the current site and the newly generated site should be empty 
>>>>>

Re: Season of Docs - Apache Beam

[Aizhamal Nurmamat kyzy]

Hi Mandar!

Thank you for the introduction and your interest to work on Apache Beam
documentation with Season of Docs! We can't wait to see your application
come through to work on 'Deployment of a Flink and Spark Clusters with
Portable Beam' documentation.

If you have any questions, feel free to reply on this thread, or you can
reach out to the registered mentors via Slack channel [1]. If you have
trouble joining the slack channel, you can request an invite here[2].

[1] https://join.slack.com/share/zt-eaml657m-KMamnNZfRF2BB7eQpmvveg
[2] https://s.apache.org/slack-invite

On Tue, May 12, 2020 at 5:14 PM MANDAR DESHPANDE  wrote:

> Dear Pablo and Aizhamal,
>
> I am a graduate student at UCLA currently pursuing my Masters in ECE with
> a focus on computer vision and machine learning. I have been an avid
> open-source contributor to organisations like Scilab, Gensim and TensorFlow.
>
> In 2017, as a part of Google Summer of Code I created a Machine Learning
> toolbox for Scilab by a Jupyter kernel integration in their CLI> The
> project got successful and I was invited to Mentor its development in 2018.
> We further integrated it with AWS and GCP to create a remote ML learning
> toolbox. Working on similarity learning research at Gensim as a Mentor for
> GSoC also helped me bolster my understanding of open-source mentoring and
> development.
> I worked as a ML Engineer at Citibank from 2017-2019 where we extensively
> used python libraries like numpy, pandas and TensorFlow. While continuing
> my full time employment, I worked as a GSoC Mentor for TensorFlow in 2019
> and will be mentoring projects for library migration to TF2.0 in 2020
> summer as well.
>
> I understand how important documentation is for open source projects,
> especially projects like Apache Beam with its massive scale or usage and
> support across various industries now. I am a fluent English speaker and
> have published multiple blogs with illustrations explaining the data
> science pipelines. You can read more about my technical writing here -
> https://medium.com/@razzormandar and https://mandroid6.github.io/archive/.
>
> I am specifically interested in Deployment of a Flink and Spark Clusters
> with Portable Beam project, as I have hands-on experience of working with
> GCP and AWS.. Being a developer and technical writer myself, I see this as
> an huge opportunity for me to grow in the role and contribute to the
> exciting work Apache Beam is doing in pipeline execution.
>
> I have attached my resume for your reference.
>
> Excited to discuss further with you!
>
> Regards,
> Mandar Deshpande
>
>

Re: GSoD with Apache Beam

[Aizhamal Nurmamat kyzy]

Hi Sylvia,

As Ahmet mentioned, you may start by exploring the 2 project ideas that we
shared [1], and see which one you like better. On the same page, you will
find links to the old/related documentation that we are looking forward to
update/improve with tech writers' help. We also specified the set of
deliverables that we expect from technical writers for each project. If you
are very new to Apache Beam, this programming guide can be also helpful to
understand the key concepts[2].

When the application period for technical writers opens on June 9, you can
submit your proposal with a detailed outline of how you would document
either of the two project ideas. Mentors will assess proposals based on
these guidelines [3]. I also created a slack channel for quick questions if
you further questions [4]. If you have trouble joining the slack channel,
you can request an invite here[5].


[1] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs
[2] https://beam.apache.org/documentation/programming-guide/
[3]
https://developers.google.com/season-of-docs/docs/project-selection#assess-proposal

[4] https://join.slack.com/share/zt-eaml657m-KMamnNZfRF2BB7eQpmvveg
[5] https://s.apache.org/slack-invite

On Tue, May 12, 2020 at 11:09 AM Ahmet Altay  wrote:

> Welcome.
>
> There was this list of projects (
> https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs)
> if that helps. +Aizhamal Nurmamat kyzy  could
> probably point you in the right direction.
>
> Ahmet
>
> On Tue, May 12, 2020 at 1:30 AM Sylvia Mittal 
> wrote:
>
>> Hey,
>>
>> I am Sylvia, a final year Computer Science student at the Indian
>> Institute Of Technology, Mandi. I am interested in applying for GSoD with
>> Apache Beam. I found the projects very interesting and useful. I would be
>> very happy to contribute to the organization with the technical
>> documentation.
>>
>> I request you to please tell me where to get started with the work. Any
>> kind of help or suggestion is welcome.
>>
>> Thanks and Regards
>> Sylvia
>>
>

Re: Apache Beam application to Season of Docs 2020

[Aizhamal Nurmamat kyzy]

PS: I am registered as a mentor too, happy to onboard the tech writers to
The Apache Way and Beam community processes when time comes.

On Mon, May 11, 2020 at 1:52 PM Aizhamal Nurmamat kyzy 
wrote:

> Apache Beam got accepted into Season of Docs, yay! [1]
>
> @Kyle/Pablo, could you please fill out the mentor registration form by
> tomorrow morning [2]?
>
> Is there anyone else interested in becoming a mentor for either of the 2
> projects [3]? The program requires at least two open source mentors for
> each technical writer in case we get 2.
>
> [1] https://developers.google.com/season-of-docs/docs/participants/
> [2]
> https://docs.google.com/forms/d/e/1FAIpQLSfMZ3yCf24PFUbvpSOkVy4sZUJFY5oS7HbGyXTNXzFg2btp4Q/viewform
> [3] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs
>
>
> On Tue, May 5, 2020 at 5:31 PM Pablo Estrada  wrote:
>
>> I think I am willing to help with Project 2.
>>
>> On Tue, May 5, 2020 at 2:01 PM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Thank you, Kyle! really appreciate it! I will add you as a mentor into
>>> the cwiki page, and let you know if Beam gets accepted to the program on
>>> May 11th.
>>>
>>> On Tue, May 5, 2020 at 12:55 PM Kyle Weaver  wrote:
>>>
>>>> Thanks Aizhamal! I would be willing to help with project 1.
>>>>
>>>> On Mon, May 4, 2020 at 5:04 PM Aizhamal Nurmamat kyzy <
>>>> aizha...@apache.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have submitted the application to the Season of Docs program with
>>>>> the project ideas we have developed last year [1]. I learnt about its
>>>>> deadline a few hours ago and didn't want to miss it.
>>>>>
>>>>> Feel free to add more project ideas (or edit the current ones) until
>>>>> May 7th.
>>>>>
>>>>> If Beam gets approved, we will get 1 or 2 experienced technical
>>>>> writers to help us document community processes or some Beam features. Is
>>>>> anyone else willing to mentor for these projects?
>>>>>
>>>>> [1]
>>>>> https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs
>>>>>
>>>>

Re: Apache Beam application to Season of Docs 2020

[Aizhamal Nurmamat kyzy]

Apache Beam got accepted into Season of Docs, yay! [1]

@Kyle/Pablo, could you please fill out the mentor registration form by
tomorrow morning [2]?

Is there anyone else interested in becoming a mentor for either of the 2
projects [3]? The program requires at least two open source mentors for
each technical writer in case we get 2.

[1] https://developers.google.com/season-of-docs/docs/participants/
[2]
https://docs.google.com/forms/d/e/1FAIpQLSfMZ3yCf24PFUbvpSOkVy4sZUJFY5oS7HbGyXTNXzFg2btp4Q/viewform
[3] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs


On Tue, May 5, 2020 at 5:31 PM Pablo Estrada  wrote:

> I think I am willing to help with Project 2.
>
> On Tue, May 5, 2020 at 2:01 PM Aizhamal Nurmamat kyzy 
> wrote:
>
>> Thank you, Kyle! really appreciate it! I will add you as a mentor into
>> the cwiki page, and let you know if Beam gets accepted to the program on
>> May 11th.
>>
>> On Tue, May 5, 2020 at 12:55 PM Kyle Weaver  wrote:
>>
>>> Thanks Aizhamal! I would be willing to help with project 1.
>>>
>>> On Mon, May 4, 2020 at 5:04 PM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have submitted the application to the Season of Docs program with the
>>>> project ideas we have developed last year [1]. I learnt about its deadline
>>>> a few hours ago and didn't want to miss it.
>>>>
>>>> Feel free to add more project ideas (or edit the current ones) until
>>>> May 7th.
>>>>
>>>> If Beam gets approved, we will get 1 or 2 experienced technical writers
>>>> to help us document community processes or some Beam features. Is anyone
>>>> else willing to mentor for these projects?
>>>>
>>>> [1]
>>>> https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs
>>>>
>>>

Re: [RESULT][VOTE] Accept the Firefly design donation as Beam Mascot - Deadline Mon April 6

[Aizhamal Nurmamat kyzy]

@Ismael, this is in my work items for as soon as we complete the migration
of the website.
@Kyle, thanks for filing Jira, I assigned it to myself.

On Mon, May 11, 2020 at 10:03 AM Kyle Weaver  wrote:

> > Now that the vote has passed maybe we should add the images somewhere
> > in the website so people can easily find the Firefly to use it
>
> +1 Maybe something to revisit after the website overhaul is complete. I
> filed https://jira.apache.org/jira/browse/BEAM-9948 if anyone wants to
> take it.
>
> On Mon, May 11, 2020 at 12:57 PM Ismaël Mejía  wrote:
>
>> Now that the vote has passed maybe we should add the images somewhere
>> in the website so people can easily find the Firefly to use it.
>> Something like what we do with our logos
>> https://beam.apache.org/community/logos/
>>
>> WDYT? any taker?
>>
>> On Tue, Apr 28, 2020 at 7:43 PM Pablo Estrada  wrote:
>> >
>> > I'll be happy to as well!
>> >
>> > On Sun, Apr 26, 2020 at 4:18 AM Maximilian Michels 
>> wrote:
>> >>
>> >> Hey Maria,
>> >>
>> >> I can testify :)
>> >>
>> >> Cheers,
>> >> Max
>> >>
>> >> On 23.04.20 20:49, María Cruz wrote:
>> >> > Hi everyone!
>> >> > It is amazing to see how this process developed to collaboratively
>> >> > create Apache Beam's mascot. Thank you to everyone who got involved!
>> >> > I would like to write a blogpost for the Beam website, and I wanted
>> to
>> >> > ask you: would anyone like to offer their testimony about the
>> process of
>> >> > creating the Beam mascot, and what this means to you? Everyone's
>> >> > testimony is welcome! If you witnessed the development of a mascot
>> for
>> >> > another open source project, even better =)
>> >> >
>> >> > Please feel free to express interest on this thread, and I'll reach
>> out
>> >> > to you off-list.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > María
>> >> >
>> >> > On Fri, Apr 17, 2020 at 6:19 AM Jeff Klukas > >> > <mailto:jklu...@mozilla.com>> wrote:
>> >> >
>> >> > I personally like the sound of "Datum" as a name. I also like the
>> >> > idea of not assigning them a gender.
>> >> >
>> >> > As a counterpoint on the naming side, one of the slide decks
>> >> > provided while iterating on the design mentions:
>> >> >
>> >> > > Mascot can change colors when it is “full of data” or has a
>> “batch
>> >> > of data” to process.  Yellow is supercharged and ready to
>> process!
>> >> >
>> >> > Based on that, I'd argue that the mascot maps to the concept of a
>> >> > bundle in the beam execution model and we should consider a name
>> >> > that's a play on "bundle" or perhaps a play on "checkpoint".
>> >> >
>> >> > On Thu, Apr 16, 2020 at 3:44 PM Julian Bruno <
>> juliangbr...@gmail.com
>> >> > <mailto:juliangbr...@gmail.com>> wrote:
>> >> >
>> >> > Hi all,
>> >> >
>> >> > While working on the design of our Mascot
>> >> > Some ideas showed up and I wish to share them.
>> >> > In regard to Alex Van Boxel's question about the name of our
>> Mascot.
>> >> >
>> >> > I was thinking about this yesterday night and feel it could
>> be a
>> >> > great idea to name the Mascot "*Data*" or "*Datum*". Both
>> names
>> >> > sound cute and make sense to me. I prefer the later. Datum
>> means
>> >> > a single piece of information. The Mascot is the first piece
>> of
>> >> > information and its job is to collect batches of data and
>> >> > process it. Datum is in charge of linking information
>> together.
>> >> >
>> >> > In addition, our Mascot should have no gender. Rendering it
>> >> > accessible to all users.
>> >> >
>> >> > Beam as a name for the mascot is pretty straight forward but
&

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Also an update from +Nam Bui  :

"This commit [1] is up-to-date. So I walked through all of markdown files.
Apart from Syntax changes between Jekyll & Hugo, if there were any
differences in contents regarding to removed/added/modified, I would have
double check the text with the current website. I can make sure that now
98-99% (probably 100% if I don’t miss any typos) of the contents are synced
and 0 lost files. Thus, there should be no unexpected content changes which
appears in this commit [1] anymore.


[1]
https://github.com/apache/beam/pull/11554/commits/94e624fb43aa2218150fd3d97333c58d3d9ff653
"

On Fri, May 8, 2020 at 9:57 AM Aizhamal Nurmamat kyzy 
wrote:

> I understand the difficulty, and this certainly comes with lessons learned
> for future similar projects.
>
> To your questions Robert:
> (1 and 2) I will commit to review the text in the resulting pages. I will
> try and use some automation to extract visible text from each page and diff
> it with the current state of the website. I can do this starting next week.
> From some quick research, there seem to be tools that help with this
> analysis (
> https://stackoverflow.com/questions/3286955/compare-two-websites-and-see-if-they-are-equal
> )
> By remaining in this state, we hold others up from making changes, or we
> increase the amount of work needed after merging to port over changes that
> may be missed. If we move forward, new changes can be done on top of the
> new website.
>
> (3) This makes sense. Brian, would you be able to spend some time to look
> at the automation changes (build files and scripts) to ensure they look
> fine?
>
> I would also like to write a post mortem to extract lessons learned and
> avoid this situation in the future.
>
>
> On Fri, May 8, 2020 at 9:44 AM Brian Hulette  wrote:
>
>> I'm -0 on merging as-is. I have the same concerns as Robert and he's
>> voiced them very well so I won't waste time re-airing them.
>>
>> (2) I spot checked the content, pulled out some common patterns, and
>>> it mostly looks good, but there were also some issues (e.g. several
>>> pages were replaced with the contents from entirely different pages).
>>> I would be more comfortable if, say, a smoke test of comparing the old
>>> and new sites, with html tags stripped and ignoring whitespace,
>>> yielded what should be empty diffs.
>>>
>>
>> Can you share any details about this analysis?
>>
>> +1 for verifying the old and new are the same by diffing the output.
>>
>>
>>> (3) It'd be good to have someone give a stamp of approval on the
>>> infrastructure changes, at least to validate that we're not going to
>>> be taking on extra tech debt with regard to jenkins stability and
>>> developer workflow. I see that Brian has at least looked at this some.
>>
>>
>> My involvement so far was just recognizing a problem (creating root-owned
>> files on jenkins workers) and helping to fix it. If there's anyone
>> available who's familiar with the website infrastructure it would be great
>> if they could take a look instead (if not I could probably acquaint myself
>> enough to review).
>>
>> On Thu, May 7, 2020 at 11:57 PM Robert Bradshaw 
>> wrote:
>>
>>> This is a tough situation.
>>>
>>> It would have been much better if this transition was structured in
>>> such a way that the review was more manageable (e.g. the suggestion of
>>> scripts, not mixing in voluminous unnecessary changes like whitespace,
>>> and not updating content), and possibly even incrementally (e.g. the
>>> new site would have been developed over multiple PRs in a subdomain or
>>> subdirectory while being worked on). But hindsight is 20/20 and no
>>> one, myself included, thought to bring this up when the original
>>> migration was proposed, so this is more something to keep in mind for
>>> the future. I also appreciate the efforts that have been made to clean
>>> things up (e.g. preserving history) and address feedback.
>>>
>>> So, where do we go from here? My first thought is that I really don't
>>> want to set a precedent that just because a PR "will require a large
>>> effort" and in a state that if we don't "move forward and merge what
>>> we have now" then "work done so far will be lost" means that we think
>>> it's OK to forgo doing a proper review.
>>>
>>> On the other hand, there are some mitigating factors with this being
>>> the website and not the code in that "bugs," though possibly
>>> embarrassing, won't break producti

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

ing it worse...)
>>
>> (2) I spot checked the content, pulled out some common patterns, and
>> it mostly looks good, but there were also some issues (e.g. several
>> pages were replaced with the contents from entirely different pages).
>> I would be more comfortable if, say, a smoke test of comparing the old
>> and new sites, with html tags stripped and ignoring whitespace,
>> yielded what should be empty diffs.
>>
>> (3) It'd be good to have someone give a stamp of approval on the
>> infrastructure changes, at least to validate that we're not going to
>> be taking on extra tech debt with regard to jenkins stability and
>> developer workflow. I see that Brian has at least looked at this some.
>>
>> - Robert
>>
>>
>> On Thu, May 7, 2020 at 12:40 PM Aizhamal Nurmamat kyzy
>>  wrote:
>> >
>> > Thank you Ahmet.
>> >
>> > Robert/Brian, what do you think?
>> >
>> > The website staging and pre commit tests have passed [1]. If nobody has
>> objections, we could merge it soon.
>> >
>> >
>> > [1] https://github.com/apache/beam/pull/11554
>> >
>> > On Thu, May 7, 2020 at 11:38 AM Ahmet Altay  wrote:
>> >>
>> >>
>> >>
>> >> On Thu, May 7, 2020 at 10:50 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>> >>>
>> >>> Thanks for the writeup Ahmet.
>> >>>
>> >>> My bias is to move forward and merge the PR. After this, we'll review
>> the outcome, and ensure that all the content is there. Nam will help us
>> with that.
>> >>> The reason that I'd like to move forward and merge what we have now -
>> is that if we don't do that, the work done so far will be lost.
>> >>> We'll make sure to stage the website in its current state, and use
>> that as reference/archive to ensure all the content have been moved.
>> >>>
>> >>> Is this reasonable to everyone?
>> >>
>> >>
>> >> This is reasonable to me. I agree with your reasons.
>> >>
>> >> What do others think?
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On Wed, May 6, 2020 at 7:07 PM Ahmet Altay  wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Wed, May 6, 2020 at 2:33 PM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>> > 1) Currently, the main blocker for merging is Staging Test
>> Failures.
>> >>>>>>
>> >>>>>> That and finishing the review. (Is someone tracking/coordinating
>> this?)
>> >>>>>
>> >>>>>
>> >>>>> I am coordinating the work on the failed tests, but I would need
>> other committer's help to perform the review. @Ahmet, could you help us
>> prioritize the review for this PR?
>> >>>>
>> >>>>
>> >>>> The problem is there are too many manual changes. Reviewing this
>> change in this form will require a large effort. I do not think I can
>> interrupt other projects to prioritize reviews on this PR. IMO, we have a
>> few options:
>> >>>>
>> >>>> - PR to be restructured in the format suggested in this thread. A
>> commit for infrastructure changes from Jekyll to hugo. A second commit for
>> a script that will convert the majority of the content. A third commit for
>> the execution of the script. And a fourth commit for the additional manual
>> content changes. If Nam can get to this form, people on this thread
>> myself/Robert/Pablo/Brian can review the changes.
>> >>>> - Another option is, we can accept that we already invested in this
>> transition and overall this is a good change, and merge the PR more or less
>> in its current form (with tests fixed and open comments addressed) even
>> though it has issues. And then overtime fix the issues we encounter. There
>> was already some amount of review and visual comparisons, we risk losing
>> some recent content changes but I am assuming this will not be much. If Nam
>> can commit to compare two sites after a merge, fixing the majority of the
>> delta, this might be a viable option.
>> >>>>
>> >>>> Another thing we can do, we can archive/store a read-only copy of
>> the current website in an "archive" url temporarily instead of co

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Thank you Ahmet.

Robert/Brian, what do you think?

The website staging and pre commit tests have passed [1]. If nobody has
objections, we could merge it soon.


[1] https://github.com/apache/beam/pull/11554

On Thu, May 7, 2020 at 11:38 AM Ahmet Altay  wrote:

>
>
> On Thu, May 7, 2020 at 10:50 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Thanks for the writeup Ahmet.
>>
>> My bias is to move forward and merge the PR. After this, we'll review the
>> outcome, and ensure that all the content is there. Nam will help us with
>> that.
>> The reason that I'd like to move forward and merge what we have now - is
>> that if we don't do that, the work done so far will be lost.
>> We'll make sure to stage the website in its current state, and use that
>> as reference/archive to ensure all the content have been moved.
>>
>> Is this reasonable to everyone?
>>
>
> This is reasonable to me. I agree with your reasons.
>
> What do others think?
>
>
>>
>>
>> On Wed, May 6, 2020 at 7:07 PM Ahmet Altay  wrote:
>>
>>>
>>>
>>> On Wed, May 6, 2020 at 2:33 PM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
>>>>
>>>>> > 1) Currently, the main blocker for merging is Staging Test Failures.
>>>>>
>>>>> That and finishing the review. (Is someone tracking/coordinating this?)
>>>>>
>>>>
>>>> I am coordinating the work on the failed tests, but I would need other
>>>> committer's help to perform the review. @Ahmet, could you help us
>>>> prioritize the review for this PR?
>>>>
>>>
>>> The problem is there are too many manual changes. Reviewing this change
>>> in this form will require a large effort. I do not think I can interrupt
>>> other projects to prioritize reviews on this PR. IMO, we have a few options:
>>>
>>> - PR to be restructured in the format suggested in this thread. A commit
>>> for infrastructure changes from Jekyll to hugo. A second commit for a
>>> script that will convert the majority of the content. A third commit for
>>> the execution of the script. And a fourth commit for the additional manual
>>> content changes. If Nam can get to this form, people on this thread
>>> myself/Robert/Pablo/Brian can review the changes.
>>> - Another option is, we can accept that we already invested in this
>>> transition and overall this is a good change, and merge the PR more or less
>>> in its current form (with tests fixed and open comments addressed) even
>>> though it has issues. And then overtime fix the issues we encounter. There
>>> was already some amount of review and visual comparisons, we risk losing
>>> some recent content changes but I am assuming this will not be much. If Nam
>>> can commit to compare two sites after a merge, fixing the majority of the
>>> delta, this might be a viable option.
>>>
>>> Another thing we can do, we can archive/store a read-only copy of the
>>> current website in an "archive" url temporarily instead of completely
>>> deleting it. It will give us a baseline for a while to go back to the old
>>> content and move any missing data. (And maybe, someone can come up with an
>>> innovative way to compare the textual content of both sites.) A note on the
>>> stop world approach, I believe we are already failing on that with merge
>>> conflicts showing up on the PR. It will be better for us to complete the
>>> transition as soon as possible. Fixing after the initial merge might be a
>>> simpler task, especially if we can archive the old site.
>>>
>>>
>>>>
>>>>
>>>>> > Michal showed Nam how to handle the 1st test which was about Apache
>>>>> License missing.
>>>>> >
>>>>> > However, the 2nd and 3rd tests looked like some kind of permissions
>>>>> error on the Jenkins worker, not to be configured by code. For more 
>>>>> details
>>>>> based on Jenkin logs, the 2nd test failed because of
>>>>> website/www/site/themes and the 3rd test failed because of
>>>>> website/www/node_modules, they are both auto-generated files on build. Can
>>>>> someone help Nam to look into this?
>>>>> >
>>>>> > RAT ("Run RAT PreCommit") — FAILURE
>>>>> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>>>>> >

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Thanks for the writeup Ahmet.

My bias is to move forward and merge the PR. After this, we'll review the
outcome, and ensure that all the content is there. Nam will help us with
that.
The reason that I'd like to move forward and merge what we have now - is
that if we don't do that, the work done so far will be lost.
We'll make sure to stage the website in its current state, and use that as
reference/archive to ensure all the content have been moved.

Is this reasonable to everyone?


On Wed, May 6, 2020 at 7:07 PM Ahmet Altay  wrote:

>
>
> On Wed, May 6, 2020 at 2:33 PM Aizhamal Nurmamat kyzy 
> wrote:
>
>>
>>> > 1) Currently, the main blocker for merging is Staging Test Failures.
>>>
>>> That and finishing the review. (Is someone tracking/coordinating this?)
>>>
>>
>> I am coordinating the work on the failed tests, but I would need other
>> committer's help to perform the review. @Ahmet, could you help us
>> prioritize the review for this PR?
>>
>
> The problem is there are too many manual changes. Reviewing this change in
> this form will require a large effort. I do not think I can interrupt other
> projects to prioritize reviews on this PR. IMO, we have a few options:
>
> - PR to be restructured in the format suggested in this thread. A commit
> for infrastructure changes from Jekyll to hugo. A second commit for a
> script that will convert the majority of the content. A third commit for
> the execution of the script. And a fourth commit for the additional manual
> content changes. If Nam can get to this form, people on this thread
> myself/Robert/Pablo/Brian can review the changes.
> - Another option is, we can accept that we already invested in this
> transition and overall this is a good change, and merge the PR more or less
> in its current form (with tests fixed and open comments addressed) even
> though it has issues. And then overtime fix the issues we encounter. There
> was already some amount of review and visual comparisons, we risk losing
> some recent content changes but I am assuming this will not be much. If Nam
> can commit to compare two sites after a merge, fixing the majority of the
> delta, this might be a viable option.
>
> Another thing we can do, we can archive/store a read-only copy of the
> current website in an "archive" url temporarily instead of completely
> deleting it. It will give us a baseline for a while to go back to the old
> content and move any missing data. (And maybe, someone can come up with an
> innovative way to compare the textual content of both sites.) A note on the
> stop world approach, I believe we are already failing on that with merge
> conflicts showing up on the PR. It will be better for us to complete the
> transition as soon as possible. Fixing after the initial merge might be a
> simpler task, especially if we can archive the old site.
>
>
>>
>>
>>> > Michal showed Nam how to handle the 1st test which was about Apache
>>> License missing.
>>> >
>>> > However, the 2nd and 3rd tests looked like some kind of permissions
>>> error on the Jenkins worker, not to be configured by code. For more details
>>> based on Jenkin logs, the 2nd test failed because of
>>> website/www/site/themes and the 3rd test failed because of
>>> website/www/node_modules, they are both auto-generated files on build. Can
>>> someone help Nam to look into this?
>>> >
>>> > RAT ("Run RAT PreCommit") — FAILURE
>>> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>>> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>>> >
>>> > 2) Are there any other blockers for merging? @Ahmet/Robert/others
>>> please share if there are any other blockers.
>>> >
>>> >
>>> > [1] https://github.com/gohugoio/hugo/pull/4494
>>> >
>>> >
>>> > On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw 
>>> wrote:
>>> >>
>>> >> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
>>> >> >
>>> >> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw <
>>> rober...@google.com> wrote:
>>> >> >>>
>>> >> >>> I took the massive commit and split it up into:
>>> >> >>>
>>> >> >>> (1) Infrastructure changes (basically everything outside of
>>> >> >>> (website/www/site/content)
>>> >> >>> (2) Sed script changes, and
>>> >> >>> (3) Manual changes (everything not

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

>
>
> > 1) Currently, the main blocker for merging is Staging Test Failures.
>
> That and finishing the review. (Is someone tracking/coordinating this?)
>

I am coordinating the work on the failed tests, but I would need other
committer's help to perform the review. @Ahmet, could you help us
prioritize the review for this PR?



> > Michal showed Nam how to handle the 1st test which was about Apache
> License missing.
> >
> > However, the 2nd and 3rd tests looked like some kind of permissions
> error on the Jenkins worker, not to be configured by code. For more details
> based on Jenkin logs, the 2nd test failed because of
> website/www/site/themes and the 3rd test failed because of
> website/www/node_modules, they are both auto-generated files on build. Can
> someone help Nam to look into this?
> >
> > RAT ("Run RAT PreCommit") — FAILURE
> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
> >
> > 2) Are there any other blockers for merging? @Ahmet/Robert/others please
> share if there are any other blockers.
> >
> >
> > [1] https://github.com/gohugoio/hugo/pull/4494
> >
> >
> > On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw 
> wrote:
> >>
> >> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
> >> >
> >> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw 
> wrote:
> >> >>>
> >> >>> I took the massive commit and split it up into:
> >> >>>
> >> >>> (1) Infrastructure changes (basically everything outside of
> >> >>> (website/www/site/content)
> >> >>> (2) Sed script changes, and
> >> >>> (3) Manual changes (everything not in (1) and (2)).
> >> >
> >> >
> >> > Thank you Robert. This makes it much easier. What is the source of
> the sed script? I am not sure why some of those lines are there. It would
> be much easier for us to comment on the script source if it is reviewable
> somewhere.
> >>
> >> I just gathered up common patterns as I was trying to go through and
> >> review the files... Mostly it was an exercise in finding a compact
> >> representation for the delta, not trying to be a perfect conversion.
> >> (I do think in retrospect, if we do something like this again, it
> >> would be preferable to commit a script that does the auto-conversion
> >> (maybe even with some patch files for manual changes) both for ease of
> >> reviewing and to avoid the stop-the-world situation we're in now. (I'm
> >> still worried that some changes will get lost in the shuffle.)
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Hi all,

Nam and Brian have been working together on blog post names and
the decision was to keep them as they are for now, because Hugo doesn’t
fully support the feature that was mentioned earlier [1]. Also I believe
this can be done after merging the PR.

1) Currently, the main blocker for merging is Staging Test Failures.
Michal showed Nam how to handle the 1st test which was about Apache License
missing.

However, the 2nd and 3rd tests looked like some kind of permissions error
on the Jenkins worker, not to be configured by code. For more details based
on Jenkin logs, the 2nd test failed because of website/www/site/themes and
the 3rd test failed because of website/www/node_modules, they are both
auto-generated files on build. Can someone help Nam to look into this?

RAT ("Run RAT PreCommit") — FAILURE
Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE

2) Are there any other blockers for merging? @Ahmet/Robert/others please
share if there are any other blockers.


[1] https://github.com/gohugoio/hugo/pull/4494


On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw  wrote:

> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
> >
> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw 
> wrote:
> >>>
> >>> I took the massive commit and split it up into:
> >>>
> >>> (1) Infrastructure changes (basically everything outside of
> >>> (website/www/site/content)
> >>> (2) Sed script changes, and
> >>> (3) Manual changes (everything not in (1) and (2)).
> >
> >
> > Thank you Robert. This makes it much easier. What is the source of the
> sed script? I am not sure why some of those lines are there. It would be
> much easier for us to comment on the script source if it is reviewable
> somewhere.
>
> I just gathered up common patterns as I was trying to go through and
> review the files... Mostly it was an exercise in finding a compact
> representation for the delta, not trying to be a perfect conversion.
> (I do think in retrospect, if we do something like this again, it
> would be preferable to commit a script that does the auto-conversion
> (maybe even with some patch files for manual changes) both for ease of
> reviewing and to avoid the stop-the-world situation we're in now. (I'm
> still worried that some changes will get lost in the shuffle.)
>

Re: Apache Beam application to Season of Docs 2020

[Aizhamal Nurmamat kyzy]

Thank you, Kyle! really appreciate it! I will add you as a mentor into the
cwiki page, and let you know if Beam gets accepted to the program on May
11th.

On Tue, May 5, 2020 at 12:55 PM Kyle Weaver  wrote:

> Thanks Aizhamal! I would be willing to help with project 1.
>
> On Mon, May 4, 2020 at 5:04 PM Aizhamal Nurmamat kyzy 
> wrote:
>
>> Hi all,
>>
>> I have submitted the application to the Season of Docs program with the
>> project ideas we have developed last year [1]. I learnt about its deadline
>> a few hours ago and didn't want to miss it.
>>
>> Feel free to add more project ideas (or edit the current ones) until May
>> 7th.
>>
>> If Beam gets approved, we will get 1 or 2 experienced technical writers
>> to help us document community processes or some Beam features. Is anyone
>> else willing to mentor for these projects?
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs
>>
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Thanks everyone for your feedback and support with the review. Please add
any other comments so we can address them soon, if not please share your
LGTMs.

@Robert, thanks for separating the PR!

@Thomas, regarding your question "There are some changes missing though
(for example [2]), are you planning to add more recent commits later?" -
yes, after merging the PR we will update all of the recent changes that are
missing.

@Nam Bui  , can we look into using the feature from
this PR [1] that Brian mentioned to keep dates in blog post file names?

@everyone, Nam also had a question regarding staging functionality - it
keeps showing the errors like below:

RAT ("Run RAT PreCommit") — FAILURE
Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE

The staging is working, but the jobs show up as failed. Does anyone have an
idea what the failures are related to and how we can fix it?

[1] https://github.com/gohugoio/hugo/pull/4494



On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw  wrote:

> I took the massive commit and split it up into:
>
> (1) Infrastructure changes (basically everything outside of
> (website/www/site/content)
> (2) Sed script changes, and
> (3) Manual changes (everything not in (1) and (2)).
>
> It does seem that (3) has a number of unintentional changes, some
> stylistic (e.g. lost of removal of end-of-file newlines) and some
> actual content that's not up to date. This cuts down the number of
> lines to be reviewed by more than half (and, notably, the more
> substantial ones).
>
> [1]
> https://github.com/apache/beam/pull/11608/commits/1bcf519a0f041607dfa401f167164301acbca2ac
> 72 files changed, 3546 insertions(+), 1472 deletions(-)
> [2]
> https://github.com/apache/beam/pull/11608/commits/8b9f488c519b97a11ca4c7e3b644bb9ffe12cb98
> 252 files changed, 4136 insertions(+), 4684 deletions(-)
> [3]
> https://github.com/apache/beam/pull/11608/commits/f9d8bc13a0fda0a60a436aa56186139d0f71de4e
> 228 files changed, 1859 insertions(+), 2370 deletions(-)
>
> I also separated out the compatibility matrix move, which was ~1700
> lines.
> https://github.com/apache/beam/pull/11608/commits/16516d036af047493445654d61940dea8d04eaaa
>
> On Mon, May 4, 2020 at 6:15 PM Robert Bradshaw 
> wrote:
> >
> > On Mon, May 4, 2020 at 6:02 PM Thomas Weise 
> wrote:
> > >
> > > I took a brief look at [1] and looks good overall.
> > >
> > > There are some changes missing though (for example [2]), are you
> planning to add more recent commits later?
> > >
> > > Also, there was an earlier question from Brian regarding the
> possibility to retain the post dates in blog file names. I would second
> that, it would make the posts significantly easier to navigate.
> >
> > I'm OK with removing them from the URL if they're to distracting, but
> > generally agree here. (If it's too difficult, it's not a huge issue.)
> >
> > > [1]
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
> > > [2]
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/documentation/runners/flink/index.html
> > >
> > > Thomas
> > >
> > > On Mon, May 4, 2020 at 11:06 AM Hannah Jiang 
> wrote:
> > >>
> > >> Hi Aizhamal,, yes, Wednesday sounds good to me. Thank you.
> > >>
> > >>
> > >> On Mon, May 4, 2020 at 10:40 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
> > >>>
> > >>> Hannah,
> > >>>
> > >>> We don't have an exact date, but we are hoping to address all the
> comments and merge the PR by Wednesday. Will it be possible for you to wait
> until then?
> > >>>
> > >>> On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang 
> wrote:
> > >>>>>
> > >>>>> Since we want to move forward with the PR, I would like to ask the
> community to hold off changes to the current Beam website for a week, until
> we are able to review and merge the PR. Is this acceptable to everyone?
> > >>>>
> > >>>> Do we have an exact date when we can push changes to the website? I
> have PRs to update documents so would like to plan ahead.
> > >>>>
> > >>>> On Thu, Apr 30, 2020 at 1:17 PM Nam Bui 
> wrote:
> > >>>>>
> > >>>>> Hey guys,
> > >>>>>
> > >>>>> I tried my best to handle renamed files in Git. I have no clue why
> GitHub doesn't show it, but finally, I made this commit [1] (thanks for
> y

Apache Beam application to Season of Docs 2020

[Aizhamal Nurmamat kyzy]

Hi all,

I have submitted the application to the Season of Docs program with the
project ideas we have developed last year [1]. I learnt about its deadline
a few hours ago and didn't want to miss it.

Feel free to add more project ideas (or edit the current ones) until May
7th.

If Beam gets approved, we will get 1 or 2 experienced technical writers to
help us document community processes or some Beam features. Is anyone else
willing to mentor for these projects?

[1] https://cwiki.apache.org/confluence/display/BEAM/Google+Season+of+Docs

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Hannah,

We don't have an exact date, but we are hoping to address all the comments
and merge the PR by Wednesday. Will it be possible for you to wait until
then?

On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang  wrote:

> Since we want to move forward with the PR, I would like to ask the
>> community to hold off changes to the current Beam website for a week, until
>> we are able to review and merge the PR. Is this acceptable to everyone?
>
> Do we have an exact date when we can push changes to the website? I have
> PRs to update documents so would like to plan ahead.
>
> On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:
>
>> Hey guys,
>>
>> I tried my best to handle renamed files in Git. I have no clue why GitHub
>> doesn't show it, but finally, I made this commit [1] (thanks for your
>> idea @bhulette) so you guys can review changes with ease (there is no bunch
>> of deleted markdown files anymore :D). Also, new staged version is
>> deployed, you could check it out [2].
>>
>> In case you are interested in translation, here is the proof of concept
>> [3] (the earth icon on the right corner is temporarily used for switching
>> languages). You can take a look at the translation guide for this PoC [4].
>>
>> [1]
>> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
>> [2]
>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
>> [3] https://safe-relation.surge.sh/
>> [4]
>> https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide
>>
>>
>> On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette 
>> wrote:
>>
>>> Changing the URLs is fine with me as long as the old urls will work too.
>>>
>>> But do we need to change the filenames for the blog posts to accomplish
>>> that? It's nice that the blog post markdown files start with a date so they
>>> naturally sort chronologically. It looks like this hugo PR [1] made it
>>> possible to extract date metadata and slug
>>> (i.e. dataflow-python-sdk-is-now-public) separately from the filename.
>>>
>>> [1] https://github.com/gohugoio/hugo/pull/4494
>>>
>>> On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:
>>>>
>>>>> For changed URLs, will previous URLs be mapped to avoid broken
>>>>> external links?
>>>>>
>>>>
>>>> I believe the answer is yes from Nam's response "For now, we keep the
>>>> old URLs working in terms of redirecting them". I very much agree that this
>>>> is very important and should work for all existing urls.
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
>>>>> aizha...@apache.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> To give a little more context regarding the URLs, the date should
>>>>>> still appear on the blog post, but not on the URL.
>>>>>> For example, we'd have:
>>>>>>
>>>>>> https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
>>>>>> become
>>>>>> https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.
>>>>>>
>>>>>
>>>> I am not a content marketer. IMO, this is a good change. In the past, a
>>>> few times, we edited dates on posts (e.g. a release date was entered
>>>> incorrectly) and we had to either have a mismatch between dates in the url
>>>> and the date in the blog, or change the url. This change simplifies, by
>>>> having date only in place (in content metadata).
>>>>
>>>>
>>>>>
>>>>>> The blog posts would have a small header showing the title, author
>>>>>> and publish date. But the URL would not have it.
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging
>>>>>>> version is "
>>>>>>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
>>>>>>> which also

Re: Companies using Beam?

[Aizhamal Nurmamat kyzy]

Another example of similar pages:
https://www.instaclustr.com/resource-type/case-studies/. The whole
resources section is very useful. It would be good for Beam to have links
to webinars, meetups, books, whitepapers, etc. from the website where new
users land.
Simpler example: https://flink.apache.org/poweredby.html . It shows
snippets and links to external (mostly) resources. Seems easier to manage.


On Fri, May 1, 2020 at 6:28 AM Kenneth Knowles  wrote:

> +1 to a "Powered By" style page. These are pretty common. Like
> https://calcite.apache.org/docs/powered_by.html
>
> I think applying a designer's skills might result in something a bit
> cooler looking...
>
> Kenn
>
> On Thu, Apr 30, 2020 at 9:24 AM Austin Bennett <
> whatwouldausti...@gmail.com> wrote:
>
>> A first pass, something like:
>>
>> https://druid.apache.org/druid-powered
>> https://spark.apache.org/powered-by.html
>>
>> or even as simple as:
>> https://github.com/apache/airflow#who-uses-apache-airflow
>>
>> Would go a long way in the sorts of very high-level conversations I'm
>> having around technology adoption/standardization.
>>
>> Getting into more specifics/testimonials/case-studies is also great, but
>> I wouldn't expect those to get looked at by most, until passing the first
>> bar of seeming to having a significant adoption.
>>
>> @Aizhamal Nurmamat kyzy   - happy to contribute as
>> I can.
>>
>> On Tue, Apr 28, 2020 at 10:13 PM Jean-Baptiste Onofre 
>> wrote:
>>
>>> Hi,
>>>
>>> We already have some testimonials on Beam home page (I did the one about
>>> Beam use at Talend).
>>>
>>> It makes sense to have a dedicated section as it gives ideas about use
>>> case and production system running with Beam.
>>>
>>> Regards
>>> JB
>>>
>>> > Le 28 avr. 2020 à 23:42, Austin Bennett 
>>> a écrit :
>>> >
>>> > Hi All,
>>> >
>>> > Have we considered getting onto our website or our our GitHub repo the
>>> ability for individuals to share that their company is using Beam?  Seeing
>>> - what I believe to be a reasonable list of - companies productively using
>>> Beam would be helpful to point others to.  For instance, a common question
>>> I get is whether anyone or who is using?  I'm not sure that's the best
>>> metric or datapoint in many cases for adoption, but a heuristic that some
>>> rely upon.
>>> >
>>> > Naturally, we could ask for a roll-call, esp. via user list, but
>>> imagining  a persistent web-list would be of interest.
>>> >
>>> > Cheers,
>>> > Austin
>>> >
>>> >
>>> > P.S.  If putting such a list into our repo, that would also get some
>>> people to submit PRs (so more contributors!) :-)
>>> >
>>> >
>>>
>>>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Hi,

To give a little more context regarding the URLs, the date should still
appear on the blog post, but not on the URL.
For example, we'd have:
https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
become https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.

The blog posts would have a small header showing the title, author and
publish date. But the URL would not have it.
Thoughts?


On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:

> Hi,
>
> @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging version is "
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
> which also includes "/11554", and Hugo considers it as a path so it breaks
> the path of "static files" (like images). We made a fix. Now I'm working on
> "getting git to recognize files as renames" as you suggested.
>
> @robert: The dates are nice but it causes verbose/long/ugly URLs. We
> discussed with Aizhamal in the development stage and agreed to get rid of
> this. For now, we keep the old URLs working in terms of redirecting them.
> However, from now on, we should change the name convention on blog posts to
> have a fancy URL like "beam.apache.org/blog/myblogpost.md". :)
>
>
>
> On Thu, Apr 30, 2020 at 2:57 AM Robert Bradshaw 
> wrote:
>
>> On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay  wrote:
>>
>>> Nam, this looks better. At least links are working, and the website
>>> visually looks similar and generally in good shape. I think there are still
>>> issues. For example, I do not see any of the images (e.g. the beam logo on
>>> top left is missing.)
>>>
>>> On Wed, Apr 29, 2020 at 3:11 PM Brian Hulette 
>>> wrote:
>>>
>>>> I left a comment on the PR [1]. I think the reason all of the website
>>>> content is not being tracked as file renames is because there was a series
>>>> of commits that created files in the new directory, and then one commit
>>>> that deleted the old directory. If there were a single commit with all of
>>>> the deleted and new files, git would surely recognize they are effectively
>>>> renameds and mark them as such. Maybe we just need to get all these commits
>>>> squashed into one?
>>>>
>>>> [1] https://github.com/apache/beam/pull/11554#issuecomment-621489844
>>>>
>>>
>>> Nam, could you try this? If we can get git to recognize these as
>>> renames, review process would be much easier.
>>>
>>
>> +1.
>>
>> Alternatively, create a commit that just moves the files into a new
>> location (which git can always detect), then sit the edits on top of that
>> (which should preserve history better).
>>
>> Also, is there a reason the dates were removed from the blog post
>> filenames? For content like that, the dates are nice.
>>
>>
>>>
>>>
>>>>
>>>> On Wed, Apr 29, 2020 at 10:39 AM Nam Bui  wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I'm Nam - from the responsible team of Apache Beam website migration.
>>>>> I am pleased to answer some of the questions here.
>>>>>
>>>>> @aizhamal: Thanks for informing to the community. :)
>>>>> @altay, @robertwb: Yes. there is a problem with the staged version at
>>>>> the moment. We didn't expect some behaviours on the build process. So, we
>>>>> fixed it today and been waiting for @pablo to re-run it again. The purpose
>>>>> of this PR is to migrate completely Beam site from Jekyll to Hugo.
>>>>> Therefore, a bunch of deleted markdown files are from Jekyll which was
>>>>> located at `beam/website/src`, and Hugo is located at `beam/website/www`
>>>>> now. In `beam/website/README.md`, I wrote down about running the Hugo
>>>>> website locally, although it is actually same as Jekyll (because it's also
>>>>> set up with Docker & Gradle). In `beam/website/CONTRIBUTE.md`, I guided
>>>>> people on how to get started with Hugo on the Beam website. There is also 
>>>>> a
>>>>> link in the "Translation Guide" section which points to a branch of
>>>>> multilingual provenance, and it will become a next PR soon.
>>>>>
>>>>> Please let me know if you need more details. Feel free to ask any
>>>>> questions and I will get back to you with answers. I'm so sorry if I 
>>>>> answer
>>>>> a little bit due to the timezone. :)
>>&g

Re: Companies using Beam?

[Aizhamal Nurmamat kyzy]

+1 on adding testimonials/snippets from users either or both on GitHub and
website.

As part of the Beam website redesign proposal [1], we are suggesting to add
a few pages like, "Powered by" or "Use Cases" which users can refer to and
find information on who is using Beam and why. The proposal hasn't been
finalized yet, we are expecting to continue to work on it after we finish
migrating the website to Hugo.

It would be awesome if we started collecting those testimonials, so that we
can share them on the Beam site once there's a Powered By / Use cases
section. Austin, is that something that you're interested in helping with?

[1]
https://docs.google.com/document/d/1btXMkQGqYaU9pUjYh0iCNrbXf4pAHe3tBFsLQ_cLYHg/edit


On Tue, Apr 28, 2020 at 3:06 PM Kyle Weaver  wrote:

> I agree it'd be beneficial to the community to highlight users better.
> Rather than just a list, though, perhaps we can get some additional user
> testimonials (either by requesting them or linking to existing blog posts,
> etc). Testimonials are more effort to write, but I think it's more enticing
> and informative to potential new users to show, in addition to _who_ is
> using Beam, _how_ they are using it. I see there are three already on
> Beam's homepage, maybe we could add more there, or add it to a different
> page, such as the overview page (
> https://beam.apache.org/get-started/beam-overview/). For example, I
> visited GRPC's website by chance earlier today, and I noticed they had
> testimonials from 8 different organizations, that go into detail about why
> they use the software: https://grpc.io/about/#whos-using-grpc-and-why
>
> On Tue, Apr 28, 2020 at 5:43 PM Austin Bennett <
> whatwouldausti...@gmail.com> wrote:
>
>> Hi All,
>>
>> Have we considered getting onto our website or our our GitHub repo the
>> ability for individuals to share that their company is using Beam?  Seeing
>> - what I believe to be a reasonable list of - companies productively using
>> Beam would be helpful to point others to.  For instance, a common question
>> I get is whether anyone or who is using?  I'm not sure that's the best
>> metric or datapoint in many cases for adoption, but a heuristic that some
>> rely upon.
>>
>> Naturally, we could ask for a roll-call, esp. via user list, but
>> imagining  a persistent web-list would be of interest.
>>
>> Cheers,
>> Austin
>>
>>
>> P.S.  If putting such a list into our repo, that would also get some
>> people to submit PRs (so more contributors!) :-)
>>
>>
>>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Adding +Nam Bui  and +Karolina Rosół
 to follow up on questions.

On Tue, Apr 28, 2020 at 11:34 AM Ahmet Altay  wrote:

> I am having trouble reviewing the staged version. What is the best way to
> review this change?
>
> Do we expect any changes to markdown files, beyond some metadata?
>
> On Tue, Apr 28, 2020 at 10:45 AM Robert Bradshaw 
> wrote:
>
>> Thanks. It'll be great to better support more languages.
>>
>> I looked at the PR and there seems to be no provenance/history. E.g. all
>> the content seems to be entirely new files rather than diffs from the old.
>> (There also seems to be a huge amount of auto-generated js code as well.)
>>
>
> I agree. This makes it very hard to review. I also see a bunch of deleted
> markdown files. Are they not getting migrated?
>
>
>>
>> On Tue, Apr 28, 2020 at 10:23 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Hello everybody,
>>>
>>> We are almost done migrating the Apache Beam website from Jekyll to
>>> Hugo. You can see the PR in [1], and we'd love to hear your
>>> feedback/comments on the PR. It includes  detailed guidelines on
>>> contributing to the new Hugo-based website and adding translations to pages
>>> [2]. For those who are curious about adding new languages, we will provide
>>> a proof of concept in the next couple of days in this thread.
>>>
>>> Since we want to move forward with the PR, I would like to ask the
>>> community to hold off changes to the current Beam website for a week, until
>>> we are able to review and merge the PR. Is this acceptable to everyone?
>>>
>>> In case anyone missed my previous email with the background for the
>>> website migration, you can find more context here [3].
>>>
>>> Thanks,
>>> Aizhamal
>>>
>>> [1] https://github.com/apache/beam/pull/11554
>>> [2]
>>> https://github.com/apache/beam/blob/256b7042bf504b94f161ca03b388a2ba247918d9/website/CONTRIBUTE.md
>>> [3]
>>> https://lists.apache.org/thread.html/r7fa6d710c0a1959cce5108e460d71c306ce5756cf96af818b41cb7ca%40%3Cdev.beam.apache.org%3E
>>>
>>

[REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Hello everybody,

We are almost done migrating the Apache Beam website from Jekyll to Hugo.
You can see the PR in [1], and we'd love to hear your feedback/comments on
the PR. It includes  detailed guidelines on contributing to the new
Hugo-based website and adding translations to pages [2]. For those who are
curious about adding new languages, we will provide a proof of concept in
the next couple of days in this thread.

Since we want to move forward with the PR, I would like to ask the
community to hold off changes to the current Beam website for a week, until
we are able to review and merge the PR. Is this acceptable to everyone?

In case anyone missed my previous email with the background for the website
migration, you can find more context here [3].

Thanks,
Aizhamal

[1] https://github.com/apache/beam/pull/11554
[2]
https://github.com/apache/beam/blob/256b7042bf504b94f161ca03b388a2ba247918d9/website/CONTRIBUTE.md
[3]
https://lists.apache.org/thread.html/r7fa6d710c0a1959cce5108e460d71c306ce5756cf96af818b41cb7ca%40%3Cdev.beam.apache.org%3E

Re: [RESULT][VOTE] Accept the Firefly design donation as Beam Mascot - Deadline Mon April 6

[Aizhamal Nurmamat kyzy]

@Alex, Beam Firefly?

On Thu, Apr 9, 2020 at 10:57 PM Alex Van Boxel  wrote:

> We forgot something
>
> ...
>
> ...
>
> it/she/he needs a *name*!
>
>
>  _/
> _/ Alex Van Boxel
>
>
> On Fri, Apr 10, 2020 at 6:19 AM Kenneth Knowles  wrote:
>
>> Looking forward to the guide. I enjoy doing (bad) drawings as a way to
>> relax. And I want them to be properly on brand :-)
>>
>> Kenn
>>
>> On Thu, Apr 9, 2020 at 10:35 AM Maximilian Michels 
>> wrote:
>>
>>> Awesome. What a milestone! The mascot is a real eye catcher. Thank you
>>> Julian and Aizhamal for making it happen.
>>>
>>> On 06.04.20 22:05, Aizhamal Nurmamat kyzy wrote:
>>> > I am happy to announce that this vote has passed, with 13 approving +1
>>> > votes, 5 of which are binding PMC votes.
>>> >
>>> > We have the final design for the Beam Firefly! Yahoo!
>>> >
>>> > Everyone have a great week!
>>> >
>>> >
>>> >
>>> > On Mon, Apr 6, 2020 at 9:57 AM David Morávek >> > <mailto:d...@apache.org>> wrote:
>>> >
>>> > +1 (non-binding)
>>> >
>>> > On Mon, Apr 6, 2020 at 12:51 PM Reza Rokni >> > <mailto:r...@google.com>> wrote:
>>> >
>>> > +1(non-binding)
>>> >
>>> > On Mon, Apr 6, 2020 at 5:24 PM Alexey Romanenko
>>> > mailto:aromanenko@gmail.com>>
>>> wrote:
>>> >
>>> > +1 (non-binding).
>>> >
>>> > > On 3 Apr 2020, at 14:53, Maximilian Michels
>>> > mailto:m...@apache.org>> wrote:
>>> > >
>>> > > +1 (binding)
>>> > >
>>> > > On 03.04.20 10:33, Jan Lukavský wrote:
>>> > >> +1 (non-binding).
>>> > >>
>>> > >> On 4/2/20 9:24 PM, Austin Bennett wrote:
>>> > >>> +1 (nonbinding)
>>> > >>>
>>> > >>> On Thu, Apr 2, 2020 at 12:10 PM Luke Cwik
>>> > mailto:lc...@google.com>
>>> > >>> <mailto:lc...@google.com <mailto:lc...@google.com>>>
>>> wrote:
>>> > >>>
>>> > >>>+1 (binding)
>>> > >>>
>>> > >>>On Thu, Apr 2, 2020 at 11:54 AM Pablo Estrada
>>> > mailto:pabl...@google.com>
>>> > >>><mailto:pabl...@google.com
>>> > <mailto:pabl...@google.com>>> wrote:
>>> > >>>
>>> > >>>+1! (binding)
>>> > >>>
>>> > >>>On Thu, Apr 2, 2020 at 11:19 AM Alex Van Boxel
>>> > >>>mailto:a...@vanboxel.be>
>>> > <mailto:a...@vanboxel.be <mailto:a...@vanboxel.be>>>
>>> wrote:
>>> > >>>
>>> > >>>Thanks for clearing this up Aizhamal.
>>> > >>>
>>> > >>>+1 (non binding)
>>> > >>>
>>> > >>>_/
>>> > >>>_/ Alex Van Boxel
>>> > >>>
>>> > >>>
>>> > >>>On Thu, Apr 2, 2020 at 8:14 PM Aizhamal
>>> > Nurmamat kyzy
>>> > >>>>> > <mailto:aizha...@apache.org> <mailto:aizha...@apache.org
>>> > <mailto:aizha...@apache.org>>> wrote:
>>> > >>>
>>> > >>>Good point, Alex. Actually Julian and I
>>> > have talked
>>> > >>>about producing this kind of guide. It
>>> > will be
>>> > >>>delivered as an additional contribution
>>> > in the follow
>>> > >>>up. We think this will be a derivative
>>&g

Re: [RESULT][VOTE] Accept the Firefly design donation as Beam Mascot - Deadline Mon April 6

[Aizhamal Nurmamat kyzy]

I am happy to announce that this vote has passed, with 13 approving +1
votes, 5 of which are binding PMC votes.

We have the final design for the Beam Firefly! Yahoo!

Everyone have a great week!



On Mon, Apr 6, 2020 at 9:57 AM David Morávek  wrote:

> +1 (non-binding)
>
> On Mon, Apr 6, 2020 at 12:51 PM Reza Rokni  wrote:
>
>> +1(non-binding)
>>
>> On Mon, Apr 6, 2020 at 5:24 PM Alexey Romanenko 
>> wrote:
>>
>>> +1 (non-binding).
>>>
>>> > On 3 Apr 2020, at 14:53, Maximilian Michels  wrote:
>>> >
>>> > +1 (binding)
>>> >
>>> > On 03.04.20 10:33, Jan Lukavský wrote:
>>> >> +1 (non-binding).
>>> >>
>>> >> On 4/2/20 9:24 PM, Austin Bennett wrote:
>>> >>> +1 (nonbinding)
>>> >>>
>>> >>> On Thu, Apr 2, 2020 at 12:10 PM Luke Cwik >> >>> <mailto:lc...@google.com>> wrote:
>>> >>>
>>> >>>+1 (binding)
>>> >>>
>>> >>>On Thu, Apr 2, 2020 at 11:54 AM Pablo Estrada >> >>><mailto:pabl...@google.com>> wrote:
>>> >>>
>>> >>>    +1! (binding)
>>> >>>
>>> >>>On Thu, Apr 2, 2020 at 11:19 AM Alex Van Boxel
>>> >>>mailto:a...@vanboxel.be>> wrote:
>>> >>>
>>> >>>Thanks for clearing this up Aizhamal.
>>> >>>
>>> >>>+1 (non binding)
>>> >>>
>>> >>>_/
>>> >>>_/ Alex Van Boxel
>>> >>>
>>> >>>
>>> >>>On Thu, Apr 2, 2020 at 8:14 PM Aizhamal Nurmamat kyzy
>>> >>>mailto:aizha...@apache.org>> wrote:
>>> >>>
>>> >>>Good point, Alex. Actually Julian and I have talked
>>> >>>about producing this kind of guide. It will be
>>> >>>delivered as an additional contribution in the follow
>>> >>>up. We think this will be a derivative of the original
>>> >>>design, and be done after the original is officially
>>> >>>accepted.
>>> >>>
>>> >>>With this vote, we want to accept the Firefly donation
>>> >>>as designed [1], and let Julian produce other
>>> >>>artifacts using the official Beam mascot later on.
>>> >>>
>>> >>>[1]
>>> https://docs.google.com/document/d/1zK8Cm8lwZ3ALVFpD1aY7TLCVNwlyTS3PXxTV2qQCAbk/edit?usp=sharing
>>> >>>
>>> >>>
>>> >>>On Thu, Apr 2, 2020 at 10:37 AM Alex Van Boxel
>>> >>>mailto:a...@vanboxel.be>> wrote:
>>> >>>
>>> >>>I don't want to be a spoiler... but this vote
>>> >>>feels like a final deliverable... but without a
>>> >>>style guide as Kenn originally suggested most of
>>> >>>use will not be able to adapt the design. This
>>> >>>would include:
>>> >>>
>>> >>>  * frontal view
>>> >>>  * side view
>>> >>>  * back view
>>> >>>
>>> >>>actually different posses so we can mix and match.
>>> >>>Without this it will never reach the potential of
>>> >>>the Go gopher or gRPC Pancakes.
>>> >>>
>>> >>>Note this is *not* a negative vote but I'm afraid
>>> >>>that the use without a guide will be fairly
>>> >>>limited as most of use are not designers. Just a
>>> >>>concern.
>>> >>>
>>> >>> _/
>>> >>>_/ Alex Van Boxel
>>> >>>
>>> >>>
>>> >>>On Thu, Apr 2, 2020 at 7:27 PM Andrew Pilloud
>>> >>>mailto:apill...@apache.or

Re: [VOTE] Accept the Firefly design donation as Beam Mascot - Deadline Mon April 6

[Aizhamal Nurmamat kyzy]

Good point, Alex. Actually Julian and I have talked about producing this
kind of guide. It will be delivered as an additional contribution in the
follow up. We think this will be a derivative of the original design, and
be done after the original is officially accepted.

With this vote, we want to accept the Firefly donation as designed [1], and
let Julian produce other artifacts using the official Beam mascot later on.

[1]
https://docs.google.com/document/d/1zK8Cm8lwZ3ALVFpD1aY7TLCVNwlyTS3PXxTV2qQCAbk/edit?usp=sharing


On Thu, Apr 2, 2020 at 10:37 AM Alex Van Boxel  wrote:

> I don't want to be a spoiler... but this vote feels like a final
> deliverable... but without a style guide as Kenn originally suggested most
> of use will not be able to adapt the design. This would include:
>
>- frontal view
>- side view
>- back view
>
> actually different posses so we can mix and match. Without this it will
> never reach the potential of the Go gopher or gRPC Pancakes.
>
> Note this is *not* a negative vote but I'm afraid that the use without a
> guide will be fairly limited as most of use are not designers. Just a
> concern.
>
>  _/
> _/ Alex Van Boxel
>
>
> On Thu, Apr 2, 2020 at 7:27 PM Andrew Pilloud  wrote:
>
>> +1, Accept the donation of the Firefly design as Beam Mascot
>>
>> On Thu, Apr 2, 2020 at 10:19 AM 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 + INPUT] Beam Mascot Designs, 3rd iteration - Deadline Wednesday, April 1

[Aizhamal Nurmamat kyzy]

Thank you all for taking an active role to develop our beautiful Firefly :)


On Wed, Apr 1, 2020 at 9:36 AM Kenneth Knowles  wrote:

> No stripes for me!
>
> I really like the evolution of the tail.
>
> On Wed, Apr 1, 2020 at 12:30 AM jincheng sun 
> wrote:
>
>> Thanks Julian!
>>
>> > 1. Do you prefer stripes or no stripes?
>> +1 for no stripes.
>>
>> I like the design even the early Sketches. Great work!
>>
>> Best,
>> Jincheng
>>
>>
>>
>> Jan Lukavský  于2020年3月31日周二 下午4:33写道：
>>
>>> On 3/31/20 4:06 AM, Julian Bruno wrote:
>>>
>>> Hello Apache Beam Community,
>>>
>>> We need a third input from the community to finish the design. Please
>>> share your input no later than Wednesday, April 1st, at noon Pacific Time.
>>> Below you will find a link to the presentation of the work process and we
>>> are eager to know what you think of the current design [1].
>>>
>>> Our question to you:
>>>
>>> 1. Do you prefer stripes or no stripes?
>>>
>>> +1 for no stripes. +0.5 for stripes. +1 overall, nice work!
>>>
>>>
>>> Please reply inline, so it is clear what exactly you are referring to. The
>>> vote and input phase will be open until Wednesday, April 1st, at 12 pm
>>> Pacific Time. We will incorporate the feedback into the final design
>>> iteration of the mascot.
>>>
>>> Please find below the attached source file (.SVG) and a High-Quality
>>> Image (.PNG).
>>>
>>> Thank you,
>>>
>>> --
>>> Julian Bruno // Visual Artist & Graphic Designer
>>>  (510) 367-0551 / SF Bay Area, CA
>>> www.instagram.com/julbro.art
>>>
>>> [1]
>>>
>>>  3/30 - Mascot Weekly Update
>>> 
>>>
>>>
>>>
>>> ᐧ
>>>
>>>

Re: [INPUT] Beam Mascot Design Progress Updates

[Aizhamal Nurmamat kyzy]

Thank you Julian for updates! Can't wait for the 2nd iteration!

On Thu, Mar 19, 2020 at 4:03 PM Julian Bruno  wrote:

> Hi Everyone,
>
> As you know, I am the designer in charge of the mascot for Apache Beam.
>
> I am looking forward to sharing with you the progress and next steps to
> follow:
>
> Last week we started a vote to get input from the community to continue
> moving forward with the design. Today we have the results and by the
> majority of votes the most chosen design is:
>
> Preferences:
>
> Simple design (to make it easy to edit)
>
> Flat colors
>
> Heavy lines
>
> Shadows
>
> Glowing wings (to avoid flatness)
>
> Trail of light for a tail
>
> Sideway view ¾ (for printing)
>
> In addition, some of you proposed ideas and possible combinations, which
> serve to define the mascot.
>
> Questions:
>
> Can prints have shadows and animation gradient?
>
> Yes, they can.
>
> What if we stretched the current Beam logo into the wings?
>
> I could try to see how this could work.
>
> Next Steps:
>
> Iterating on the design based on the majority vote
>
> Sharing updates as needed
>
> I wanted to clarify one more thing.  The delivery of the files will be in
> two file formats, rasterized (JPG / PNG) and vectorial (SVG / Ai.).  The
> former is not editable. The latter is editable and will be presented in
> layers. Each layer will incorporate each element of the body separately and
> be named accordingly to what it represents, eg.,  Layer 1: Arm Front, Layer
> 2: Arm Back, etc. Please note that you need a program, like Adobe
> Illustrator, BoxySVG, Vecteezy, Vectr., to be able to edit vectors.
>
> Thank you for sharing your thoughts.
>
> Your questions and concerns are important to my work, so if you have any,
> feel free to reach out!
>
> Cheers,
>
>
> --
> Julian Bruno // Visual Artist & Graphic Designer
>  (510) 367-0551 / SF Bay Area, CA
> www.instagram.com/julbro.art
>
> ᐧ
>

Re: [Progress Update] Improvements to the Apache Beam website - Phase 1

[Aizhamal Nurmamat kyzy]

Hi Kenn,

The transition will occur in the next 6-8 weeks as estimated by the
vendors. For now, there will be no changes to the workflow. Once we start
contributing pull requests to migrate the website, we'll communicate on the
dev@ list to hold off other PRs. We'll also make sure to update cwiki on
how to make website changes for everyone.
Thanks!


On Wed, Mar 11, 2020 at 8:47 AM Kenneth Knowles  wrote:

> LGTM. Any idea when the transition to Docsy will occur? Will there be a
> period that we will need to pause changes to the website?
>
> On Tue, Mar 10, 2020 at 2:00 PM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Hello everyone,
>>
>> As per our previous discussion [1], we are ready to move forward with the
>> 1st phase of our project plan and migrate the Beam website to Docsy [2].
>> Please review the doc and discussion to see the background for the change.
>> Also feel free to ask any questions and share any feedback you might have
>> in this thread.
>>
>> We have partnered with a 3rd party vendor - Polidea- to execute the
>> migration, and will be sharing progress updates and collecting feedback on
>> the dev@ list.
>>
>> Hope you are all well and stay healthy,
>>
>> Aizhamal
>>
>> [1]
>> https://lists.apache.org/thread.html/rfab4cc1411318c3f4667bee051df68f37be11846ada877f3576c41a9%40%3Cdev.beam.apache.org%3E
>>
>> [2]
>> https://docs.google.com/document/d/1HlRHfmc9MvKkFEf2gfIL3RYVxTmBXQL4sXjAGGOjeiI/edit#heading=h.5rqdbnson7px
>>
>>

Re: [VOTE + INPUT] Beam Mascot Designs, 1st iteration - Deadline Wed March 18

[Aizhamal Nurmamat kyzy]

Thank you Julian!
Here is the link to the slides
https://docs.google.com/presentation/d/1cEydTxQcsTJES_JCRvC_xgK7HMCIfnxmuawd7x2Bk_o/edit?usp=sharing

On Fri, Mar 13, 2020 at 12:25 PM Julian Bruno 
wrote:

> Hello Apache Beam Community,
>
>
> Together with Aizhamal and her team, we have been working on the design of
> the Apache Beam mascot.
>
> We now need input from the community to continue moving forward with the
> design. Please share your input no later than Wednesday, March 18, at noon
> Pacific Time. Below you will find a link to the presentation of the work
> process and we are eager to know what you think of the current design [1].
>
> Our questions to you:
>
> 1. Does the final outcome of the design process meet the community’s
> expectations and represent Apache Beam? If not, what things should change?
>
> For printing, do you prefer sideways or front view for the character?
>
> 2. Which color style do you like? A. Flat Color  B. Gradient Colors C.
> Shadows + Flat Colors (slide 13)
>
> 3. If you chose A, what line style do you like on the flat color style?
> A1. Heavy Lines A2. Thin Lines A3.  No Lines (slide 15)
>
> If you chose B, what line style do you like on the gradient color style?
> B1. Heavy Lines B2. Thin Lines B3.  No Lines (slide 17)
>
> If you chose C, what line style do you like on the shadows + flat color
> style? C1. Heavy Lines C2. Thin Lines C3.  No Lines (slide 19)
>
> 4. What do you think about the color palette?
>
> Please reply inline, so it is clear what exactly you are referring to. The
> vote and input phase will be open until Wednesday, March 18, at 12 pm
> Pacific Time. And we will incorporate the feedback to the next design
> iteration of the mascot.
>
> Thank you,
>
> Julian
>
>
> --
> Julian Bruno // Visual Artist & Graphic Designer
>  (510) 367-0551 / SF Bay Area, CA
> www.instagram.com/julbro.art
>
> ᐧ
>

[Progress Update] Improvements to the Apache Beam website - Phase 1

[Aizhamal Nurmamat kyzy]

Hello everyone,

As per our previous discussion [1], we are ready to move forward with the
1st phase of our project plan and migrate the Beam website to Docsy [2].
Please review the doc and discussion to see the background for the change.
Also feel free to ask any questions and share any feedback you might have
in this thread.

We have partnered with a 3rd party vendor - Polidea- to execute the
migration, and will be sharing progress updates and collecting feedback on
the dev@ list.

Hope you are all well and stay healthy,

Aizhamal

[1]
https://lists.apache.org/thread.html/rfab4cc1411318c3f4667bee051df68f37be11846ada877f3576c41a9%40%3Cdev.beam.apache.org%3E

[2]
https://docs.google.com/document/d/1HlRHfmc9MvKkFEf2gfIL3RYVxTmBXQL4sXjAGGOjeiI/edit#heading=h.5rqdbnson7px

Seattle Beam Meetup - March 2

[Aizhamal Nurmamat kyzy]

Hello everyone,

We are hosting a Beam Meetup in Seattle on March 2! If you are in the
Seattle area please come and join us at Google office in South Lake Union.

Meetup agenda:
18:00 - Registration, speed networking, food and drinks.
18:30 - Encoding free-text drug names in electronic health records using
Apache Beam by Damon Douglas (Dito)
19:00 - Beam+Rust : Portable Correct Performance by Sean Jensen-Grey
(Google)
19:30 - Evolution of Dataswarm, a Facebook Scale Data Pipeline Platform by
Shawn Wang and Kaushik Raj (Facebook)
20:00 - Networking

The detailed agenda and logistics are published here:

https://www.meetup.com/Seattle-Apache-Beam-Meetup/events/268302476/

I hope to see a lot of you around!

Thanks,
Aizhamal

Re: [DISCUSS][PROPOSAL] Improvements to the Apache Beam website

[Aizhamal Nurmamat kyzy]

Thank you all for your feedback. If no one has objections, I will continue
working according to the plan. I will be sharing the progress updates in
the dev list.

Thanks,
Aizhamal

On Tue, Jan 28, 2020 at 7:42 PM Kenneth Knowles  wrote:

> Technical clarification: Docsy is a set of templates for Hugo. The
> advantages of Hugo over Jekyll are many.
>
>  - Its tagline is that it is faster. For large sites maybe that matters
> more, but for us I don't think it matters much. At least not when I'm
> working on the site it hasn't.
>  - Community/vibrance: At this point it is about equal or slightly
> surpassed Jekyll in GitHub stars & forks, etc, so Hugo is thriving. But
> they both are.
>  - I've particularly heard it is better for i18n. I think it is important
> for inclusion to have a space set aside for other languages, even before
> they are contributed or before you are sure there will be demand.
>  - Hugo is easier to get started with, no Ruby stuff which is a huge pain
> and is why we have this docker build for the website (which I don't use
> because I don't have my laptop set up for it). Just simpler. That's good
> for encouraging community contributions. And that is a good starting point
> for a lot of contributors.
>
> I'm all for it. And I think using a great set of templates from a major
> vendor (Google) is a pretty darn good idea. So, big +1 for Hugo and Docsy
> from me.
>
> Kenn
>
>
> On Mon, Jan 27, 2020 at 3:50 PM Heejong Lee  wrote:
>
>>
>> On Mon, Jan 27, 2020 at 11:19 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Hi Alexey,
>>>
>>> Answers are inline:
>>>
>>> Do we have any user demands for documentation translation into other
>>>> languages? I’m asking this because, in my experience, it’s quite tough work
>>>> to translate everything and it won’t be always up-to-date with the
>>>> mainstream docs in English.
>>>>
>>>
>>> We know of at least one user who has been trying to grow a Beam
>>> community in China and translate the documentation with the local community
>>> help:
>>> --> https://github.com/mybeam/Apache-Beam-/tree/master/website
>>> -->
>>> https://lists.apache.org/thread.html/6b7008affee7d70aa0ef13bce7d57455c85759b0af7e08582a086f53%40%3Cdev.beam.apache.org%3E
>>>
>>> This would hopefully unblock other contributors. For translations, the
>>> idea is that the source of truth is the english version, and we'll make
>>> sure it's visible on the header of translated pages, as well as dates for
>>> the latest updates.
>>>
>>
>> +1
>>
>> I think localized contents help non-english speaking users a lot to spark
>> the interest even if the contents are somewhat out-of-date.
>>
>>
>>>
>>> Also, moving to another doc engine probably will require us to change a
>>>> format of mark-up language or not?. What are the other advantages of Docsy
>>>> over Jekyll?
>>>>
>>>
>>> We will have to make small tweaks to the Jekyll MD files, but as Brian
>>> pointed out in the old thread we can use some tools to automate the process:
>>> -->   https://gohugo.io/commands/hugo_import_jekyll/
>>>
>>> I’d also suggest to improve Beam site context search to be able to
>>>> differentiate search queries over user documentation and/or API references.
>>>>
>>> +1. Will add this as a work item.
>>>
>>>

Re: [DISCUSS][PROPOSAL] Improvements to the Apache Beam website

[Aizhamal Nurmamat kyzy]

Hi Alexey,

Answers are inline:

Do we have any user demands for documentation translation into other
> languages? I’m asking this because, in my experience, it’s quite tough work
> to translate everything and it won’t be always up-to-date with the
> mainstream docs in English.
>

We know of at least one user who has been trying to grow a Beam community
in China and translate the documentation with the local community help:
--> https://github.com/mybeam/Apache-Beam-/tree/master/website
-->
https://lists.apache.org/thread.html/6b7008affee7d70aa0ef13bce7d57455c85759b0af7e08582a086f53%40%3Cdev.beam.apache.org%3E

This would hopefully unblock other contributors. For translations, the idea
is that the source of truth is the english version, and we'll make sure
it's visible on the header of translated pages, as well as dates for the
latest updates.

Also, moving to another doc engine probably will require us to change a
> format of mark-up language or not?. What are the other advantages of Docsy
> over Jekyll?
>

We will have to make small tweaks to the Jekyll MD files, but as Brian
pointed out in the old thread we can use some tools to automate the process:
-->   https://gohugo.io/commands/hugo_import_jekyll/

I’d also suggest to improve Beam site context search to be able to
> differentiate search queries over user documentation and/or API references.
>
+1. Will add this as a work item.

[DISCUSS][PROPOSAL] Improvements to the Apache Beam website

[Aizhamal Nurmamat kyzy]

TL;DR

I am proposing improvements to documentation and content of the Apache Beam
website to facilitate adoption and growth of its community [4].

Hi everyone,

I have been talking and brainstorming with a few Beam users, developers,
and contributors to figure out more ways to help increase Beam’s adoption,
and grow a healthy and inclusive community. Based on those conversations, I
have come up with the following ideas:

First, is to enable internationalization and localization of the Apache
Beam website to increase the reach of the project. We can do this by
migrating the current website from Jekyll do Docsy [2]. Docsy supports
internationalization out-of-the-box. Other projects have been very
successful enabling platforms that allow their users to contribute a
translation of the documentation and make the project accessible to
non-english speakers. Examples are Kubernetes, Tensorflow and Apache
Airflow.

Second, is to work on the content of the website to make the user
onboarding experience easier. This includes updating tutorials and
quickstarts, deprecating outdated or irrelevant sets of documentation, and
creating new documentation that is currently lacking. From the
conversations with both new and experienced users, it is clear that there
are a number of new features (Schemas, State and Timers, new Python IOs,
etc) that are not documented. Documentation for existing features can also
be improved. We also plan to add new pages with useful knowledge about Beam
(its Ecosystem, past workshops, talks and upcoming meetups) that will
provide Beam users additional support in their journey towards adoption.

Third, rework the knowledge architecture to be more intuitive and improve
website functionality for better and faster user onboarding. Include
relevant links in the Apache Beam docs to additional contributor resources
on Beam Cwiki to make new contributor experience better.

More detailed action plan and estimated timeline is described in this document
[4]. It is still a work in progress, but feel free to leave your feedback
in the comments, as well as in this thread.


Thanks,

Aizhamal

[1] https://beam.apache.org/
[2] https://github.com/google/docsy
[3] https://cwiki.apache.org/confluence/display/BEAM/Apache+Beam
[4]
https://docs.google.com/document/d/1HlRHfmc9MvKkFEf2gfIL3RYVxTmBXQL4sXjAGGOjeiI/edit#heading=h.5rqdbnson7px

Re: [RESULT] [VOTE] Beam's Mascot will be the Firefly (Lampyridae)

[Aizhamal Nurmamat kyzy]

I was going to let Julian answer as he is following this thread, but yes,
the design will have appropriate licences so we can use and reuse and
modify it in the future. Julian also expressed willingness to stay active
in the community to contribute more varieties of the mascot as we need :)

On Thu, Jan 16, 2020 at 8:52 AM Kenneth Knowles  wrote:

> *correction: ASF does not require transfer of copyright, only appropriate
> license
>
> On Thu, Jan 16, 2020 at 8:45 AM Kenneth Knowles  wrote:
>
>> Good question. IMO it is a very good thing to have fun as with the
>> variety of uses of the Go language mascot.
>>
>> Note that copyright and trademark should be clearly separated in this
>> discussion. These both govern "everyone can draw and adapt".
>>
>> Copyright: contributed images owned by ASF, licensed ASL2. You can use
>> and create derivative works.
>> Trademark: a mark owned by ASF, protected by ASF and Beam PMC. See
>> http://www.apache.org/foundation/marks/ and particularly "nominative
>> use".
>>
>> Kenn
>>
>> On Tue, Jan 14, 2020 at 1:43 PM Alex Van Boxel  wrote:
>>
>>> I hope for the mascot will be simple enough so everyone can draw it and
>>> adapt. The mascot will be license free right... so you don't need to pay
>>> the graphic artist for every use of the mascot?
>>>
>>>  _/
>>> _/ Alex Van Boxel
>>>
>>>
>>> On Tue, Jan 14, 2020 at 8:26 PM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
>>>> Thanks Kenn for running the vote!
>>>>
>>>> I had reached out to a couple designers that I know personally and few
>>>> in the community to see whether they were willing to contribute the
>>>> designs.
>>>>
>>>> Julian was one of them, who agreed to work with us for a reasonable fee
>>>> which can be donated by Google. Julian is a very talented visual artist and
>>>> creates really cool animations too (if we want our Firefly to fly).
>>>>
>>>> Here is more about Julian’s work:
>>>>
>>>> 2D reel : https://youtu.be/2miCzKbuook
>>>>
>>>> linkedin: www.linkedin.com/in/julianbruno
>>>>
>>>> artstation: www.artstation.com/jbruno
>>>>
>>>> If you all agree to work with him, I will start the process. Here is
>>>> how it is going to look like:
>>>>
>>>>
>>>>1.
>>>>
>>>>Julian will be sending us a series of sketches of the firefly in
>>>>the dev@ list, iterating on the version that we like the most
>>>>2.
>>>>
>>>>If the sketches meet the community’s expectations, he will continue
>>>>polishing the final design
>>>>3.
>>>>
>>>>Once the design has been approved, he will give the final touches
>>>>to it and send us raw files containing the character on whichever file
>>>>format we want
>>>>
>>>>
>>>> What do you all think?
>>>>
>>>>
>>>> On Fri, Jan 3, 2020 at 9:33 PM Kenneth Knowles  wrote:
>>>>
>>>>> I am happy to announce that this vote has passed, with 20 approving +1
>>>>> votes, 5 of which are binding PMC votes.
>>>>>
>>>>> Beam's Mascot is the Firefly!
>>>>>
>>>>> Kenn
>>>>>
>>>>> On Fri, Jan 3, 2020 at 9:31 PM Kenneth Knowles 
>>>>> wrote:
>>>>>
>>>>>> +1 (binding)
>>>>>>
>>>>>> On Tue, Dec 17, 2019 at 12:30 PM Leonardo Miguel <
>>>>>> leonardo.mig...@arquivei.com.br> wrote:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> Em sex., 13 de dez. de 2019 às 01:58, Kenneth Knowles <
>>>>>>> k...@apache.org> escreveu:
>>>>>>>
>>>>>>>> Please vote on the proposal for Beam's mascot to be the Firefly.
>>>>>>>> This encompasses the Lampyridae family of insects, without specifying a
>>>>>>>> genus or species.
>>>>>>>>
>>>>>>>> [ ] +1, Approve Firefly being the mascot
>>>>>>>> [ ] -1, Disapprove Firefly being the mascot
>>>>>>>>
>>>>>>>> The vote will be open for at least 72 hours excluding weekends. It
>>>>>>>> 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)"
>>>>>>>>
>>>>>>>> Kenn
>>>>>>>>
>>>>>>>> *I have chosen this format for this vote, even though Beam uses
>>>>>>>> simple majority as a rule, because I want any PMC member to be able to 
>>>>>>>> veto
>>>>>>>> based on concerns about overlap or trademark.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> []s
>>>>>>>
>>>>>>> Leonardo Alves Miguel
>>>>>>> Data Engineer
>>>>>>> (16) 3509-5515 | www.arquivei.com.br
>>>>>>> <https://arquivei.com.br/?utm_campaign=assinatura-email_content=assinatura>
>>>>>>> [image: Arquivei.com.br – Inteligência em Notas Fiscais]
>>>>>>> <https://arquivei.com.br/?utm_campaign=assinatura-email_content=assinatura>
>>>>>>> [image: Google seleciona Arquivei para imersão e mentoria no Vale do
>>>>>>> Silício]
>>>>>>> <https://arquivei.com.br/blog/google-seleciona-arquivei/?utm_campaign=assinatura-email-launchpad_content=assinatura-launchpad>
>>>>>>> <https://www.facebook.com/arquivei>
>>>>>>> <https://www.linkedin.com/company/arquivei>
>>>>>>> <https://www.youtube.com/watch?v=KJFrh8h4Zds%3Acc=on>
>>>>>>>
>>>>>>

Re: [RESULT] [VOTE] Beam's Mascot will be the Firefly (Lampyridae)

[Aizhamal Nurmamat kyzy]

Thanks Kenn for running the vote!

I had reached out to a couple designers that I know personally and few in
the community to see whether they were willing to contribute the designs.

Julian was one of them, who agreed to work with us for a reasonable fee
which can be donated by Google. Julian is a very talented visual artist and
creates really cool animations too (if we want our Firefly to fly).

Here is more about Julian’s work:

2D reel : https://youtu.be/2miCzKbuook

linkedin: www.linkedin.com/in/julianbruno

artstation: www.artstation.com/jbruno

If you all agree to work with him, I will start the process. Here is how it
is going to look like:


   1.

   Julian will be sending us a series of sketches of the firefly in the dev@
   list, iterating on the version that we like the most
   2.

   If the sketches meet the community’s expectations, he will continue
   polishing the final design
   3.

   Once the design has been approved, he will give the final touches to it
   and send us raw files containing the character on whichever file format we
   want


What do you all think?


On Fri, Jan 3, 2020 at 9:33 PM Kenneth Knowles  wrote:

> I am happy to announce that this vote has passed, with 20 approving +1
> votes, 5 of which are binding PMC votes.
>
> Beam's Mascot is the Firefly!
>
> Kenn
>
> On Fri, Jan 3, 2020 at 9:31 PM Kenneth Knowles  wrote:
>
>> +1 (binding)
>>
>> On Tue, Dec 17, 2019 at 12:30 PM Leonardo Miguel <
>> leonardo.mig...@arquivei.com.br> wrote:
>>
>>> +1
>>>
>>> Em sex., 13 de dez. de 2019 às 01:58, Kenneth Knowles 
>>> escreveu:
>>>
 Please vote on the proposal for Beam's mascot to be the Firefly. This
 encompasses the Lampyridae family of insects, without specifying a genus or
 species.

 [ ] +1, Approve Firefly being the mascot
 [ ] -1, Disapprove Firefly being the mascot

 The vote will be open for at least 72 hours excluding weekends. It 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)"

 Kenn

 *I have chosen this format for this vote, even though Beam uses simple
 majority as a rule, because I want any PMC member to be able to veto based
 on concerns about overlap or trademark.

>>>
>>>
>>> --
>>> []s
>>>
>>> Leonardo Alves Miguel
>>> Data Engineer
>>> (16) 3509-5515 | www.arquivei.com.br
>>> 
>>> [image: Arquivei.com.br – Inteligência em Notas Fiscais]
>>> 
>>> [image: Google seleciona Arquivei para imersão e mentoria no Vale do
>>> Silício]
>>> 
>>> 
>>> 
>>> 
>>>
>>

Re: [VOTE] Beam Mascot animal choice: vote for as many as you want

[Aizhamal Nurmamat kyzy]

esults :)
>>>>>>>
>>>>>>
>>>>>> Generally decisions, especially votes, for apache projects are
>>>>>> supposed to happen on-list. I suppose this is more an advisory vote, but
>>>>>> still probably makes sense to keep it here. .
>>>>>>
>>>>>
>>>>> Indeed. Someone suggested a Google form before I started this, but I
>>>>> deliberately didn't use it. It doesn't add much and it puts the vote off
>>>>> list onto opaque and mutable third party infrastructure.
>>>>>
>>>>> If you voted on the form, please repeat it on thread so I can count it.
>>>>>
>>>>> Kenn
>>>>>
>>>>>
>>>>>
>>>>> import collections, pprint, re, requests
>>>>>> thread = requests.get('
>>>>>> https://lists.apache.org/api/thread.lua?id=ff60eabbf8349ba6951633869000356c2c2feb48bbff187cf3c60039@%3Cdev.beam.apache.org%3E').json(
>>>>>> )
>>>>>> counts = collections.defaultdict(int)
>>>>>> for email in thread['emails']:
>>>>>>   body = requests.get('https://lists.apache.org/api/email.lua?id=%s'
>>>>>> % email['mid']).json()['body']
>>>>>>   for vote in re.findall(r'\n\s*\[\s*[xX]\s*\]\s*([a-zA-Z ]+)', body):
>>>>>> counts[vote] += 1
>>>>>>   pprint.pprint(sorted(counts.items(), key=lambda kv: kv[-1]))
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> [('Beaver', 1),
>>>>>>
>>>>>>  ('Capybara', 2),
>>>>>>
>>>>>>  ('Trout', 2),
>>>>>>
>>>>>>  ('Salmon', 4),
>>>>>>
>>>>>>  ('Dumbo Octopus', 7),
>>>>>>
>>>>>>  ('Robot dinosaur', 9),
>>>>>>
>>>>>>  ('Hedgehog', 10),
>>>>>>
>>>>>>  ('Cuttlefish', 11),
>>>>>>
>>>>>>  ('Angler fish', 12),
>>>>>>
>>>>>>  ('Lemur', 14),
>>>>>>
>>>>>>  ('Owl', 15),
>>>>>>
>>>>>>  ('Firefly', 17)]
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 21, 2019 at 6:18 PM Vinay Mayar <
>>>>>>> vinay.ma...@expanseinc.com> wrote:
>>>>>>>
>>>>>>>> [ ] Beaver
>>>>>>>> [ ] Hedgehog
>>>>>>>> [ ] Lemur
>>>>>>>> [ ] Owl
>>>>>>>> [ ] Salmon
>>>>>>>> [ ] Trout
>>>>>>>> [ ] Robot dinosaur
>>>>>>>> [ ] Firefly
>>>>>>>> [ ] Cuttlefish
>>>>>>>> [x] Dumbo Octopus
>>>>>>>> [ ] Angler fish
>>>>>>>>
>>>>>>>> On Thu, Nov 21, 2019 at 6:14 PM Chamikara Jayalath <
>>>>>>>> chamik...@google.com> wrote:
>>>>>>>>
>>>>>>>>> [X] Beaver
>>>>>>>>> [ ] Hedgehog
>>>>>>>>> [ ] Lemur
>>>>>>>>> [X] Owl
>>>>>>>>> [ ] Salmon
>>>>>>>>> [ ] Trout
>>>>>>>>> [ ] Robot dinosaur
>>>>>>>>> [ ] Firefly
>>>>>>>>> [X ] Cuttlefish
>>>>>>>>> [X ] Dumbo Octopus
>>>>>>>>> [ X] Angler fish
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Cham
>>>>>>>>>
>>>>>>>>> On Thu, Nov 21, 2019 at 1:43 PM Michał Walenia <
>>>>>>>>> michal.wale...@polidea.com> wrote:
>>>>>>>>>
>>>>>>>>>> [X] Beaver
>>>>>>>>>> [ ] Hedgehog
>>>>>>>>>> [X] Lemur
>>>>>>>>>> [X] Owl
>>>>>>>>>> [ ] Salmon
>>>>>>>>>> [ ] Trout
>>>>>>>>>> [X] Robot dinosaur
>>>>>>>>>> [X] Firefly
>>>>>>>>>> [ ] Cuttlefish
>>>>>>>>>> [ ] Dumbo Octopus
>>>&g

Re: [Discuss] Beam Summit 2020 Dates & locations

[Aizhamal Nurmamat kyzy]

Maria put together this documents with related industry conferences [1], it
would make sense to choose a time that doesn't conflict with other events
around projects close to Beam.

How about for June 21-22 (around Spark Summit) for North America, and
October 5-6 or October 12-13 for Europe?

[1]
https://docs.google.com/spreadsheets/d/1LQv95XP9UPhZjGqcMA8JksfcAure-fAp4h3TTjaafRs/edit#gid=1680445982

On Tue, Nov 12, 2019 at 4:45 PM Udi Meiri  wrote:

> +1 for better organization. I would have gone to ApacheCon LV had I known
> there was going to be a Beam summit there.
>
> On Tue, Nov 12, 2019 at 9:31 AM Alexey Romanenko 
> wrote:
>
>> On 8 Nov 2019, at 11:32, Maximilian Michels  wrote:
>> >
>> > The dates sounds good to me. I agree that the bay area has an advantage
>> because of its large tech community. On the other hand, it is a question of
>> how we run the event. For Berlin we managed to get about 200 attendees to
>> Berlin, but for the BeamSummit in Las Vegas with ApacheCon the attendance
>> was much lower.
>>
>> I agree with your point Max and I believe that it would be more efficient
>> to run Beam Summit as a “standalone" event (as it was done in London and
>> Berlin) which will allow us to attract mostly
>> Beam-oriented/interested/focused audience comparing to running this as part
>> of ApacheCon or any other large conferences where are many other different
>> topics and tracks.
>>
>> > Should this also be discussed on the user mailing list?
>>
>> Definitively! Despite the fact that users opinion is a key point here, it
>> will not be so easy to get not-biased statistics in this question.
>>
>> The time frames are also very important since holidays in different
>> countries (for example, August is traditionally a "vacation month" in
>> France and some other European countries) can effect people availability
>> and influent the final number of participants in the end.
>>
>> >
>> > Cheers,
>> > Max
>> >
>> > On 07.11.19 22:50, Alex Van Boxel wrote:
>> >> For date wise, I'm wondering why we should switching the Europe and NA
>> one, this would mean that the Berlin and the new EU summit would be almost
>> 1.5 years apart.
>> >>  _/
>> >> _/ Alex Van Boxel
>> >> On Thu, Nov 7, 2019 at 8:43 PM Ahmet Altay > al...@google.com>> wrote:
>> >>I prefer bay are for NA summit. My reasoning is that there is a
>> >>criticall mass of contributors and users in that location, probably
>> >>more than alternative NA locations. I was not involved with planning
>> >>recently and I do not know if there were people who could attend due
>> >>to location previously. If that is the case, I agree with Elliotte
>> >>on looking for other options.
>> >>Related to dates: March (Asia) and mid-May (NA) dates are a bit
>> >>close. Mid-June for NA might be better to spread events. Other
>> >>pieces looks good.
>> >>Ahmet
>> >>On Thu, Nov 7, 2019 at 7:09 AM Elliotte Rusty Harold
>> >>mailto:elh...@ibiblio.org>> wrote:
>> >>The U.S. sadly is not a reliable destination for international
>> >>conferences these days. Almost every conference I go to, big and
>> >>small, has at least one speaker, sometimes more, who can't get
>> into
>> >>the country. Canada seems worth considering. Vancouver,
>> >>Montreal, and
>> >>Toronto are all convenient.
>> >>On Wed, Nov 6, 2019 at 2:17 PM Griselda Cuevas > >>> wrote:
>> >> >
>> >> > Hi Beam Community!
>> >> >
>> >> > I'd like to kick off a thread to discuss potential dates and
>> >>venues for the 2020 Beam Summits.
>> >> >
>> >> > I did some research on industry conferences happening in 2020
>> >>and pre-selected a few ranges as follows:
>> >> >
>> >> > (2 days) NA between mid-May and mid-June
>> >> > (2 days) EU mid October
>> >> > (1 day) Asia Mini Summit:  March
>> >> >
>> >> > I'd like to hear your thoughts on these dates and get
>> >>consensus on exact dates as the convo progresses.
>> >> >
>> >> > For locations these are the options I reviewed:
>> >> >
>> >> > NA: Austin Texas, Berkeley California, Mexico City.
>> >> > Europe: Warsaw, Barcelona, Paris
>> >> > Asia: Singapore
>> >> >
>> >> > Let the discussion begin!
>> >> > G (on behalf of the Beam Summit Steering Committee)
>> >> >
>> >> >
>> >> >
>> >>-- Elliotte Rusty Harold
>> >>elh...@ibiblio.org 
>>
>>

Re: [VOTE] Beam Mascot animal choice: vote for as many as you want

[Aizhamal Nurmamat kyzy]

[ ] Beaver
[X] Hedgehog
[ ] Lemur
[ ] Owl
[ ] Salmon
[ ] Trout
[ ] Robot dinosaur
[ ] Firefly
[X] Cuttlefish
[ ] Dumbo Octopus
[ ] Angler fish

On Thu, Nov 21, 2019 at 11:21 AM Robert Burke  wrote:

> [ X] Beaver
> [] Hedgehog
> [ x] Lemur
> [ X] Owl
> [ ] Salmon
> [ ] Trout
> [ ] Robot dinosaur
> [X ] Firefly
> [ X] Cuttlefish
> [x ] Dumbo Octopus
> [X ] Angler fish
>
> On Thu, Nov 21, 2019, 9:33 AM Łukasz Gajowy 
> wrote:
>
>> [ ] Beaver
>> [ ] Hedgehog
>> [x] Lemur
>> [x] Owl
>> [ ] Salmon
>> [ ] Trout
>> [x] Robot dinosaur!
>> [ ] Firefly
>> [ ] Cuttlefish
>> [ ] Dumbo Octopus
>> [ ] Angler fish
>>
>> czw., 21 lis 2019 o 00:44 Augustin Lafanechere <
>> augustin.lafanech...@kapten.com> napisał(a):
>>
>>> [ ] Beaver
>>> [ ] Hedgehog
>>> [ ] Lemur
>>> [ ] Owl
>>> [x] Salmon
>>> [ ] Trout
>>> [ ] Robot dinosaur
>>> [ ] Firefly
>>> [ ] Cuttlefish
>>> [ ] Dumbo Octopus
>>> [x ] Angler fish
>>>
>>> > Le 20 nov. 2019 à 13:38, Maximilian Michels  a écrit :
>>> >
>>> > [ ] Beaver
>>> > [ ] Hedgehog
>>> > [x] Lemur
>>> > [ ] Owl
>>> > [ ] Salmon
>>> > [ ] Trout
>>> > [ ] Robot dinosaur
>>> > [x] Firefly
>>> > [x] Cuttlefish
>>> > [ ] Dumbo Octopus
>>> > [x] Angler fish
>>> >
>>> > On 20.11.19 08:18, Alex Van Boxel wrote:
>>> >> [ ] Beaver
>>> >> [ ] Hedgehog
>>> >> [ ] Lemur
>>> >> [ ] Owl
>>> >> [ ] Salmon
>>> >> [ ] Trout
>>> >> [ ] Robot dinosaur
>>> >> [ X] Firefly
>>> >> [ ] Cuttlefish
>>> >> [ ] Dumbo Octopus
>>> >> [ X] Angler fish
>>> >>  _/
>>> >> _/ Alex Van Boxel
>>> >> On Wed, Nov 20, 2019 at 3:57 AM Reza Rokni >> r...@google.com>> wrote:
>>> >>[ ] Beaver
>>> >>[ ] Hedgehog
>>> >>[ ] Lemur
>>> >>[ ] Owl
>>> >>[X] Salmon
>>> >>[ ] Trout
>>> >>[ ] Robot dinosaur
>>> >>[ ] Firefly
>>> >>[ ] Cuttlefish
>>> >>[X] Dumbo Octopus
>>> >>[X] Angler fish
>>> >>On Wed, 20 Nov 2019 at 10:43, Kenneth Knowles >> >>> wrote:
>>> >>Please cast your votes of approval [1] for animals you would
>>> >>support as Beam mascot. The animal with the most approval will
>>> >>be identified as the favorite.
>>> >>*** Vote for as many as you like, using this checklist as a
>>> >>template 
>>> >>[ ] Beaver
>>> >>[ ] Hedgehog
>>> >>[ ] Lemur
>>> >>[ ] Owl
>>> >>[ ] Salmon
>>> >>[ ] Trout
>>> >>[ ] Robot dinosaur
>>> >>[ ] Firefly
>>> >>[ ] Cuttlefish
>>> >>[ ] Dumbo Octopus
>>> >>[ ] Angler fish
>>> >>This vote will remain open for at least 72 hours.
>>> >>Kenn
>>> >>[1] See
>>> >>https://en.wikipedia.org/wiki/Approval_voting#Description and
>>> >>https://www.electionscience.org/library/approval-voting/
>>> >>-- This email may be confidential and privileged. If you
>>> received this
>>> >>communication by mistake, please don't forward it to anyone else,
>>> >>please erase all copies and attachments, and please let me know
>>> that
>>> >>it has gone to the wrong person.
>>> >>The above terms reflect a potential business arrangement, are
>>> >>provided solely as a basis for further discussion, and are not
>>> >>intended to be and do not constitute a legally binding obligation.
>>> >>No legally binding obligations will be created, implied, or
>>> inferred
>>> >>until an agreement in final form is executed in writing by all
>>> >>parties involved.
>>>
>>>

Re: [ANNOUNCE] New committer: Daniel Oliveira

[Aizhamal Nurmamat kyzy]

Congratulations, Daniel!!!

On Thu, Nov 21, 2019 at 2:17 AM Connell O'Callaghan 
wrote:

> Well done - congratulations Daniel!!!
> Kenn thank you for sharing!!!
>
> On Thu, Nov 21, 2019 at 1:32 AM Robin Qiu  wrote:
>
>> Congrats, Daniel!
>>
>> On Thu, Nov 21, 2019 at 10:11 AM Gleb Kanterov  wrote:
>>
>>> Congratulations!
>>>
>>> On Thu, Nov 21, 2019 at 6:24 AM Thomas Weise  wrote:
>>>
 Congratulations!


 On Wed, Nov 20, 2019, 7:56 PM Chamikara Jayalath 
 wrote:

> Congrats!!
>
> On Wed, Nov 20, 2019 at 5:21 PM Daniel Oliveira <
> danolive...@google.com> wrote:
>
>> Thank you everyone! I won't let you down. o7
>>
>> On Wed, Nov 20, 2019 at 2:12 PM Ruoyun Huang 
>> wrote:
>>
>>> Congrats Daniel!
>>>
>>> On Wed, Nov 20, 2019 at 1:58 PM Robert Burke 
>>> wrote:
>>>
 Congrats Daniel! Much deserved.

 On Wed, Nov 20, 2019, 12:49 PM Udi Meiri  wrote:

> Congrats Daniel!
>
> On Wed, Nov 20, 2019 at 12:42 PM Kyle Weaver 
> wrote:
>
>> Congrats Dan! Keep up the good work :)
>>
>> On Wed, Nov 20, 2019 at 12:41 PM Cyrus Maden 
>> wrote:
>>
>>> Congratulations! This is great news.
>>>
>>> On Wed, Nov 20, 2019 at 3:24 PM Rui Wang 
>>> wrote:
>>>
 Congrats!


 -Rui

 On Wed, Nov 20, 2019 at 11:48 AM Valentyn Tymofieiev <
 valen...@google.com> wrote:

> Congrats, Daniel!
>
> On Wed, Nov 20, 2019 at 11:47 AM Kenneth Knowles <
> k...@apache.org> wrote:
>
>> Hi all,
>>
>> Please join me and the rest of the Beam PMC in welcoming a
>> new committer: Daniel Oliveira
>>
>> Daniel introduced himself to dev@ over two years ago and has
>> contributed in many ways since then. Daniel has contributed to 
>> general
>> project health, the portability framework, and all three 
>> languages: Java,
>> Python SDK, and Go. I would like to particularly highlight how 
>> he deleted
>> 12k lines of dead reference runner code [1].
>>
>> In consideration of Daniel's contributions, the Beam PMC
>> trusts him with the responsibilities of a Beam committer [2].
>>
>> Thank you, Daniel, for your contributions and looking forward
>> to many more!
>>
>> Kenn, on behalf of the Apache Beam PMC
>>
>> [1] https://github.com/apache/beam/pull/8380
>> [2]
>> https://beam.apache.org/contribute/become-a-committer/#an-apache-beam-committer
>>
>
>>>
>>> --
>>> 
>>> Ruoyun  Huang
>>>
>>>

Re: [Discuss] Beam mascot

[Aizhamal Nurmamat kyzy]

That last sketch of a cuttlefish with a hat is really really good. I vote
for that.

On Fri, Nov 15, 2019 at 10:33 AM Kenneth Knowles  wrote:

> PSA: cuttlefish tentacles look more like their face, not their legs.
> Please find attached illustrations to that effect. And also evidence that
> they are occasionally fancy. Definitely *not* from a respectable designer
> or anyone who could execution a professional logo.
>
> I do think the PMC needs to shepherd this. I would suggest starting with
> an approval vote [1] for animal (no plant ideas?) and then an ASF-style
> vote to record the validated result. From there, we can go through more
> standard design process.
>
> Kenn
>
> [1] https://www.electionscience.org/library/approval-voting/
>
> On Fri, Nov 15, 2019 at 6:54 AM Maximilian Michels  wrote:
>
>> It's great we're having this discussion and we came up with a lot of
>> great ideas through it. However, it is unclear how we proceed from here.
>> Certainly, we can't let designers work with an open-ended discussion on
>> the type of mascot.
>>
>> Personally, I'm fine with _any_ kind of mascot, as long as it is made by
>> a decent designer. The respectable designer I'm talking to was very
>> generous to donate these sketches for free. I don't think that this is
>> to be expected at all. Coming back to the original idea of hiring
>> multiple designers, I don't see how we will pay those designers to all
>> come up with a logo, unless we all donate money.
>>
>> The sketches I've sent might not look like much because there is still a
>> decent process involved in coming up with the final logo which looks
>> good in different sizes, possibly with many iterations. So far I've
>> tried to incorporate as many of the suggestions here, but for the sake
>> of protecting the designer, I think I'll have to stop doing that. It
>> simply won't work.
>>
>> How to proceed from here? I think _any_ professionally executed logo
>> will do, this is really more about the community agreeing for the
>> greater good. Ultimately, I think the PMC might have to decide on how to
>> proceed here.
>>
>> Cheers,
>> Max
>>
>> On 15.11.19 13:59, Hannah Jiang wrote:
>> > I also vote for firefly.
>> >
>> > On Wed, Nov 13, 2019 at 1:38 PM Valentyn Tymofieiev <
>> valen...@google.com
>> > > wrote:
>> >
>> > I like the firefly sketch a lot, it's my favorite so far.
>> >
>> > On Wed, Nov 13, 2019 at 12:58 PM Robert Bradshaw
>> > mailto:rober...@google.com>> wrote:
>> >
>> > #37 from the sketches was the cuttlefish, which would put it at
>> > (with
>> > 4 votes) the most popular so far. I do like the firefly too.
>> >
>> > On Wed, Nov 13, 2019 at 12:03 PM Gris Cuevas > > > wrote:
>> >  >
>> >  > 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=ACYBGNTFW6vq76cHp05g4vBaR-SVJNI1iw:1573674471669=lnms=isch=X=0ahUKEwiTwICf-uflAhUKHqwKHVtzAykQ_AUIEigB=1440=735
>> >  

Re: [Discuss] Beam mascot

[Aizhamal Nurmamat kyzy]

52 and 37 for me. I don't know what 53 is, but I like it too.


On Tue, Nov 12, 2019 at 9:19 AM Maximilian Michels  wrote:

> More logos :D
>
> (35) - (37), (51), (48), (53) go into the direction of cuttlefish.
>
>  From the new ones I like (52) because of the eyes. (53) If we want to
> move into the direction of a water animal, the small ones are quite
> recognizable. Also, (23) and (36) are kinda cute.
>
> Cheers,
> Max
>
> On 12.11.19 02:09, Robert Bradshaw wrote:
> > Cuttlefish are cool, but I don't know how recognizable they are, and
> > they don't scream "fast" or "stream-y" or "parallel processing" to me
> > (not that that's a requirement...) I like that firefly, nice working
> > the logo into the trailing beam of light.
> >
> > On Mon, Nov 11, 2019 at 5:03 PM Udi Meiri  wrote:
> >>
> >> Dumbo octopus anyone? https://youtu.be/DmqikqvLLLw?t=263
> >>
> >>
> >> On Mon, Nov 11, 2019 at 2:06 PM Luke Cwik  wrote:
> >>>
> >>> The real answer, what cool schwag can we get based upon the mascot.
> >>>
> >>> On Mon, Nov 11, 2019 at 2:04 PM Kenneth Knowles 
> wrote:
> >>>>
> >>>> I'm with Luke on cuttlefish. We can have color changing schwag...
> >>>>
> >>>> On Mon, Nov 11, 2019 at 9:57 AM David Cavazos 
> wrote:
> >>>>>
> >>>>> I like 9 as well. Not related to anything, but chinchillas are also
> cute.
> >>>>>
> >>>>> On Mon, Nov 11, 2019 at 8:25 AM Luke Cwik  wrote:
> >>>>>>
> >>>>>> 9 and 7 for me (in that order)
> >>>>>>
> >>>>>> On Mon, Nov 11, 2019 at 7:18 AM Maximilian Michels 
> wrote:
> >>>>>>>
> >>>>>>> Here are some sketches from the designer. I've put them all in one
> image
> >>>>>>> and added labels to make it easier to refer to them. My favorites
> are
> >>>>>>> (2) and (9).
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Max
> >>>>>>>
> >>>>>>> On 09.11.19 19:43, Maximilian Michels wrote:
> >>>>>>>> I like that sketch! The designer has also sent me some rough
> sketches,
> >>>>>>>> I'll share these here when I get consent from the designer.
> >>>>>>>>
> >>>>>>>> -Max
> >>>>>>>>
> >>>>>>>> On 09.11.19 19:22, Alex Van Boxel wrote:
> >>>>>>>>> +1 for a FireFly. Ok, I can't draw, but it's to make a point ;-)
> >>>>>>>>>
> >>>>>>>>> Fire2.jpg
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>_/
> >>>>>>>>> _/ Alex Van Boxel
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Sat, Nov 9, 2019 at 12:26 AM Kyle Weaver  >>>>>>>>> <mailto:kcwea...@google.com>> wrote:
> >>>>>>>>>
> >>>>>>>>>  Re fish: The authors of the Streaming Systems went with
> trout, but
> >>>>>>>>>  the book mentioned a missed opportunity to make their cover
> a "robot
> >>>>>>>>>  dinosaur with a Scottish accent." Perhaps that idea is worth
> >>>>>>>>> revisiting?
> >>>>>>>>>
> >>>>>>>>>  On Fri, Nov 8, 2019 at 3:20 PM Luke Cwik  >>>>>>>>>  <mailto:lc...@google.com>> wrote:
> >>>>>>>>>
> >>>>>>>>>  My top suggestion is a cuttlefish.
> >>>>>>>>>
> >>>>>>>>>  On Thu, Nov 7, 2019 at 10:28 PM Reza Rokni <
> r...@google.com
> >>>>>>>>>  <mailto:r...@google.com>> wrote:
> >>>>>>>>>
> >>>>>>>>>  Salmon... they love streams? :-)
> >>>>>>>>>
> >>>>>>>>>  On Fri, 8 Nov 2019 at 12:00, Kenneth Knowles
> >>>>>>>>>  mailto:k...@apache.org>> wrote:
> >>

Re: [Discuss] Beam mascot

[Aizhamal Nurmamat kyzy]

Aww.. that Hoover beaver is cute. But then lemur is also "taken" [1] and
the owl too [2].

Personally, I don't think it matters much which mascots are taken, as long
as the project is not too close in the same space as Beam. Also, it's good
to just get all ideas out. We should still consider hedgehogs. I looked up
fireflies, they don't look nice, but i am not dismissing the idea :/

And thanks for reaching out to designers, Max. To your point:
>how do we arrive at a concrete design
>once we have consensus on the type of mascot?
My thinking is that the designer will come up with few sketches, then we
vote on one here in the dev@ list.

[1]
https://www.nginx.com/blog/introducing-the-lemur-stack-and-an-official-nginx-mascot/
[2] https://blog.readme.io/why-every-startup-needs-a-mascot/

On Tue, Nov 5, 2019 at 5:31 AM Maximilian Michels  wrote:

> Quick update: The mentioned designer has gotten back to me and offered
> to sketch something until the end of the week. I've pointed him to this
> thread and the existing logo material:
> https://beam.apache.org/community/logos/
>
> [I don't want to interrupt the discussion in any way, I just think
> having something concrete will help us to eventually decide what we want.]
>
> On 05.11.19 12:49, Maximilian Michels wrote:
> > How about fireflies in the Beam light rays? ;)
> >
> >> Feels like "Beam" would go well with an animal that has glowing bright
> >> eyes such as a lemur
> >
> > I love the lemur idea because it has almost orange eyes.
> >
> > Thanks for starting this Aizhamal! I've recently talked to a designer
> > which is somewhat famous for creating logos. He was inclined to work on
> > a software project logo. Of course there is a little bit of a price tag
> > attached, though the quote sounded reasonable.
> >
> > It raises the general question, how do we arrive at a concrete design
> > once we have consensus on the type of mascot? I believe there are also
> > designers working at companies using Beam ;)
> >
> > Cheers,
> > Max
> >
> > On 05.11.19 06:14, Eugene Kirpichov wrote:
> >> Feels like "Beam" would go well with an animal that has glowing bright
> >> eyes (with beams of light shooting out of them), such as a lemur [1]
> >> or an owl.
> >>
> >> [1] https://www.cnn.com/travel/article/madagascar-lemurs/index.html
> >>
> >> On Mon, Nov 4, 2019 at 7:33 PM Kenneth Knowles  >> <mailto:k...@apache.org>> wrote:
> >>
> >> Yes! Let's have a mascot!
> >>
> >> Direct connections often have duplicates. For example in the log
> >> processing space, there is https://www.linkedin.com/in/hooverbeaver
> >>
> >> I like a flying squirrel, but Flink already is a squirrel.
> >>
> >> Hedgehog? I could not find any source of confusion for this one.
> >>
> >> Kenn
> >>
> >>
> >> On Mon, Nov 4, 2019 at 6:02 PM Robert Burke  >> <mailto:rob...@frantil.com>> wrote:
> >>
> >> As both a Canadian, and the resident fan of a programming
> >> language with a rodent mascot, I endorse this mascot.
> >>
> >> On Mon, Nov 4, 2019, 4:11 PM David Cavazos  >> <mailto:dcava...@google.com>> wrote:
> >>
> >> I like it, a beaver could be a cute mascot :)
> >>
> >> On Mon, Nov 4, 2019 at 3:33 PM Aizhamal Nurmamat kyzy
> >> mailto:aizha...@apache.org>> wrote:
> >>
> >> Hi everybody,
> >>
> >> I think the idea of creating a Beam mascot has been
> >> brought up a couple times here in the past, but I would
> >> like us to go through with it this time if we are all in
> >> agreement:)
> >>
> >> We can brainstorm in this thread what the mascot should
> >> be given Beam’s characteristics and principles. What do
> >> you all think?
> >>
> >> For example, I am proposing a beaver as a mascot,
> >> because:
> >> 1. Beavers build dams out of logs for streams
> >> 2. The name is close to Beam
> >> 3. And with the right imagination, you can make a really
> >> cute beaver :D https://imgur.com/gallery/RLo05M9
> >>
> >> WDYT? If you don’t like the beaver, what are the other
> >> op

[Discuss] Beam mascot

[Aizhamal Nurmamat kyzy]

Hi everybody,

I think the idea of creating a Beam mascot has been brought up a couple
times here in the past, but I would like us to go through with it this time
if we are all in agreement:)

We can brainstorm in this thread what the mascot should be given Beam’s
characteristics and principles. What do you all think?

For example, I am proposing a beaver as a mascot, because:
1. Beavers build dams out of logs for streams
2. The name is close to Beam
3. And with the right imagination, you can make a really cute beaver :D
https://imgur.com/gallery/RLo05M9

WDYT? If you don’t like the beaver, what are the other options that you
think could be appropriate? I would like to invite others to propose ideas
and get the discussions going.

Thanks,
Aizhamal

Re: [Discuss] Ideas for Apache Beam presence in social media

[Aizhamal Nurmamat kyzy]

Thank you Matthias,

I was supposed to write up the documentation.. sorry this got slipped
through the cracks. I will prepare the PR until the end of the week.

On Tue, Oct 22, 2019, 12:51 AM Matthias Baetens 
wrote:

> Thanks Thomas.
>
> Happy to help on the doc side when I find some time :) I'll give you a
> ping when I have the PR ready!
>
> On Mon, Oct 14, 2019, 20:07 Thomas Weise  wrote:
>
>> Matthias,
>>
>> The process is already in use, but it would be nice to have it documented
>> also.
>>
>> I gave you edit access to the spreadsheet, since working with the
>> comments is cumbersome and sheets does not have suggestions.
>>
>> Thanks
>>
>>
>> On Fri, Oct 11, 2019 at 11:59 PM Matthias Baetens <
>> baetensmatth...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Picking up this thread, since I wanted to use this facility and help
>>> drive this if necessary.
>>>
>>> I saw the sheet has now comment access enabled. Did we decide / document
>>> the desired process on the website? I am happy to testdrive that process
>>> and submit a PR if successful.
>>>
>>> Many thanks,
>>> Matthias
>>>
>>> On Tue, 13 Aug 2019 at 01:49, Thomas Weise  wrote:
>>>
>>>> Yes, everyone should have comment access for this to make sense. Sorry
>>>> for the confusion.
>>>>
>>>>
>>>> On Mon, Aug 12, 2019 at 5:30 PM Kenneth Knowles 
>>>> wrote:
>>>>
>>>>> Thanks for setting this up. It is nice to start building up a system
>>>>> for this so everyone can participate.
>>>>>
>>>>> Regarding Jira versus notifications, how are people with only view
>>>>> access to make suggestions for tweets? When I suggested gdocs, I meant for
>>>>> everyone to have "comment" access, so then anyone can subscribe to all
>>>>> comments, which would include suggestions. This allows anyone to suggest
>>>>> tweets and anyone to subscribe to suggestions.
>>>>>
>>>>> Kenn
>>>>>
>>>>> On Wed, Aug 7, 2019 at 4:07 PM Aizhamal Nurmamat kyzy <
>>>>> aizha...@google.com> wrote:
>>>>>
>>>>>> Thanks Thomas, changed the doc to view only and granted you and Ahmet
>>>>>> edit access.
>>>>>> @all - please send requests for access with your google accounts. I
>>>>>> will update the thread once I document the process and submit the PR to 
>>>>>> the
>>>>>> website.
>>>>>>
>>>>>> Thank you,
>>>>>> Aizhamal
>>>>>>
>>>>>> On Wed, Aug 7, 2019 at 3:12 PM Thomas Weise  wrote:
>>>>>>
>>>>>>> I was able to subscribe now.
>>>>>>>
>>>>>>> Reminder for others that the spreadsheet of interest can be found
>>>>>>> here: s.apache.org/beam-tweets
>>>>>>>
>>>>>>> Aizhamal,
>>>>>>>
>>>>>>> Can you help with a couple changes to bring this closer to how
>>>>>>> similar gdoc resources are handled?
>>>>>>>
>>>>>>> * Make the document view only. *PMC members* that care to help with
>>>>>>> this can request edit access.
>>>>>>> * Document the process for other contributors. Maybe here?
>>>>>>> https://beam.apache.org/contribute/
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 7, 2019 at 2:39 PM Ahmet Altay  wrote:
>>>>>>>
>>>>>>>> I am able to subscribe to notifications now. Thomas does it work
>>>>>>>> for you?
>>>>>>>>
>>>>>>>> On Wed, Aug 7, 2019 at 2:23 PM Aizhamal Nurmamat kyzy <
>>>>>>>> aizha...@apache.org> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I set the access to 'anyone can edit'. Let me know if
>>>>>>>>> notifications work now.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> On Wed, Aug 7, 2019 at 2:00 PM A

Re: Hi

[Aizhamal Nurmamat kyzy]

Welcome Saikat!

On Sun, Oct 20, 2019, 5:55 AM Saikat Maitra  wrote:

> Hi Kenneth,
>
> Thank you, much appreciate your help.
>
> Warm regards,
> Saikat
>
> On Sat, Oct 19, 2019 at 10:40 PM Kenneth Knowles  wrote:
>
>> Welcome! I've added you to the Contributors role.
>>
>> Kenn
>>
>> On Sat, Oct 19, 2019 at 5:40 PM Saikat Maitra 
>> wrote:
>>
>>> Hi,
>>>
>>> I am Saikat and I am committer in Apache Ignite project.
>>>
>>> I am interested in joining the Apache Beam community and contribute to
>>> following Apache Ignite integration.
>>>
>>> https://issues.apache.org/jira/browse/IGNITE-7198
>>>
>>> I also wanted to get familiar with Apache Beam project and wanted to
>>> take up few open issues like below.
>>>
>>> https://issues.apache.org/jira/browse/BEAM-3658
>>>
>>> Can someone please add me in Apache Beam contributor list?
>>>
>>> Regards,
>>>
>>> Saikat
>>>
>>

Re: Feedback on how we use Apache Beam in my company

[Aizhamal Nurmamat kyzy]

Also great addition to https://github.com/pabloem/awesome-beam

On Fri, Oct 11, 2019 at 3:52 PM Pierre Vanacker <
pierre.vanac...@dailymotion.com> wrote:

> Nice, thanks. I just registered, see you there !
>
>
>
> Pierre
>
>
>
> *De : *Alexey Romanenko 
> *Répondre à : *"u...@beam.apache.org" 
> *Date : *vendredi 11 octobre 2019 à 15:29
> *À : *"u...@beam.apache.org" 
> *Cc : *dev 
> *Objet : *Re: Feedback on how we use Apache Beam in my company
>
>
>
> Hi Pierre,
>
>
>
> If you are in Paris region (I can guess because of Dailymotion name =) )
> then it would be great to chat about that at next (2nd) Paris Beam meetup,
> which will be held very soon, *October 17th*.
>
> https://www.meetup.com/Paris-Apache-Beam-Meetup/events/264545288/
> 
>
>
>
>
>
> On 11 Oct 2019, at 14:58, Pierre Vanacker 
> wrote:
>
>
>
> Thanks Etienne & Matthias !
>
>
>
> Why not, it kinda depends on the location :) What meetup / summit do you
> have in mind ?
>
>
>
> Pierre
>
>
>
> *De : *Matthias Baetens 
> *Répondre à : *"u...@beam.apache.org" 
> *Date : *vendredi 11 octobre 2019 à 09:45
> *À : *"u...@beam.apache.org" 
> *Cc : *dev 
> *Objet : *Re: Feedback on how we use Apache Beam in my company
>
>
>
> This is great, Pierre! Thank you for sharing, very interesting.
>
>
>
> Would you and your team be interested to talk about your use case at a
> meetup (or Summit) in the future? :)
>
>
>
> All the best,
>
> Matthias
>
>
>
> On Wed, 9 Oct 2019 at 15:59, Etienne Chauchot 
> wrote:
>
> Very nice !
>
> Thanks
>
> ccing dev list
>
> Etienne
>
> On 09/10/2019 16:55, Pierre Vanacker wrote:
>
> Hi Apache Beam community,
>
>
>
> We’ve been working with Apache Beam in production for a few years now in
> my company (Dailymotion).
>
>
>
> If you’re interested to know how we use Apache Beam in combination with
> Google Dataflow, we shared this experience in the following article :
> https://medium.com/dailymotion/realtime-data-processing-with-apache-beam-and-google-dataflow-at-dailymotion-7d1b994dc816
> 
>
>
>
> Thanks to the developers for your great work !
>
>
>
> Regards,
>
>
>
> Pierre
>
>
>

Re: Beam meetup Seattle!! September 26th, 6pm

[Aizhamal Nurmamat kyzy]

Gentle reminder that Seattle Apache Beam meetup is happening tomorrow!

Here is a quick agenda:
- 18:00 - Registrations, speed networking, pizza and drinks.
- 18:30 - kick-off
- 18:40 - Making Beam Schemas Portable by Brian Hulette
- 19:10 - Apache Beam @ Brightcove - A case study
- 19:40 - ZetaSQL as a SQL dialect in BeamSQL by Rui Wang
- 20:10 - Networking

Looking forward to seeing you all tomorrow :)


On Mon, Sep 23, 2019 at 11:03 AM Pablo Estrada  wrote:

> Hello everyone!
>
> If you are in the Seattle area please come to Beam meetup this Thursday,
> September 26th - at 6pm in the Google office in Fremont. There will be
> interesting talks, and there should be a number of Beam contributors and
> users around. Also pizza and drinks.
>
> The page with al the info:
> https://www.meetup.com/Seattle-Apache-Beam-Meetup/events/263845364/
>
> I hope to see a lot of you around, and will be happy to chat about all
> things Batch, Streaming, Beam, end of summer, etc.
>
> Best,
> -P.
>

Re: Beam at Google Summer of Code 2019

[Aizhamal Nurmamat kyzy]

Thank you Tanay! I hope you had a truly wonderful GSoC experience, and will
stay involved in the community for years to come :)

On Wed, Sep 4, 2019 at 10:42 AM Ahmet Altay  wrote:

> Thank you Tanay for all your contributions during summer and looking
> forward to more of it :)
>
> On Wed, Sep 4, 2019 at 10:38 AM Tanay Tummalapalli 
> wrote:
>
>> Hi everyone,
>>
>> I've completed Google Summer of Code '19[1].
>> I had fun working on Beam for the past 3 months and learning about Beam
>> internals.
>>
>> Thank you Pablo for everything! None of it would have been possible
>> without you.
>> I'd also like to thank the Beam community for the code reviews and being
>> supportive and encouraging.
>>
>> I'm moving to Bangalore this month. I'll be back to contributing to Beam
>> next month.
>>
>> Thank You
>>  - Tanay
>>
>> [1] https://gist.github.com/ttanay/80f84b7b852e0867d5a00d3b345e1dad
>>
>> On Fri, May 24, 2019 at 12:47 AM Tanay Tummalapalli 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I made a Kanban board[1] on Github, on my fork of apache/beam to keep
>>> track of progress for GSoC '19.
>>>
>>> Regards,
>>> Tanay Tummalapalli
>>>
>>> [1] https://github.com/ttanay/beam/projects/1
>>>
>>> On Tue, May 7, 2019 at 6:39 PM Tanay Tummalapalli 
>>> wrote:
>>>
 Thank You!

 I'm really excited to work on Beam!
 I'd like to thank Pablo, Chamikara Jayalath and Tim Robertson for
 helping out with my proposal[1].

 Looking forward to working with everyone and learning a great deal.

 Regards
 Tanay Tummalapalli
 LinkedIn  | Github
 

 [1]
 https://docs.google.com/document/d/15Peyd3Z_wu5rvGWw8lMLpZuTyyreM_JOAEFFWvF97YY/edit?usp=sharing

 On Tue, May 7, 2019 at 12:04 AM Pablo Estrada 
 wrote:

> Hello all,
> it is my pleasure to share with everyone that Tanay Tummalapalli has
> been accepted as a GSoC student with Beam, to implement support for File
> Loads into BigQuery for streaming pipelines[1].
>
> Tanay wrote a very strong proposal, and showed understanding of the
> tricky streaming considerations that will play out in this project.
>
> I speak on behalf of everyone welcoming you Tanay, and we'll be happy
> to see your contributions to Beam. : )
> Best
> -P.
>
> [1]
> https://summerofcode.withgoogle.com/projects/?sp-search=Tanay#4999837794172928
>