Related to release notes, I do agree with cleaninp up the JIRA (as a community) and including the dependency changes. I find those information useful.
If the proposal here is to loosely align newsletter timelines with release times, I agree with that. If it is a proposal to merge release notes with the newsletter, I will be worried it will make the release process more difficult than it is today. Simply because we will need more things to happen for a release to be completed. On Wed, Mar 13, 2019 at 2:37 AM Etienne Chauchot <echauc...@apache.org> wrote: > Hi, > +1 on the process > +1 on the new News section > > I also think that matching the newsletter pace with the release pace makes > it clearer for users. Also, as a general obvious comment, newsletter have > the interest of providing the ongoing work compared to release notes that > provide only the work that was done. > > Etienne > > Le mardi 12 mars 2019 à 21:50 -0700, Kenneth Knowles a écrit : > > > > On Tue, Mar 12, 2019 at 9:04 PM Thomas Weise <t...@apache.org> wrote: > > The release blog is already on the radar for improvement [1]. > > I don't think there is a need to separate out the release blogs. That's if > they provide content that is valuable to users (IMO that's not exactly the > case today). > > > The case I am thinking about is a user searching the web for an issue and > figuring out what version it was fixed in. Dep upgrades being a primary > thing to notice. > > > If release blogs are just reformatted JIRA reports, then maybe we can skip > them altogether (release notes are already linked from download page). > > > One reason is that Jira remains mutable and I am not so sure of the SEO, > in terms of helping users figure out if an upgrade might solve their > problem. > > > In that case I would much rather like to see the original JIRA report > cleaned up as part of the release process. > > > Either way, this seems worthwhile. I think release managers often do this > anyhow. How could we formalize it? Do we need to? My favorite form of > formal process is just to get more eyes on some LGTM. > > > On the other hand, if release blogs are assembled similar to the > newsletter that we discuss here, through broader contributor input and with > the aim to provide more meaningful content to users, then I don't see why > we need to put them into a different area. > > > Same answer: people searching for issue resolution. I wonder if our > release notes should be a static copy/paste of the Jira list, deleting > things that really make no sense and editing everything else to be > meaningful. But I get the idea that we don't really need a separate area. > > What if newsletters matched releases, and could be drafted throughout the > 6 week period, with folks really trying to give a narrative to what they > contributed to a release? > > Kenn > > > Overall, given proposed newsletter cadence of 2 months and existing > release cadence, we would probably still end up with a monthly piece of > news. > > Thanks, > Thomas > > > > https://lists.apache.org/thread.html/224908775d8807eecc53e45f14f99d6a439beb8bb5165e3a813bf82d@%3Cdev.beam.apache.org%3E > > > On Tue, Mar 12, 2019 at 9:27 AM Rose Nguyen <rtngu...@google.com> wrote: > > Once every 2 months works. We include both big and small items. It'll > provide the focus Thomas mentions but still catches the frequency that > Pablo suggested for relevancy. To Alexey's point, it's difficult to > navigate the more recent non-release blog posts (<1 year) because they are > sprinkled in. > > A compromise for all of our points is to move the release notes to a > separate section, and have a single section that's blog/news. > > And thanks for wanting to contribute, Aizhamal! Teaming up with you will > make things run smoothly. > > On Tue, Mar 12, 2019 at 3:58 AM Alexey Romanenko <aromanenko....@gmail.com> > wrote: > > +1 for “News” section. Though, I’d propose to exclude “release notes” > posts from “Blog” section list (since now we have quite regular releases, > it makes blog posts list not very readable for users) and move them to new > created News section. Also, this section could include the posts about > other Beam events, like meet-ups, conferences, project updates, etc. I’d > keep “Blog” section for more technical posts. > > On 12 Mar 2019, at 06:31, Pablo Estrada <pabl...@google.com> wrote: > > I agree that the newsletter fits well as a blog post. I think that'd work > best. > > As for the cadence, I think quarterly would be a bit too infrequent. I > like once a month, or once every other month to have at least one per > release. Though happy to hear other people's thoughts. > Best > -P. > > On Mon, Mar 11, 2019 at 6:42 PM Thomas Weise <t...@apache.org> wrote: > > +1 for single blog/news section > > Also I wouldn't mind quarterly cadence, to provide more focus for folks to > contribute. > > On Mon, Mar 11, 2019 at 6:35 PM Kenneth Knowles <k...@apache.org> wrote: > > Could the newsletter be a blog entry? If you check out > https://blogs.apache.org/ many of the posts are "Apache News Round-up". > We could rename the "Blog" section to "News" if you ask me. > > Kenn > > On Mon, Mar 11, 2019 at 5:13 PM Aizhamal Nurmamat kyzy < > aizha...@google.com> wrote: > > Hello everyone, > > I had a chat with Rose on how I can support the effort and keep sending > the newsletters on a monthly basis. The new workflow would look as follows: > > 1. Send out the same [CALL FOR ITEMS] where you can contribute to the > Google doc with deadlines > 2. Edit the doc after the deadline > 3. Convert the file into Markdown > 4. Send in PR to add the file to Beam repo in Newsletter directory > 5. Have people send their fixes/updates through PRs > > In this effort, I can support Rose in steps 3 & 4. > > We would also need: > > - Create a Newsletter section under the Community tab > - Write guidelines on newsletter contributions > - Make a note about timing e.g. if upcoming event, then add to the > next newsletter > > How does that sound to you all? > > > On Wed, Mar 6, 2019 at 9:19 PM Rose Nguyen <rtngu...@google.com> wrote: > > Good points. With the suggested workflow I think I can support a quarterly > newsletter. I'm also happy to get more involvement from others to do this > work and we can see what cadence that allows. > > On Wed, Mar 6, 2019 at 8:22 PM Kenneth Knowles <k...@apache.org> wrote: > > Good points Melissa & Austin. > > - archive in the repo & on the website > - put missed items on the next newsletter, so anyone following sees them > > Kenn > > On Wed, Mar 6, 2019 at 3:26 PM Suneel Marthi <smar...@apache.org> wrote: > > I believe there was also a Beam workshop or working session in Warsaw last > week. > > On Wed, Mar 6, 2019 at 6:20 PM Austin Bennett <whatwouldausti...@gmail.com> > wrote: > > +1 for archive in our repo. > > I do follow the newsletter, but am unlikely to go back and look into the > past for changes/updates. > > Would suggest that things that get missed in one newsletter (a concrete > example, Suneel's talks not mentioned in the newsletter) would get > published in the next iteration, rather than editing the past 'published' > newsletter. Put another way, save editing the past for corrections (typos, > things being incorrect). Else, I imagine that I'm unlikely to catch a > great announcement that warranted being in the newsletter in the first > place. This certainly works better with a regular/frequent release > cadence, like we arrived at for version releases (then, if something misses > one cut, it is not too big a deal, as the next release is coming soon). > > > > > On Wed, Mar 6, 2019 at 12:50 PM Melissa Pashniak <meliss...@google.com> > wrote: > > > For step #2 (publishing onto the website), I think it would be good to > stay consistent with our existing workflows if possible. Rather than using > an external tool, what about: > > After a google doc newsletter draft is ready, convert it into a standard > markdown file and put it into our GitHub repo, perhaps in a new newsletter > directory in the website community directory [1]. These would be listed for > browsing on a Newsletters page as mentioned in step #4. People can then > just open a PR to add missing things to the pages later, and the newsletter > will be automatically updated on the website through our standard website > workflow. It also avoids the potential issue of the source google docs > disappearing in the future, as they are stored in a community location. > > [1] https://github.com/apache/beam/tree/master/website/src/community > > > On Wed, Mar 6, 2019 at 10:36 AM Rose Nguyen <rtngu...@google.com> wrote: > > I think that would be a great idea to change formats to help with > distribution. I'm open to suggestions! I'm currently using a Google doc to > collect and edit, then copy/paste sending the newsletter out directly, based > on an interpretation of this discussion > <https://lists.apache.org/thread.html/1f638eae43fe8abcb2f8752141c96d3dbdac86a583e0790044eea727@%3Cdev.beam.apache.org%3E> > . > > How about this doc->website->Beam site workflow?: > > 1. The same usual newsletter [CALL FOR ITEMS] where you can contribute > to the google doc, with soft deadlines for when I'll publish. > 2. I'll publish the doc itself onto a website. > 3. The newsletter is mailed out in the same way, but now with a > shareable website link. > 4. We'll keep an index of archived newsletter web pages on the Beam > site, under the Community tab. > 5. If you want to submit more content after the soft deadline, add it > to the google doc and let me know to republish. I don't want to make the > publication changes automatic because that leaves us open to tampering. > > > This process is more laggy, so I'd suggest doing a 2 month vs monthly > newsletter cadence. If we're happy with this idea, I'll send in a website > PR for a new "Newsletter" left nav item under Community. > > Here's an example of a published newsletter: Apache Beam February-March > 2019 > <https://gdoc.pub/doc/e/2PACX-1vTQIS4WkxV-HpgX5Lb6q05g4-wuIVcYd82123Mp4Y6q9fMv6Ynwd-l7dI4TrMyCrKilyU-YsoitbnZB> > > > - This link is permanent unless the principal google doc is deleted. > - Changes to the google doc after web publication are not > automatically published on the website to protect the information > integrity. > - Republishing is quick and easy for me if you let me know you've > added more. > - I'll improve the formatting later if we go with this route. > > Any thoughts? > > On Wed, Mar 6, 2019 at 6:13 AM Thomas Weise <t...@apache.org> wrote: > > Similar to blog posts. A link that can be shared would also help to > distribute over other channels, such as Twitter. > > > On Wed, Mar 6, 2019, 6:06 AM Ismaël Mejía <ieme...@gmail.com> wrote: > > We should have these newsletters published somewhere with a fixed URL so > we can add missing updates, I have at least missed putting stuff in the > last 3 ones just to realize when the newsletter has been already > 'published' (and sadly interesting features like zstd have not been > announced because of this). > > On Wed, Mar 6, 2019 at 2:48 PM Etienne Chauchot <echauc...@apache.org> > wrote: > > Hi, > I would add in what's been done: > > Work on cassandraIO (Etienne Chauchot, Mathieu Blanchard, Frank Shahar) : > refactorings, bugfixes, new where clause, security fix > > Etienne > > Le lundi 04 mars 2019 à 18:36 +0100, Suneel Marthi a écrit : > > Is this the final draft? - we had 2 beam talks at Big Data Tech Warsaw > last Wednesday - I can send the updates offline. > > On Mon, Mar 4, 2019 at 6:16 PM Rose Nguyen <rtngu...@google.com> wrote: > > > [image: Beam.png] > February-March 2019 | Newsletter > > What’s been done > > ------------------------------ > > Apache Beam 2.10.0 released (by: many contributors) > > - Download the release here. > <https://beam.apache.org/get-started/downloads/> > - See the blog post > <https://beam.apache.org/blog/2019/02/15/beam-2.10.0.html> for more > details. > > > Apache Beam awarded the 2019 Technology of the Year Award! > > - InfoWorld just awarded Beam the 2019 Technology of the Year Award. > - See this article > > <https://www.infoworld.com/article/3336072/application-development/infoworlds-2019-technology-of-the-year-award-winners.html?nsdr=true> > for more details. > > > Kettle Beam 0.5 released with support for flink (by: Matt Casters) > > - Kettle now supports Apache Flink as well as Cloud Dataflow and Spark. > - See Matt’s Blog > > <http://sandbox.kettle.be/wordpress/index.php/2019/02/24/kettle-beam-update-0-5-0/> > for more details. > > > > What we’re working on... > > ------------------------------ > > Apache Beam 2.11.0 release (by: many contributors) > > > Hive Metastore Table provider for SQL (by: Anton Kedin) > > - Support for plugging table providers through Beam SQL API to allow > obtaining table schemas from external sources. > - See the PR <https://github.com/apache/beam/pull/7746> for more > details. > > > User Defined Coders for the Beam Go SDK (by: Robert Burke) > > - Working on expanding the variety of user defined types that can be a > member of a PCollection in the Go SDK. > - See BEAM-3306 <https://issues.apache.org/jira/browse/BEAM-3306> for > more details. > > > Python 3 (by: Ahmet Altay, Robert Bradshaw, Charles Chen, Mark Liu, Robbe > Sneyders, Juta Staes, Valentyn Tymofieiev) > > - Beam 2.11.0 is the first release offering partial Python 3 support. > - Many thanks to all contributors who helped to reach this milestone. > - IO availablility on Python 3 is currently limited and only Python > 3.5 version has been tested extensively. > - Stay tuned on BEAM-1251 for more details. > > > Notebooks for quickstarts and custom I/O (by: David Cavazos) > > - Adding IPython notebooks and snippets > - See [BEAM-6557] <https://github.com/apache/beam/pull/7679> for more > details. > > > > > New members > ------------------------------ > > New PMC member! > > - Etienne Chauchot, Nantes, France > > > New Committers! > > - Gleb Kanterov, Stockholm, Sweden > - Michael Luckey > > > New Contributors! > > - Kyle Weaver, San Francisco, CA > - Would like to help begin implementing portability support for the > Spark runner > - Tanay Tummapalli, Delhi, India > - Would like to contribute to Open Source this summer as part of > Google Summer of Code > - Brian Hulette, Seattle, WA > - Contributing to Beam Portability > - Michał Walenia, Warsaw, Poland > - Working on integration and load testing > - Daniel Chen, San Francisco, CA > - Working on Beam Samza runner > > > > Talks & meetups > ------------------------------ > > > Plugin Machine Intelligence and Apache Beam with Pentaho - Feb 7 @ London > > - Watch the How to Run Kettle on Apache Beam video here > > <https://skillsmatter.com/skillscasts/13405-how-to-run-kettle-on-apache-beam#video>. > > - See event details here > <https://www.meetup.com/Pentaho-London-User-Group/events/256773962/>.. > > > Beam @Lyft / Streaming, TensorFlow and use-cases - Feb 7 @ San Francisco, > CA > > - Organized by Thomas Weise and Austin Bennet, with speakers Tyler > Akidau, Robert Crowe, Thomas Weise and Amar Pai > - See event details here > <https://www.meetup.com/San-Francisco-Apache-Beam/events/257482350/> > and the slides for these presentation: Overview of Apache Beam and > TensorFlow Transform (TFX) with Apache Beam > <http://s.apache.org/beam-intro-feb-2019>, Python Streaming Pipelines > with Beam on Flink <http://go.lyft.com/python-flink-beam-meetup-2019>, > Dynamic > pricing of Lyft rides using streaming > > <https://www.slideshare.net/AmarPai2/dynamic-pricing-of-lyft-rides-using-streaming> > > . > Flink meetup - Feb 21@ Seattle, WA > > - Speakers from Alibaba, Google, and Uber gave talks about Apache > Flink with Hive, Tensorflow, Beam, and AthenaX. > - See event details here > <https://www.meetup.com/seattle-flink/events/258723322/> and > presentations here <https://www.slideshare.net/BowenLi9/presentations>. > > > > Beam Summit Europe 2019 - June 19-20 @ Berlin > > - Beam Summit Europe 2019 will take place in Berlin on June 19-20. > - Speaker CfP and other details to follow soon! > - Twitter announcement! > <https://twitter.com/matthiasbaetens/status/1098854758893273088> > > > > Resources > ------------------------------ > > Apache Jira Beginner’s Guide (by: Daniel Oliveira) > > - A guide > > <https://cwiki.apache.org/confluence/display/BEAM/Beam+Jira+Beginner%27s+Guide> > to introduce Beam contributors to the basics of using the Apache Jira for > Beam development. Feedback welcomed! > > > An approach to community building from Apache Beam (by: Kenn Knowles) > > - The Apache Software Foundation has published committer guidelines to > help Beam's community building work. > - See the post <https://blogs.apache.org/comdev/date/20190222> on the > ASF blog. > > > Exploring Beam SQL on Google Cloud Platform (by: Graham Polley) > > - “In this article, I’ll dive into this new feature of Beam, and see > how it works by using a pipeline to read a data file from GCS, transform > it, and then perform a basic calculation on the values contained in the > file”. > - See article > > <https://medium.com/weareservian/exploring-beam-sql-on-google-cloud-platform-b6c77f9b4af4> > and full source code > > <https://github.com/polleyg/gcp-batch-ingestion-bigquery/blob/beam_sql/src/main/java/org/polleyg/BeamSQLMagic.java> > . > > > *Until Next Time!* > -- > Rose Thị Nguyễn > > > > -- > Rose Thị Nguyễn > > > > -- > Rose Thị Nguyễn > > > > -- > > *Aizhamal Nurmamat kyzy* > Open Source Program Manager > 646-355-9740 <(646)%20355-9740> Mobile > 601 North 34th Street, Seattle, WA 98103 > <https://maps.google.com/?q=601+North+34th+Street,+Seattle,+WA+98103&entry=gmail&source=g> > > > > >
