You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by María Cruz <ma...@gmail.com> on 2020/01/08 21:01:04 UTC
Re: Please comment on draft comms strategy by Oct 16
Hi everyone,
I'm writing to send an update about the communication strategy for Beam. In
a nutshell, I have 3 proposed changes (copied from the md file here:
https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
).
While all the channels are connected to a specific function in the short,
medium, and long term, some areas have redundancies, and some other areas
could use more exposure. In order to continue to grow the project, there
are 3 proposals we need to focus on (click on the link on each section to
read more):
1. Blog post categories, frequency and distribution.
<https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution>
Reduce
to one blogging space (on Beam Website). Incorporate 3 categories to the
blog: Apache Beam summit, Apache Beam use cases, and Your journey as a
contributor.
2. Develop more in-person and digital workshops.
<https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-2-develop-more-in-person-and-digital-workshops>
Two
workshop types: how to use Beam, and how to contribute to Beam.
3. Increase distribution of tech talks.
<https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-3-distribution-of-tech-talks>
- Embed tech talks in the Beam website, and the Beam Summit website,
- Share talks on @ApacheBeam Twitter handle
- Curate a list of talks by topic, and write blog posts to share curated
talks (1 blog every 3 months),
- Distribute copy via email to users@ and dev@ mailing lists.
- Create playlists on YouTube channel. Create one view for subscribed
users (featuring latest content), and one for non-subscribed users
(featuring most popular content). One playlist per event, plus 1 playlist
for use cases.
The communications plan also has a section about what to do when there is
new content about Apache Beam:
Where should I share new content about Apache Beam?
Main outreach channels
Beam Website
Beam website blog
Twitter handles (x2)
Mailing lists (x2)
Blogpost
✓
✓
✓
✓
(share first paragraph in the
email, and link to blog)
Tech talk
✓
(special section
for tech talks)
✓
(curate tech talks
quarterly in a blog)
✓
✓
(share blogs on a quarterly
basis when published)
Trainings
✓
(under section “Get started”)
✓
✓
If you have any questions or comments about this logic model, please add
them here <https://github.com/macruzbar/beam/issues/4>.
I'm happy to support in some of the proposed changes if there is interest
in moving forward with them. If there aren't any further changes requested,
I will proceed to add these files through a pull request.
Pablo, thank you for the feedback. Some comments in line.
On Mon, Dec 16, 2019 at 4:31 PM Pablo Estrada <pa...@google.com> wrote:
> Hi Maria,
> thanks for putting this together. It's large, so a bit hard to follow -
> but that's probably just an indication of the complexity of Beam's
> communication channels.
> FWIW, I found that reading from the top down was useful (or rather, from
> the top, backwards from the arrows).
>
> It is an interesting logical map. I am curious to see what we can derive
> from it : )
>
> My comments:
> - All of the factors that contribute to project transparency, when put
> together, add up to increased use of Beam, but I feel like 'increased
> knowledge of how to use beam' is the single largest contributor to that. Is
> 'knowing how to use' completely captured by transparency? (I can try to
> rephrase what I mean...)
>
This is true, we could add a direct connector between knowledge on how to
use Beam, and use of Beam. At the stage of development that the project is
at (growing), I think it is important to understand what is the value added
by all the content and events that are created around the project to
promote its use. In other words, knowing how to use the project is not the
only factor contributing to the growth in its use, because the project is
not new. Given that the project is in a growing phase, the community aspect
becomes more and more important, which is why I thought it was important to
highlight the role that transparency has in these dynamics.
> - I'm sure you've considered this, as you've received the feedback; but
> not all of these channels are 'owned' by Beam. Some of these are
> 'independently organized'. It may help to mark them as such.
>
I have considered this, and I created a second version of the comms map here
<https://github.com/macruzbar/beam/blob/master/Comms-map-V2.md>. In
developing this strategy, it is clear that all the channels (independent or
not) are working towards the same project goals, so I saw no point
in distinguishing one set from the other. Do you think there is any
specific use to have this information outlined?
- From the Artifacts section, Blog appears twice, while other artifacts
> appear only once with multiple arrows pointing at them (e.g. tech talks).
> Maybe this is on purpose, but just checking.
>
Yes, this is because there are currently 2 live blogs: one on Beam website,
and one on Beam Summit website. On the first proposal
<https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution>,
my recommendation is to reduce this to only 1 blog, with different
categories. I hope this can be implemented! =) It will work better towards
bringing new users to Beam events.
Looking forward to your thoughts / comments!
María
>
> Thanks!
> -P.
>
> On Fri, Dec 6, 2019 at 5:12 PM María Cruz <ma...@gmail.com> wrote:
>
>> Hi everyone,
>> sorry for the tardiness in responding to this, and thank you to everyone
>> who shared comments.
>> I have adjusted the initial graphic, and taken a step further to develop
>> the Apache Beam Communications Logic Model. This type of visualization is a
>> hypothesized description of the chain of causes and effects leading to an
>> outcome of interest [1]. The goal of making this graphic is to identify how
>> Apache Beam's channels and content work towards project goals.
>>
>> The logic model graphic is attached and has also been uploaded [2] to the
>> repo I've been working on. I also added it to comms-strategy-DRAFT.md [3].
>> If you have any questions or comments about this graphic, please add them
>> here [4].
>>
>> Step 3 in this process includes describing areas where we can be more
>> strategic about the content we produce for Apache Beam. I would like to
>> deliver this by December 17.
>>
>> Looking forward to your comments and feedback!
>>
>> Thanks,
>>
>> María
>>
>>
>> [1] https://en.wikipedia.org/wiki/Logic_model
>> [2] https://github.com/macruzbar/beam/blob/master/comms-logic-model.svg
>> [3]
>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>> [4] https://github.com/macruzbar/beam/issues/4
>>
>> On Wed, Oct 9, 2019 at 7:09 PM Thomas Weise <th...@apache.org> wrote:
>>
>>> It probably makes sense to separate official project channels from
>>> external ones like Beam Summit and meetups. Beam Summit is about Beam, but
>>> it is "third party" and not under the project umbrella. Operation of the
>>> youtube channel might also need clarification.
>>>
>>>
>>> On Wed, Oct 9, 2019 at 4:35 PM Robert Bradshaw <ro...@google.com>
>>> wrote:
>>>
>>>> Probably worth mentioning Slack and StackOverflow as well.
>>>>
>>>> On Wed, Oct 9, 2019 at 3:59 PM María Cruz <ma...@gmail.com> wrote:
>>>> >
>>>> > Hi all,
>>>> > sorry for multiple messages. I realized after sending the first email
>>>> that a new thread with a different subject was probably more efficient.
>>>> >
>>>> > I created a communication strategy draft. To start, I did a map of
>>>> Beam channels and content, and I have some questions for you:
>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>> >
>>>> > In order to create these files, I forked the repo. Once this looks
>>>> good, and if everyone agrees, we can merge the changes to apache/beam.
>>>> >
>>>> > I didn't assign reviewers for this file because I don't know if there
>>>> is someone who usually looks at these kinds of documents. So everyone:
>>>> please feel free to pitch in! I will give this a week for comments.
>>>> >
>>>> > Looking forward to your comments!
>>>> >
>>>> > María
>>>>
>>>
Re: Please comment on draft comms strategy by Oct 16
Posted by María Cruz <ma...@gmail.com>.
Hi Matthias,
thank you for the detailed feedback on the comms strategy. I can definitely
help with the Youtube channel revamp and social media copy to promote that
content. I will connect off-list with you about this.
All: given that we are moving forward with this strategy, I created a pull
request <https://github.com/apache/beam/pull/10958> to add this work to
Beam's repository. Please let me know if the PR is missing information.
Thanks,
María
On Tue, Feb 18, 2020 at 10:51 PM Matthias Baetens <ba...@gmail.com>
wrote:
> To make things more concrete, we could start by giving the YouTube channel
> more structure & drafting Tweets to go out on the different channels. Is
> this something you'd be able to help out with?
>
> Thanks!
> Matthias
>
> On Sun, 16 Feb 2020 at 10:29, Matthias Baetens <ba...@gmail.com>
> wrote:
>
>> Hey Maria,
>>
>> Great work!! This provides a nice overview of all the channels and how
>> they contribute to the overall project.
>>
>> I will comment on the sections I am most familiar with:
>> - Website / blog: +1 for reducing the number of outlets to 1. The Beam
>> Summit website repository could use a clean-up and this can be part of that
>> effort.
>> - Workshops: Pablo & Austin have done some great work in this space, but
>> even more dedicated time & attention to this would greatly benefit the
>> project - and as Pablo raised this might be separate from project
>> transparency but directly contribute to increased usage.
>> -- For topics/format, it's split up in how to use and how to contribute.
>> How to use I would split up in a beginner training ("set-up and write your
>> first pipeline"), advanced training ("use some of the more exotic Beam
>> features / optimise your pipeline") and office hours (solve specific
>> problems people have which can feedback to the development team as well in
>> terms of missing features or potential improvement of documentation). Imho,
>> classroom style with an intro to Beam and concepts / advanced topics,
>> combined with do-it-yourself where people actually do some coding with
>> something to walk away is good for onboarding. A more fun and game-like
>> set-up can be done for users that already use Beam where we can accommodate
>> discussions or have them solve a specific use-case in groups.
>> - +1 for increased distribution of the talks. We should actively engage
>> the speakers as well to share it on their personal channels, and surface
>> the talks on the website and Twitter handles. Also a curated list as
>> blogpost would be a great addition.
>>
>> I think a more consistent feedback mechanism and maybe idea box at events
>> might also benefit the community.
>>
>> Cheers,
>> Matthias
>>
>>
>> On Wed, 15 Jan 2020 at 22:46, Austin Bennett <wh...@gmail.com>
>> wrote:
>>
>>> Hi Kenn,
>>>
>>> We had workshop on this very topic (how to contribute to Beam) at our
>>> Berlin Summit: https://www.youtube.com/watch?v=PtPslSdAPcM There's is
>>> certainly room for me (or anyone) to cleanup and formalize that a bit
>>> more. Though, the views of that are relatively small, which either indeed
>>> points to a lack of appetite and/or that it wasn't well publicized (I
>>> suspect both).
>>>
>>> Cheers,
>>> Austin
>>>
>>> On Thu, Jan 9, 2020 at 6:53 PM Kenneth Knowles <ke...@apache.org> wrote:
>>>
>>>> Wow, this is great work. I looked at the graphical maps when you sent
>>>> them but forgot to reply on thread. They really distill a lot of
>>>> possibilities and help to think about the current state.
>>>>
>>>> These three action items seem good and doable. Thanks for highlighting
>>>> those. The only one that isn't obvious to me is "workshop on how to
>>>> contribute to Beam". Is there enough appetite / audience to make this a
>>>> workshop? What forms could this take? A live coding demonstration in a
>>>> normal talk slot at an OSS or data conference seems like a possibility.
>>>> Whatever we do, we should record and distribute for sure, because when
>>>> someone wants to contribute, they need to find the resources at that moment.
>>>>
>>>> Kenn
>>>>
>>>> On Wed, Jan 8, 2020 at 1:01 PM María Cruz <ma...@gmail.com> wrote:
>>>>
>>>>> Hi everyone,
>>>>> I'm writing to send an update about the communication strategy for
>>>>> Beam. In a nutshell, I have 3 proposed changes (copied from the md file
>>>>> here:
>>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>>> ).
>>>>>
>>>>> While all the channels are connected to a specific function in the
>>>>> short, medium, and long term, some areas have redundancies, and some other
>>>>> areas could use more exposure. In order to continue to grow the project,
>>>>> there are 3 proposals we need to focus on (click on the link on each
>>>>> section to read more):
>>>>>
>>>>> 1. Blog post categories, frequency and distribution.
>>>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution> Reduce
>>>>> to one blogging space (on Beam Website). Incorporate 3 categories to the
>>>>> blog: Apache Beam summit, Apache Beam use cases, and Your journey as a
>>>>> contributor.
>>>>>
>>>>> 2. Develop more in-person and digital workshops.
>>>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-2-develop-more-in-person-and-digital-workshops> Two
>>>>> workshop types: how to use Beam, and how to contribute to Beam.
>>>>>
>>>>> 3. Increase distribution of tech talks.
>>>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-3-distribution-of-tech-talks>
>>>>>
>>>>> - Embed tech talks in the Beam website, and the Beam Summit
>>>>> website,
>>>>> - Share talks on @ApacheBeam Twitter handle
>>>>> - Curate a list of talks by topic, and write blog posts to share
>>>>> curated talks (1 blog every 3 months),
>>>>> - Distribute copy via email to users@ and dev@ mailing lists.
>>>>> - Create playlists on YouTube channel. Create one view for
>>>>> subscribed users (featuring latest content), and one for non-subscribed
>>>>> users (featuring most popular content). One playlist per event, plus 1
>>>>> playlist for use cases.
>>>>>
>>>>> The communications plan also has a section about what to do when there
>>>>> is new content about Apache Beam:
>>>>>
>>>>>
>>>>> Where should I share new content about Apache Beam?
>>>>>
>>>>> Main outreach channels
>>>>>
>>>>> Beam Website
>>>>>
>>>>> Beam website blog
>>>>>
>>>>> Twitter handles (x2)
>>>>>
>>>>> Mailing lists (x2)
>>>>> Blogpost
>>>>>
>>>>> ✓
>>>>>
>>>>> ✓
>>>>>
>>>>> ✓
>>>>>
>>>>> ✓
>>>>> (share first paragraph in the
>>>>> email, and link to blog)
>>>>> Tech talk
>>>>>
>>>>> ✓
>>>>> (special section
>>>>> for tech talks)
>>>>>
>>>>> ✓
>>>>> (curate tech talks
>>>>> quarterly in a blog)
>>>>>
>>>>> ✓
>>>>>
>>>>> ✓
>>>>> (share blogs on a quarterly
>>>>> basis when published)
>>>>> Trainings
>>>>>
>>>>> ✓
>>>>> (under section “Get started”)
>>>>>
>>>>> ✓
>>>>>
>>>>> ✓
>>>>>
>>>>> If you have any questions or comments about this logic model, please
>>>>> add them here <https://github.com/macruzbar/beam/issues/4>.
>>>>>
>>>>> I'm happy to support in some of the proposed changes if there is
>>>>> interest in moving forward with them. If there aren't any further changes
>>>>> requested, I will proceed to add these files through a pull request.
>>>>>
>>>>>
>>>>> Pablo, thank you for the feedback. Some comments in line.
>>>>>
>>>>> On Mon, Dec 16, 2019 at 4:31 PM Pablo Estrada <pa...@google.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Maria,
>>>>>> thanks for putting this together. It's large, so a bit hard to follow
>>>>>> - but that's probably just an indication of the complexity of Beam's
>>>>>> communication channels.
>>>>>> FWIW, I found that reading from the top down was useful (or rather,
>>>>>> from the top, backwards from the arrows).
>>>>>>
>>>>>> It is an interesting logical map. I am curious to see what we can
>>>>>> derive from it : )
>>>>>>
>>>>>> My comments:
>>>>>> - All of the factors that contribute to project transparency, when
>>>>>> put together, add up to increased use of Beam, but I feel like 'increased
>>>>>> knowledge of how to use beam' is the single largest contributor to that. Is
>>>>>> 'knowing how to use' completely captured by transparency? (I can try to
>>>>>> rephrase what I mean...)
>>>>>>
>>>>>
>>>>> This is true, we could add a direct connector between knowledge on how
>>>>> to use Beam, and use of Beam. At the stage of development that the project
>>>>> is at (growing), I think it is important to understand what is the value
>>>>> added by all the content and events that are created around the project to
>>>>> promote its use. In other words, knowing how to use the project is not the
>>>>> only factor contributing to the growth in its use, because the project is
>>>>> not new. Given that the project is in a growing phase, the community aspect
>>>>> becomes more and more important, which is why I thought it was important to
>>>>> highlight the role that transparency has in these dynamics.
>>>>>
>>>>>
>>>>>> - I'm sure you've considered this, as you've received the feedback;
>>>>>> but not all of these channels are 'owned' by Beam. Some of these are
>>>>>> 'independently organized'. It may help to mark them as such.
>>>>>>
>>>>>
>>>>> I have considered this, and I created a second version of the comms
>>>>> map here
>>>>> <https://github.com/macruzbar/beam/blob/master/Comms-map-V2.md>. In
>>>>> developing this strategy, it is clear that all the channels (independent or
>>>>> not) are working towards the same project goals, so I saw no point
>>>>> in distinguishing one set from the other. Do you think there is any
>>>>> specific use to have this information outlined?
>>>>>
>>>>> - From the Artifacts section, Blog appears twice, while other
>>>>>> artifacts appear only once with multiple arrows pointing at them (e.g. tech
>>>>>> talks). Maybe this is on purpose, but just checking.
>>>>>>
>>>>>
>>>>> Yes, this is because there are currently 2 live blogs: one on Beam
>>>>> website, and one on Beam Summit website. On the first proposal
>>>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution>,
>>>>> my recommendation is to reduce this to only 1 blog, with different
>>>>> categories. I hope this can be implemented! =) It will work better towards
>>>>> bringing new users to Beam events.
>>>>>
>>>>>
>>>>>
>>>>> Looking forward to your thoughts / comments!
>>>>>
>>>>> María
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>> -P.
>>>>>>
>>>>>> On Fri, Dec 6, 2019 at 5:12 PM María Cruz <ma...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi everyone,
>>>>>>> sorry for the tardiness in responding to this, and thank you to
>>>>>>> everyone who shared comments.
>>>>>>> I have adjusted the initial graphic, and taken a step further to
>>>>>>> develop the Apache Beam Communications Logic Model. This type of
>>>>>>> visualization is a hypothesized description of the chain of causes and
>>>>>>> effects leading to an outcome of interest [1]. The goal of making this
>>>>>>> graphic is to identify how Apache Beam's channels and content work towards
>>>>>>> project goals.
>>>>>>>
>>>>>>> The logic model graphic is attached and has also been uploaded [2]
>>>>>>> to the repo I've been working on. I also added it to
>>>>>>> comms-strategy-DRAFT.md [3]. If you have any questions or comments about
>>>>>>> this graphic, please add them here [4].
>>>>>>>
>>>>>>> Step 3 in this process includes describing areas where we can be
>>>>>>> more strategic about the content we produce for Apache Beam. I would like
>>>>>>> to deliver this by December 17.
>>>>>>>
>>>>>>> Looking forward to your comments and feedback!
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> María
>>>>>>>
>>>>>>>
>>>>>>> [1] https://en.wikipedia.org/wiki/Logic_model
>>>>>>> [2]
>>>>>>> https://github.com/macruzbar/beam/blob/master/comms-logic-model.svg
>>>>>>> [3]
>>>>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>>>>> [4] https://github.com/macruzbar/beam/issues/4
>>>>>>>
>>>>>>> On Wed, Oct 9, 2019 at 7:09 PM Thomas Weise <th...@apache.org> wrote:
>>>>>>>
>>>>>>>> It probably makes sense to separate official project channels from
>>>>>>>> external ones like Beam Summit and meetups. Beam Summit is about Beam, but
>>>>>>>> it is "third party" and not under the project umbrella. Operation of the
>>>>>>>> youtube channel might also need clarification.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Oct 9, 2019 at 4:35 PM Robert Bradshaw <ro...@google.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Probably worth mentioning Slack and StackOverflow as well.
>>>>>>>>>
>>>>>>>>> On Wed, Oct 9, 2019 at 3:59 PM María Cruz <ma...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > Hi all,
>>>>>>>>> > sorry for multiple messages. I realized after sending the first
>>>>>>>>> email that a new thread with a different subject was probably more
>>>>>>>>> efficient.
>>>>>>>>> >
>>>>>>>>> > I created a communication strategy draft. To start, I did a map
>>>>>>>>> of Beam channels and content, and I have some questions for you:
>>>>>>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>>>>>>> >
>>>>>>>>> > In order to create these files, I forked the repo. Once this
>>>>>>>>> looks good, and if everyone agrees, we can merge the changes to apache/beam.
>>>>>>>>> >
>>>>>>>>> > I didn't assign reviewers for this file because I don't know if
>>>>>>>>> there is someone who usually looks at these kinds of documents. So
>>>>>>>>> everyone: please feel free to pitch in! I will give this a week for
>>>>>>>>> comments.
>>>>>>>>> >
>>>>>>>>> > Looking forward to your comments!
>>>>>>>>> >
>>>>>>>>> > María
>>>>>>>>>
>>>>>>>>
Re: Please comment on draft comms strategy by Oct 16
Posted by Matthias Baetens <ba...@gmail.com>.
To make things more concrete, we could start by giving the YouTube channel
more structure & drafting Tweets to go out on the different channels. Is
this something you'd be able to help out with?
Thanks!
Matthias
On Sun, 16 Feb 2020 at 10:29, Matthias Baetens <ba...@gmail.com>
wrote:
> Hey Maria,
>
> Great work!! This provides a nice overview of all the channels and how
> they contribute to the overall project.
>
> I will comment on the sections I am most familiar with:
> - Website / blog: +1 for reducing the number of outlets to 1. The Beam
> Summit website repository could use a clean-up and this can be part of that
> effort.
> - Workshops: Pablo & Austin have done some great work in this space, but
> even more dedicated time & attention to this would greatly benefit the
> project - and as Pablo raised this might be separate from project
> transparency but directly contribute to increased usage.
> -- For topics/format, it's split up in how to use and how to contribute.
> How to use I would split up in a beginner training ("set-up and write your
> first pipeline"), advanced training ("use some of the more exotic Beam
> features / optimise your pipeline") and office hours (solve specific
> problems people have which can feedback to the development team as well in
> terms of missing features or potential improvement of documentation). Imho,
> classroom style with an intro to Beam and concepts / advanced topics,
> combined with do-it-yourself where people actually do some coding with
> something to walk away is good for onboarding. A more fun and game-like
> set-up can be done for users that already use Beam where we can accommodate
> discussions or have them solve a specific use-case in groups.
> - +1 for increased distribution of the talks. We should actively engage
> the speakers as well to share it on their personal channels, and surface
> the talks on the website and Twitter handles. Also a curated list as
> blogpost would be a great addition.
>
> I think a more consistent feedback mechanism and maybe idea box at events
> might also benefit the community.
>
> Cheers,
> Matthias
>
>
> On Wed, 15 Jan 2020 at 22:46, Austin Bennett <wh...@gmail.com>
> wrote:
>
>> Hi Kenn,
>>
>> We had workshop on this very topic (how to contribute to Beam) at our
>> Berlin Summit: https://www.youtube.com/watch?v=PtPslSdAPcM There's is
>> certainly room for me (or anyone) to cleanup and formalize that a bit
>> more. Though, the views of that are relatively small, which either indeed
>> points to a lack of appetite and/or that it wasn't well publicized (I
>> suspect both).
>>
>> Cheers,
>> Austin
>>
>> On Thu, Jan 9, 2020 at 6:53 PM Kenneth Knowles <ke...@apache.org> wrote:
>>
>>> Wow, this is great work. I looked at the graphical maps when you sent
>>> them but forgot to reply on thread. They really distill a lot of
>>> possibilities and help to think about the current state.
>>>
>>> These three action items seem good and doable. Thanks for highlighting
>>> those. The only one that isn't obvious to me is "workshop on how to
>>> contribute to Beam". Is there enough appetite / audience to make this a
>>> workshop? What forms could this take? A live coding demonstration in a
>>> normal talk slot at an OSS or data conference seems like a possibility.
>>> Whatever we do, we should record and distribute for sure, because when
>>> someone wants to contribute, they need to find the resources at that moment.
>>>
>>> Kenn
>>>
>>> On Wed, Jan 8, 2020 at 1:01 PM María Cruz <ma...@gmail.com> wrote:
>>>
>>>> Hi everyone,
>>>> I'm writing to send an update about the communication strategy for
>>>> Beam. In a nutshell, I have 3 proposed changes (copied from the md file
>>>> here:
>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>> ).
>>>>
>>>> While all the channels are connected to a specific function in the
>>>> short, medium, and long term, some areas have redundancies, and some other
>>>> areas could use more exposure. In order to continue to grow the project,
>>>> there are 3 proposals we need to focus on (click on the link on each
>>>> section to read more):
>>>>
>>>> 1. Blog post categories, frequency and distribution.
>>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution> Reduce
>>>> to one blogging space (on Beam Website). Incorporate 3 categories to the
>>>> blog: Apache Beam summit, Apache Beam use cases, and Your journey as a
>>>> contributor.
>>>>
>>>> 2. Develop more in-person and digital workshops.
>>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-2-develop-more-in-person-and-digital-workshops> Two
>>>> workshop types: how to use Beam, and how to contribute to Beam.
>>>>
>>>> 3. Increase distribution of tech talks.
>>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-3-distribution-of-tech-talks>
>>>>
>>>> - Embed tech talks in the Beam website, and the Beam Summit website,
>>>> - Share talks on @ApacheBeam Twitter handle
>>>> - Curate a list of talks by topic, and write blog posts to share
>>>> curated talks (1 blog every 3 months),
>>>> - Distribute copy via email to users@ and dev@ mailing lists.
>>>> - Create playlists on YouTube channel. Create one view for
>>>> subscribed users (featuring latest content), and one for non-subscribed
>>>> users (featuring most popular content). One playlist per event, plus 1
>>>> playlist for use cases.
>>>>
>>>> The communications plan also has a section about what to do when there
>>>> is new content about Apache Beam:
>>>>
>>>>
>>>> Where should I share new content about Apache Beam?
>>>>
>>>> Main outreach channels
>>>>
>>>> Beam Website
>>>>
>>>> Beam website blog
>>>>
>>>> Twitter handles (x2)
>>>>
>>>> Mailing lists (x2)
>>>> Blogpost
>>>>
>>>> ✓
>>>>
>>>> ✓
>>>>
>>>> ✓
>>>>
>>>> ✓
>>>> (share first paragraph in the
>>>> email, and link to blog)
>>>> Tech talk
>>>>
>>>> ✓
>>>> (special section
>>>> for tech talks)
>>>>
>>>> ✓
>>>> (curate tech talks
>>>> quarterly in a blog)
>>>>
>>>> ✓
>>>>
>>>> ✓
>>>> (share blogs on a quarterly
>>>> basis when published)
>>>> Trainings
>>>>
>>>> ✓
>>>> (under section “Get started”)
>>>>
>>>> ✓
>>>>
>>>> ✓
>>>>
>>>> If you have any questions or comments about this logic model, please
>>>> add them here <https://github.com/macruzbar/beam/issues/4>.
>>>>
>>>> I'm happy to support in some of the proposed changes if there is
>>>> interest in moving forward with them. If there aren't any further changes
>>>> requested, I will proceed to add these files through a pull request.
>>>>
>>>>
>>>> Pablo, thank you for the feedback. Some comments in line.
>>>>
>>>> On Mon, Dec 16, 2019 at 4:31 PM Pablo Estrada <pa...@google.com>
>>>> wrote:
>>>>
>>>>> Hi Maria,
>>>>> thanks for putting this together. It's large, so a bit hard to follow
>>>>> - but that's probably just an indication of the complexity of Beam's
>>>>> communication channels.
>>>>> FWIW, I found that reading from the top down was useful (or rather,
>>>>> from the top, backwards from the arrows).
>>>>>
>>>>> It is an interesting logical map. I am curious to see what we can
>>>>> derive from it : )
>>>>>
>>>>> My comments:
>>>>> - All of the factors that contribute to project transparency, when put
>>>>> together, add up to increased use of Beam, but I feel like 'increased
>>>>> knowledge of how to use beam' is the single largest contributor to that. Is
>>>>> 'knowing how to use' completely captured by transparency? (I can try to
>>>>> rephrase what I mean...)
>>>>>
>>>>
>>>> This is true, we could add a direct connector between knowledge on how
>>>> to use Beam, and use of Beam. At the stage of development that the project
>>>> is at (growing), I think it is important to understand what is the value
>>>> added by all the content and events that are created around the project to
>>>> promote its use. In other words, knowing how to use the project is not the
>>>> only factor contributing to the growth in its use, because the project is
>>>> not new. Given that the project is in a growing phase, the community aspect
>>>> becomes more and more important, which is why I thought it was important to
>>>> highlight the role that transparency has in these dynamics.
>>>>
>>>>
>>>>> - I'm sure you've considered this, as you've received the feedback;
>>>>> but not all of these channels are 'owned' by Beam. Some of these are
>>>>> 'independently organized'. It may help to mark them as such.
>>>>>
>>>>
>>>> I have considered this, and I created a second version of the comms map
>>>> here <https://github.com/macruzbar/beam/blob/master/Comms-map-V2.md>.
>>>> In developing this strategy, it is clear that all the channels (independent
>>>> or not) are working towards the same project goals, so I saw no point
>>>> in distinguishing one set from the other. Do you think there is any
>>>> specific use to have this information outlined?
>>>>
>>>> - From the Artifacts section, Blog appears twice, while other artifacts
>>>>> appear only once with multiple arrows pointing at them (e.g. tech talks).
>>>>> Maybe this is on purpose, but just checking.
>>>>>
>>>>
>>>> Yes, this is because there are currently 2 live blogs: one on Beam
>>>> website, and one on Beam Summit website. On the first proposal
>>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution>,
>>>> my recommendation is to reduce this to only 1 blog, with different
>>>> categories. I hope this can be implemented! =) It will work better towards
>>>> bringing new users to Beam events.
>>>>
>>>>
>>>>
>>>> Looking forward to your thoughts / comments!
>>>>
>>>> María
>>>>
>>>>
>>>>>
>>>>> Thanks!
>>>>> -P.
>>>>>
>>>>> On Fri, Dec 6, 2019 at 5:12 PM María Cruz <ma...@gmail.com> wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>> sorry for the tardiness in responding to this, and thank you to
>>>>>> everyone who shared comments.
>>>>>> I have adjusted the initial graphic, and taken a step further to
>>>>>> develop the Apache Beam Communications Logic Model. This type of
>>>>>> visualization is a hypothesized description of the chain of causes and
>>>>>> effects leading to an outcome of interest [1]. The goal of making this
>>>>>> graphic is to identify how Apache Beam's channels and content work towards
>>>>>> project goals.
>>>>>>
>>>>>> The logic model graphic is attached and has also been uploaded [2] to
>>>>>> the repo I've been working on. I also added it to comms-strategy-DRAFT.md
>>>>>> [3]. If you have any questions or comments about this graphic, please add
>>>>>> them here [4].
>>>>>>
>>>>>> Step 3 in this process includes describing areas where we can be more
>>>>>> strategic about the content we produce for Apache Beam. I would like to
>>>>>> deliver this by December 17.
>>>>>>
>>>>>> Looking forward to your comments and feedback!
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> María
>>>>>>
>>>>>>
>>>>>> [1] https://en.wikipedia.org/wiki/Logic_model
>>>>>> [2]
>>>>>> https://github.com/macruzbar/beam/blob/master/comms-logic-model.svg
>>>>>> [3]
>>>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>>>> [4] https://github.com/macruzbar/beam/issues/4
>>>>>>
>>>>>> On Wed, Oct 9, 2019 at 7:09 PM Thomas Weise <th...@apache.org> wrote:
>>>>>>
>>>>>>> It probably makes sense to separate official project channels from
>>>>>>> external ones like Beam Summit and meetups. Beam Summit is about Beam, but
>>>>>>> it is "third party" and not under the project umbrella. Operation of the
>>>>>>> youtube channel might also need clarification.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 9, 2019 at 4:35 PM Robert Bradshaw <ro...@google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Probably worth mentioning Slack and StackOverflow as well.
>>>>>>>>
>>>>>>>> On Wed, Oct 9, 2019 at 3:59 PM María Cruz <ma...@gmail.com>
>>>>>>>> wrote:
>>>>>>>> >
>>>>>>>> > Hi all,
>>>>>>>> > sorry for multiple messages. I realized after sending the first
>>>>>>>> email that a new thread with a different subject was probably more
>>>>>>>> efficient.
>>>>>>>> >
>>>>>>>> > I created a communication strategy draft. To start, I did a map
>>>>>>>> of Beam channels and content, and I have some questions for you:
>>>>>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>>>>>> >
>>>>>>>> > In order to create these files, I forked the repo. Once this
>>>>>>>> looks good, and if everyone agrees, we can merge the changes to apache/beam.
>>>>>>>> >
>>>>>>>> > I didn't assign reviewers for this file because I don't know if
>>>>>>>> there is someone who usually looks at these kinds of documents. So
>>>>>>>> everyone: please feel free to pitch in! I will give this a week for
>>>>>>>> comments.
>>>>>>>> >
>>>>>>>> > Looking forward to your comments!
>>>>>>>> >
>>>>>>>> > María
>>>>>>>>
>>>>>>>
Re: Please comment on draft comms strategy by Oct 16
Posted by Matthias Baetens <ba...@gmail.com>.
Hey Maria,
Great work!! This provides a nice overview of all the channels and how they
contribute to the overall project.
I will comment on the sections I am most familiar with:
- Website / blog: +1 for reducing the number of outlets to 1. The Beam
Summit website repository could use a clean-up and this can be part of that
effort.
- Workshops: Pablo & Austin have done some great work in this space, but
even more dedicated time & attention to this would greatly benefit the
project - and as Pablo raised this might be separate from project
transparency but directly contribute to increased usage.
-- For topics/format, it's split up in how to use and how to contribute.
How to use I would split up in a beginner training ("set-up and write your
first pipeline"), advanced training ("use some of the more exotic Beam
features / optimise your pipeline") and office hours (solve specific
problems people have which can feedback to the development team as well in
terms of missing features or potential improvement of documentation). Imho,
classroom style with an intro to Beam and concepts / advanced topics,
combined with do-it-yourself where people actually do some coding with
something to walk away is good for onboarding. A more fun and game-like
set-up can be done for users that already use Beam where we can accommodate
discussions or have them solve a specific use-case in groups.
- +1 for increased distribution of the talks. We should actively engage the
speakers as well to share it on their personal channels, and surface the
talks on the website and Twitter handles. Also a curated list as blogpost
would be a great addition.
I think a more consistent feedback mechanism and maybe idea box at events
might also benefit the community.
Cheers,
Matthias
On Wed, 15 Jan 2020 at 22:46, Austin Bennett <wh...@gmail.com>
wrote:
> Hi Kenn,
>
> We had workshop on this very topic (how to contribute to Beam) at our
> Berlin Summit: https://www.youtube.com/watch?v=PtPslSdAPcM There's is
> certainly room for me (or anyone) to cleanup and formalize that a bit
> more. Though, the views of that are relatively small, which either indeed
> points to a lack of appetite and/or that it wasn't well publicized (I
> suspect both).
>
> Cheers,
> Austin
>
> On Thu, Jan 9, 2020 at 6:53 PM Kenneth Knowles <ke...@apache.org> wrote:
>
>> Wow, this is great work. I looked at the graphical maps when you sent
>> them but forgot to reply on thread. They really distill a lot of
>> possibilities and help to think about the current state.
>>
>> These three action items seem good and doable. Thanks for highlighting
>> those. The only one that isn't obvious to me is "workshop on how to
>> contribute to Beam". Is there enough appetite / audience to make this a
>> workshop? What forms could this take? A live coding demonstration in a
>> normal talk slot at an OSS or data conference seems like a possibility.
>> Whatever we do, we should record and distribute for sure, because when
>> someone wants to contribute, they need to find the resources at that moment.
>>
>> Kenn
>>
>> On Wed, Jan 8, 2020 at 1:01 PM María Cruz <ma...@gmail.com> wrote:
>>
>>> Hi everyone,
>>> I'm writing to send an update about the communication strategy for Beam.
>>> In a nutshell, I have 3 proposed changes (copied from the md file here:
>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>> ).
>>>
>>> While all the channels are connected to a specific function in the
>>> short, medium, and long term, some areas have redundancies, and some other
>>> areas could use more exposure. In order to continue to grow the project,
>>> there are 3 proposals we need to focus on (click on the link on each
>>> section to read more):
>>>
>>> 1. Blog post categories, frequency and distribution.
>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution> Reduce
>>> to one blogging space (on Beam Website). Incorporate 3 categories to the
>>> blog: Apache Beam summit, Apache Beam use cases, and Your journey as a
>>> contributor.
>>>
>>> 2. Develop more in-person and digital workshops.
>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-2-develop-more-in-person-and-digital-workshops> Two
>>> workshop types: how to use Beam, and how to contribute to Beam.
>>>
>>> 3. Increase distribution of tech talks.
>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-3-distribution-of-tech-talks>
>>>
>>> - Embed tech talks in the Beam website, and the Beam Summit website,
>>> - Share talks on @ApacheBeam Twitter handle
>>> - Curate a list of talks by topic, and write blog posts to share
>>> curated talks (1 blog every 3 months),
>>> - Distribute copy via email to users@ and dev@ mailing lists.
>>> - Create playlists on YouTube channel. Create one view for
>>> subscribed users (featuring latest content), and one for non-subscribed
>>> users (featuring most popular content). One playlist per event, plus 1
>>> playlist for use cases.
>>>
>>> The communications plan also has a section about what to do when there
>>> is new content about Apache Beam:
>>>
>>>
>>> Where should I share new content about Apache Beam?
>>>
>>> Main outreach channels
>>>
>>> Beam Website
>>>
>>> Beam website blog
>>>
>>> Twitter handles (x2)
>>>
>>> Mailing lists (x2)
>>> Blogpost
>>>
>>> ✓
>>>
>>> ✓
>>>
>>> ✓
>>>
>>> ✓
>>> (share first paragraph in the
>>> email, and link to blog)
>>> Tech talk
>>>
>>> ✓
>>> (special section
>>> for tech talks)
>>>
>>> ✓
>>> (curate tech talks
>>> quarterly in a blog)
>>>
>>> ✓
>>>
>>> ✓
>>> (share blogs on a quarterly
>>> basis when published)
>>> Trainings
>>>
>>> ✓
>>> (under section “Get started”)
>>>
>>> ✓
>>>
>>> ✓
>>>
>>> If you have any questions or comments about this logic model, please add
>>> them here <https://github.com/macruzbar/beam/issues/4>.
>>>
>>> I'm happy to support in some of the proposed changes if there is
>>> interest in moving forward with them. If there aren't any further changes
>>> requested, I will proceed to add these files through a pull request.
>>>
>>>
>>> Pablo, thank you for the feedback. Some comments in line.
>>>
>>> On Mon, Dec 16, 2019 at 4:31 PM Pablo Estrada <pa...@google.com>
>>> wrote:
>>>
>>>> Hi Maria,
>>>> thanks for putting this together. It's large, so a bit hard to follow -
>>>> but that's probably just an indication of the complexity of Beam's
>>>> communication channels.
>>>> FWIW, I found that reading from the top down was useful (or rather,
>>>> from the top, backwards from the arrows).
>>>>
>>>> It is an interesting logical map. I am curious to see what we can
>>>> derive from it : )
>>>>
>>>> My comments:
>>>> - All of the factors that contribute to project transparency, when put
>>>> together, add up to increased use of Beam, but I feel like 'increased
>>>> knowledge of how to use beam' is the single largest contributor to that. Is
>>>> 'knowing how to use' completely captured by transparency? (I can try to
>>>> rephrase what I mean...)
>>>>
>>>
>>> This is true, we could add a direct connector between knowledge on how
>>> to use Beam, and use of Beam. At the stage of development that the project
>>> is at (growing), I think it is important to understand what is the value
>>> added by all the content and events that are created around the project to
>>> promote its use. In other words, knowing how to use the project is not the
>>> only factor contributing to the growth in its use, because the project is
>>> not new. Given that the project is in a growing phase, the community aspect
>>> becomes more and more important, which is why I thought it was important to
>>> highlight the role that transparency has in these dynamics.
>>>
>>>
>>>> - I'm sure you've considered this, as you've received the feedback; but
>>>> not all of these channels are 'owned' by Beam. Some of these are
>>>> 'independently organized'. It may help to mark them as such.
>>>>
>>>
>>> I have considered this, and I created a second version of the comms map
>>> here <https://github.com/macruzbar/beam/blob/master/Comms-map-V2.md>.
>>> In developing this strategy, it is clear that all the channels (independent
>>> or not) are working towards the same project goals, so I saw no point
>>> in distinguishing one set from the other. Do you think there is any
>>> specific use to have this information outlined?
>>>
>>> - From the Artifacts section, Blog appears twice, while other artifacts
>>>> appear only once with multiple arrows pointing at them (e.g. tech talks).
>>>> Maybe this is on purpose, but just checking.
>>>>
>>>
>>> Yes, this is because there are currently 2 live blogs: one on Beam
>>> website, and one on Beam Summit website. On the first proposal
>>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution>,
>>> my recommendation is to reduce this to only 1 blog, with different
>>> categories. I hope this can be implemented! =) It will work better towards
>>> bringing new users to Beam events.
>>>
>>>
>>>
>>> Looking forward to your thoughts / comments!
>>>
>>> María
>>>
>>>
>>>>
>>>> Thanks!
>>>> -P.
>>>>
>>>> On Fri, Dec 6, 2019 at 5:12 PM María Cruz <ma...@gmail.com> wrote:
>>>>
>>>>> Hi everyone,
>>>>> sorry for the tardiness in responding to this, and thank you to
>>>>> everyone who shared comments.
>>>>> I have adjusted the initial graphic, and taken a step further to
>>>>> develop the Apache Beam Communications Logic Model. This type of
>>>>> visualization is a hypothesized description of the chain of causes and
>>>>> effects leading to an outcome of interest [1]. The goal of making this
>>>>> graphic is to identify how Apache Beam's channels and content work towards
>>>>> project goals.
>>>>>
>>>>> The logic model graphic is attached and has also been uploaded [2] to
>>>>> the repo I've been working on. I also added it to comms-strategy-DRAFT.md
>>>>> [3]. If you have any questions or comments about this graphic, please add
>>>>> them here [4].
>>>>>
>>>>> Step 3 in this process includes describing areas where we can be more
>>>>> strategic about the content we produce for Apache Beam. I would like to
>>>>> deliver this by December 17.
>>>>>
>>>>> Looking forward to your comments and feedback!
>>>>>
>>>>> Thanks,
>>>>>
>>>>> María
>>>>>
>>>>>
>>>>> [1] https://en.wikipedia.org/wiki/Logic_model
>>>>> [2]
>>>>> https://github.com/macruzbar/beam/blob/master/comms-logic-model.svg
>>>>> [3]
>>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>>> [4] https://github.com/macruzbar/beam/issues/4
>>>>>
>>>>> On Wed, Oct 9, 2019 at 7:09 PM Thomas Weise <th...@apache.org> wrote:
>>>>>
>>>>>> It probably makes sense to separate official project channels from
>>>>>> external ones like Beam Summit and meetups. Beam Summit is about Beam, but
>>>>>> it is "third party" and not under the project umbrella. Operation of the
>>>>>> youtube channel might also need clarification.
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 9, 2019 at 4:35 PM Robert Bradshaw <ro...@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Probably worth mentioning Slack and StackOverflow as well.
>>>>>>>
>>>>>>> On Wed, Oct 9, 2019 at 3:59 PM María Cruz <ma...@gmail.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > Hi all,
>>>>>>> > sorry for multiple messages. I realized after sending the first
>>>>>>> email that a new thread with a different subject was probably more
>>>>>>> efficient.
>>>>>>> >
>>>>>>> > I created a communication strategy draft. To start, I did a map of
>>>>>>> Beam channels and content, and I have some questions for you:
>>>>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>>>>> >
>>>>>>> > In order to create these files, I forked the repo. Once this looks
>>>>>>> good, and if everyone agrees, we can merge the changes to apache/beam.
>>>>>>> >
>>>>>>> > I didn't assign reviewers for this file because I don't know if
>>>>>>> there is someone who usually looks at these kinds of documents. So
>>>>>>> everyone: please feel free to pitch in! I will give this a week for
>>>>>>> comments.
>>>>>>> >
>>>>>>> > Looking forward to your comments!
>>>>>>> >
>>>>>>> > María
>>>>>>>
>>>>>>
Re: Please comment on draft comms strategy by Oct 16
Posted by Austin Bennett <wh...@gmail.com>.
Hi Kenn,
We had workshop on this very topic (how to contribute to Beam) at our
Berlin Summit: https://www.youtube.com/watch?v=PtPslSdAPcM There's is
certainly room for me (or anyone) to cleanup and formalize that a bit
more. Though, the views of that are relatively small, which either indeed
points to a lack of appetite and/or that it wasn't well publicized (I
suspect both).
Cheers,
Austin
On Thu, Jan 9, 2020 at 6:53 PM Kenneth Knowles <ke...@apache.org> wrote:
> Wow, this is great work. I looked at the graphical maps when you sent them
> but forgot to reply on thread. They really distill a lot of possibilities
> and help to think about the current state.
>
> These three action items seem good and doable. Thanks for highlighting
> those. The only one that isn't obvious to me is "workshop on how to
> contribute to Beam". Is there enough appetite / audience to make this a
> workshop? What forms could this take? A live coding demonstration in a
> normal talk slot at an OSS or data conference seems like a possibility.
> Whatever we do, we should record and distribute for sure, because when
> someone wants to contribute, they need to find the resources at that moment.
>
> Kenn
>
> On Wed, Jan 8, 2020 at 1:01 PM María Cruz <ma...@gmail.com> wrote:
>
>> Hi everyone,
>> I'm writing to send an update about the communication strategy for Beam.
>> In a nutshell, I have 3 proposed changes (copied from the md file here:
>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>> ).
>>
>> While all the channels are connected to a specific function in the short,
>> medium, and long term, some areas have redundancies, and some other areas
>> could use more exposure. In order to continue to grow the project, there
>> are 3 proposals we need to focus on (click on the link on each section to
>> read more):
>>
>> 1. Blog post categories, frequency and distribution.
>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution> Reduce
>> to one blogging space (on Beam Website). Incorporate 3 categories to the
>> blog: Apache Beam summit, Apache Beam use cases, and Your journey as a
>> contributor.
>>
>> 2. Develop more in-person and digital workshops.
>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-2-develop-more-in-person-and-digital-workshops> Two
>> workshop types: how to use Beam, and how to contribute to Beam.
>>
>> 3. Increase distribution of tech talks.
>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-3-distribution-of-tech-talks>
>>
>> - Embed tech talks in the Beam website, and the Beam Summit website,
>> - Share talks on @ApacheBeam Twitter handle
>> - Curate a list of talks by topic, and write blog posts to share
>> curated talks (1 blog every 3 months),
>> - Distribute copy via email to users@ and dev@ mailing lists.
>> - Create playlists on YouTube channel. Create one view for subscribed
>> users (featuring latest content), and one for non-subscribed users
>> (featuring most popular content). One playlist per event, plus 1 playlist
>> for use cases.
>>
>> The communications plan also has a section about what to do when there is
>> new content about Apache Beam:
>>
>>
>> Where should I share new content about Apache Beam?
>>
>> Main outreach channels
>>
>> Beam Website
>>
>> Beam website blog
>>
>> Twitter handles (x2)
>>
>> Mailing lists (x2)
>> Blogpost
>>
>> ✓
>>
>> ✓
>>
>> ✓
>>
>> ✓
>> (share first paragraph in the
>> email, and link to blog)
>> Tech talk
>>
>> ✓
>> (special section
>> for tech talks)
>>
>> ✓
>> (curate tech talks
>> quarterly in a blog)
>>
>> ✓
>>
>> ✓
>> (share blogs on a quarterly
>> basis when published)
>> Trainings
>>
>> ✓
>> (under section “Get started”)
>>
>> ✓
>>
>> ✓
>>
>> If you have any questions or comments about this logic model, please add
>> them here <https://github.com/macruzbar/beam/issues/4>.
>>
>> I'm happy to support in some of the proposed changes if there is interest
>> in moving forward with them. If there aren't any further changes requested,
>> I will proceed to add these files through a pull request.
>>
>>
>> Pablo, thank you for the feedback. Some comments in line.
>>
>> On Mon, Dec 16, 2019 at 4:31 PM Pablo Estrada <pa...@google.com> wrote:
>>
>>> Hi Maria,
>>> thanks for putting this together. It's large, so a bit hard to follow -
>>> but that's probably just an indication of the complexity of Beam's
>>> communication channels.
>>> FWIW, I found that reading from the top down was useful (or rather, from
>>> the top, backwards from the arrows).
>>>
>>> It is an interesting logical map. I am curious to see what we can derive
>>> from it : )
>>>
>>> My comments:
>>> - All of the factors that contribute to project transparency, when put
>>> together, add up to increased use of Beam, but I feel like 'increased
>>> knowledge of how to use beam' is the single largest contributor to that. Is
>>> 'knowing how to use' completely captured by transparency? (I can try to
>>> rephrase what I mean...)
>>>
>>
>> This is true, we could add a direct connector between knowledge on how to
>> use Beam, and use of Beam. At the stage of development that the project is
>> at (growing), I think it is important to understand what is the value added
>> by all the content and events that are created around the project to
>> promote its use. In other words, knowing how to use the project is not the
>> only factor contributing to the growth in its use, because the project is
>> not new. Given that the project is in a growing phase, the community aspect
>> becomes more and more important, which is why I thought it was important to
>> highlight the role that transparency has in these dynamics.
>>
>>
>>> - I'm sure you've considered this, as you've received the feedback; but
>>> not all of these channels are 'owned' by Beam. Some of these are
>>> 'independently organized'. It may help to mark them as such.
>>>
>>
>> I have considered this, and I created a second version of the comms map
>> here <https://github.com/macruzbar/beam/blob/master/Comms-map-V2.md>. In
>> developing this strategy, it is clear that all the channels (independent or
>> not) are working towards the same project goals, so I saw no point
>> in distinguishing one set from the other. Do you think there is any
>> specific use to have this information outlined?
>>
>> - From the Artifacts section, Blog appears twice, while other artifacts
>>> appear only once with multiple arrows pointing at them (e.g. tech talks).
>>> Maybe this is on purpose, but just checking.
>>>
>>
>> Yes, this is because there are currently 2 live blogs: one on Beam
>> website, and one on Beam Summit website. On the first proposal
>> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution>,
>> my recommendation is to reduce this to only 1 blog, with different
>> categories. I hope this can be implemented! =) It will work better towards
>> bringing new users to Beam events.
>>
>>
>>
>> Looking forward to your thoughts / comments!
>>
>> María
>>
>>
>>>
>>> Thanks!
>>> -P.
>>>
>>> On Fri, Dec 6, 2019 at 5:12 PM María Cruz <ma...@gmail.com> wrote:
>>>
>>>> Hi everyone,
>>>> sorry for the tardiness in responding to this, and thank you to
>>>> everyone who shared comments.
>>>> I have adjusted the initial graphic, and taken a step further to
>>>> develop the Apache Beam Communications Logic Model. This type of
>>>> visualization is a hypothesized description of the chain of causes and
>>>> effects leading to an outcome of interest [1]. The goal of making this
>>>> graphic is to identify how Apache Beam's channels and content work towards
>>>> project goals.
>>>>
>>>> The logic model graphic is attached and has also been uploaded [2] to
>>>> the repo I've been working on. I also added it to comms-strategy-DRAFT.md
>>>> [3]. If you have any questions or comments about this graphic, please add
>>>> them here [4].
>>>>
>>>> Step 3 in this process includes describing areas where we can be more
>>>> strategic about the content we produce for Apache Beam. I would like to
>>>> deliver this by December 17.
>>>>
>>>> Looking forward to your comments and feedback!
>>>>
>>>> Thanks,
>>>>
>>>> María
>>>>
>>>>
>>>> [1] https://en.wikipedia.org/wiki/Logic_model
>>>> [2] https://github.com/macruzbar/beam/blob/master/comms-logic-model.svg
>>>>
>>>> [3]
>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>> [4] https://github.com/macruzbar/beam/issues/4
>>>>
>>>> On Wed, Oct 9, 2019 at 7:09 PM Thomas Weise <th...@apache.org> wrote:
>>>>
>>>>> It probably makes sense to separate official project channels from
>>>>> external ones like Beam Summit and meetups. Beam Summit is about Beam, but
>>>>> it is "third party" and not under the project umbrella. Operation of the
>>>>> youtube channel might also need clarification.
>>>>>
>>>>>
>>>>> On Wed, Oct 9, 2019 at 4:35 PM Robert Bradshaw <ro...@google.com>
>>>>> wrote:
>>>>>
>>>>>> Probably worth mentioning Slack and StackOverflow as well.
>>>>>>
>>>>>> On Wed, Oct 9, 2019 at 3:59 PM María Cruz <ma...@gmail.com>
>>>>>> wrote:
>>>>>> >
>>>>>> > Hi all,
>>>>>> > sorry for multiple messages. I realized after sending the first
>>>>>> email that a new thread with a different subject was probably more
>>>>>> efficient.
>>>>>> >
>>>>>> > I created a communication strategy draft. To start, I did a map of
>>>>>> Beam channels and content, and I have some questions for you:
>>>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>>>> >
>>>>>> > In order to create these files, I forked the repo. Once this looks
>>>>>> good, and if everyone agrees, we can merge the changes to apache/beam.
>>>>>> >
>>>>>> > I didn't assign reviewers for this file because I don't know if
>>>>>> there is someone who usually looks at these kinds of documents. So
>>>>>> everyone: please feel free to pitch in! I will give this a week for
>>>>>> comments.
>>>>>> >
>>>>>> > Looking forward to your comments!
>>>>>> >
>>>>>> > María
>>>>>>
>>>>>
Re: Please comment on draft comms strategy by Oct 16
Posted by Kenneth Knowles <ke...@apache.org>.
Wow, this is great work. I looked at the graphical maps when you sent them
but forgot to reply on thread. They really distill a lot of possibilities
and help to think about the current state.
These three action items seem good and doable. Thanks for highlighting
those. The only one that isn't obvious to me is "workshop on how to
contribute to Beam". Is there enough appetite / audience to make this a
workshop? What forms could this take? A live coding demonstration in a
normal talk slot at an OSS or data conference seems like a possibility.
Whatever we do, we should record and distribute for sure, because when
someone wants to contribute, they need to find the resources at that moment.
Kenn
On Wed, Jan 8, 2020 at 1:01 PM María Cruz <ma...@gmail.com> wrote:
> Hi everyone,
> I'm writing to send an update about the communication strategy for Beam.
> In a nutshell, I have 3 proposed changes (copied from the md file here:
> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
> ).
>
> While all the channels are connected to a specific function in the short,
> medium, and long term, some areas have redundancies, and some other areas
> could use more exposure. In order to continue to grow the project, there
> are 3 proposals we need to focus on (click on the link on each section to
> read more):
>
> 1. Blog post categories, frequency and distribution.
> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution> Reduce
> to one blogging space (on Beam Website). Incorporate 3 categories to the
> blog: Apache Beam summit, Apache Beam use cases, and Your journey as a
> contributor.
>
> 2. Develop more in-person and digital workshops.
> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-2-develop-more-in-person-and-digital-workshops> Two
> workshop types: how to use Beam, and how to contribute to Beam.
>
> 3. Increase distribution of tech talks.
> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-3-distribution-of-tech-talks>
>
> - Embed tech talks in the Beam website, and the Beam Summit website,
> - Share talks on @ApacheBeam Twitter handle
> - Curate a list of talks by topic, and write blog posts to share
> curated talks (1 blog every 3 months),
> - Distribute copy via email to users@ and dev@ mailing lists.
> - Create playlists on YouTube channel. Create one view for subscribed
> users (featuring latest content), and one for non-subscribed users
> (featuring most popular content). One playlist per event, plus 1 playlist
> for use cases.
>
> The communications plan also has a section about what to do when there is
> new content about Apache Beam:
>
>
> Where should I share new content about Apache Beam?
>
> Main outreach channels
>
> Beam Website
>
> Beam website blog
>
> Twitter handles (x2)
>
> Mailing lists (x2)
> Blogpost
>
> ✓
>
> ✓
>
> ✓
>
> ✓
> (share first paragraph in the
> email, and link to blog)
> Tech talk
>
> ✓
> (special section
> for tech talks)
>
> ✓
> (curate tech talks
> quarterly in a blog)
>
> ✓
>
> ✓
> (share blogs on a quarterly
> basis when published)
> Trainings
>
> ✓
> (under section “Get started”)
>
> ✓
>
> ✓
>
> If you have any questions or comments about this logic model, please add
> them here <https://github.com/macruzbar/beam/issues/4>.
>
> I'm happy to support in some of the proposed changes if there is interest
> in moving forward with them. If there aren't any further changes requested,
> I will proceed to add these files through a pull request.
>
>
> Pablo, thank you for the feedback. Some comments in line.
>
> On Mon, Dec 16, 2019 at 4:31 PM Pablo Estrada <pa...@google.com> wrote:
>
>> Hi Maria,
>> thanks for putting this together. It's large, so a bit hard to follow -
>> but that's probably just an indication of the complexity of Beam's
>> communication channels.
>> FWIW, I found that reading from the top down was useful (or rather, from
>> the top, backwards from the arrows).
>>
>> It is an interesting logical map. I am curious to see what we can derive
>> from it : )
>>
>> My comments:
>> - All of the factors that contribute to project transparency, when put
>> together, add up to increased use of Beam, but I feel like 'increased
>> knowledge of how to use beam' is the single largest contributor to that. Is
>> 'knowing how to use' completely captured by transparency? (I can try to
>> rephrase what I mean...)
>>
>
> This is true, we could add a direct connector between knowledge on how to
> use Beam, and use of Beam. At the stage of development that the project is
> at (growing), I think it is important to understand what is the value added
> by all the content and events that are created around the project to
> promote its use. In other words, knowing how to use the project is not the
> only factor contributing to the growth in its use, because the project is
> not new. Given that the project is in a growing phase, the community aspect
> becomes more and more important, which is why I thought it was important to
> highlight the role that transparency has in these dynamics.
>
>
>> - I'm sure you've considered this, as you've received the feedback; but
>> not all of these channels are 'owned' by Beam. Some of these are
>> 'independently organized'. It may help to mark them as such.
>>
>
> I have considered this, and I created a second version of the comms map
> here <https://github.com/macruzbar/beam/blob/master/Comms-map-V2.md>. In
> developing this strategy, it is clear that all the channels (independent or
> not) are working towards the same project goals, so I saw no point
> in distinguishing one set from the other. Do you think there is any
> specific use to have this information outlined?
>
> - From the Artifacts section, Blog appears twice, while other artifacts
>> appear only once with multiple arrows pointing at them (e.g. tech talks).
>> Maybe this is on purpose, but just checking.
>>
>
> Yes, this is because there are currently 2 live blogs: one on Beam
> website, and one on Beam Summit website. On the first proposal
> <https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md#proposal-1-blog-post-categories-frequency-and-distribution>,
> my recommendation is to reduce this to only 1 blog, with different
> categories. I hope this can be implemented! =) It will work better towards
> bringing new users to Beam events.
>
>
>
> Looking forward to your thoughts / comments!
>
> María
>
>
>>
>> Thanks!
>> -P.
>>
>> On Fri, Dec 6, 2019 at 5:12 PM María Cruz <ma...@gmail.com> wrote:
>>
>>> Hi everyone,
>>> sorry for the tardiness in responding to this, and thank you to everyone
>>> who shared comments.
>>> I have adjusted the initial graphic, and taken a step further to develop
>>> the Apache Beam Communications Logic Model. This type of visualization is a
>>> hypothesized description of the chain of causes and effects leading to an
>>> outcome of interest [1]. The goal of making this graphic is to identify how
>>> Apache Beam's channels and content work towards project goals.
>>>
>>> The logic model graphic is attached and has also been uploaded [2] to
>>> the repo I've been working on. I also added it to comms-strategy-DRAFT.md
>>> [3]. If you have any questions or comments about this graphic, please add
>>> them here [4].
>>>
>>> Step 3 in this process includes describing areas where we can be more
>>> strategic about the content we produce for Apache Beam. I would like to
>>> deliver this by December 17.
>>>
>>> Looking forward to your comments and feedback!
>>>
>>> Thanks,
>>>
>>> María
>>>
>>>
>>> [1] https://en.wikipedia.org/wiki/Logic_model
>>> [2] https://github.com/macruzbar/beam/blob/master/comms-logic-model.svg
>>> [3]
>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>> [4] https://github.com/macruzbar/beam/issues/4
>>>
>>> On Wed, Oct 9, 2019 at 7:09 PM Thomas Weise <th...@apache.org> wrote:
>>>
>>>> It probably makes sense to separate official project channels from
>>>> external ones like Beam Summit and meetups. Beam Summit is about Beam, but
>>>> it is "third party" and not under the project umbrella. Operation of the
>>>> youtube channel might also need clarification.
>>>>
>>>>
>>>> On Wed, Oct 9, 2019 at 4:35 PM Robert Bradshaw <ro...@google.com>
>>>> wrote:
>>>>
>>>>> Probably worth mentioning Slack and StackOverflow as well.
>>>>>
>>>>> On Wed, Oct 9, 2019 at 3:59 PM María Cruz <ma...@gmail.com> wrote:
>>>>> >
>>>>> > Hi all,
>>>>> > sorry for multiple messages. I realized after sending the first
>>>>> email that a new thread with a different subject was probably more
>>>>> efficient.
>>>>> >
>>>>> > I created a communication strategy draft. To start, I did a map of
>>>>> Beam channels and content, and I have some questions for you:
>>>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>>>> >
>>>>> > In order to create these files, I forked the repo. Once this looks
>>>>> good, and if everyone agrees, we can merge the changes to apache/beam.
>>>>> >
>>>>> > I didn't assign reviewers for this file because I don't know if
>>>>> there is someone who usually looks at these kinds of documents. So
>>>>> everyone: please feel free to pitch in! I will give this a week for
>>>>> comments.
>>>>> >
>>>>> > Looking forward to your comments!
>>>>> >
>>>>> > María
>>>>>
>>>>