Re: [DISCUSS] DISTILL Product Direction
We have SLACK!? What? Ok, I'll check that out right-quick! Let's plan on October for the tech interchange. I have some parenting to do this month with my new boy. I'll solicit some interest from the group and maybe set up a hangouts or some mechanism to add interested parties into a call. Good idea. In the meantime, I'll start doing some bare minimum repo management for Distill to start pulling in WIPs. Really, I think the stack is a separate implementation environment for the toolkit, not really an evolution. This lets us retreat back to content generation for the meat that the stack serves, rather than starting with a fancy platter. I'll flesh out the proposal a bit more on confluence. We did (a while back) pull together some requirements for v0.2.0 of the stack that we can use as a talking point so that we can start with a toolkit and move forward to a stack implementation: https://cwiki.apache.org/confluence/display/FLAGON/Distill+0.2.0 On 9/12/2019 10:21 AM, lewis john mcgibbney wrote: Hi Josh, Replies inline below On Wed, Sep 11, 2019 at 9:54 PM wrote: From: "Joshua C. Poore" To: "dev@flagon.apache.org" Cc: Bcc: Date: Mon, 9 Sep 2019 21:36:51 -0400 Subject: RE: [DISCUSS] DISTILL Product Direction Hi Lewis, I’m working with another community that’s doing the same exercise. They want a Python environment, which was always Distill’s intent, however they want to exploit the gamut of PlotLy and Dash. I’ll arrange an introduction, but that will have to be OFFLINE. ack “Maybe an hour-long technical session is required to hash out the proposal more fully then we post it for community input?” I like this idea. Can you spec out a little more what you’d like to go over in the “session” is this just a telecon, webcast discussion, or more of a demonstration? I think a discussion about what it would take to evolve Distill from the stack to toolkit. Some architectural discussion would be appropriate. We can then flush the output to a wiki and cross reference on this ML. Yep, there is no problem with us essentially branching DISTILL into a 'stack' or 'legacy' branch and then continuing on master with your proposal. I really like this idea, I can get started on this, and build out a new master as a pypy package. ack Please let me know when you are free to discuss and we can tagup. BTW, the ASF has a Slack at the-asf.slack.com which we could use... fyi
Re: [DISCUSS] DISTILL Product Direction
Hi Josh, Replies inline below On Wed, Sep 11, 2019 at 9:54 PM wrote: > From: "Joshua C. Poore" > To: "dev@flagon.apache.org" > Cc: > Bcc: > Date: Mon, 9 Sep 2019 21:36:51 -0400 > Subject: RE: [DISCUSS] DISTILL Product Direction > Hi Lewis, > > I’m working with another community that’s doing the same exercise. They > want a Python environment, which was always Distill’s intent, however they > want to exploit the gamut of PlotLy and Dash. I’ll arrange an introduction, > but that will have to be OFFLINE. ack > > > “Maybe an hour-long technical session is required to hash out the proposal > more fully then we post it for community input?” > > I like this idea. Can you spec out a little more what you’d like to go > over in the “session” is this just a telecon, webcast discussion, or more > of a demonstration? > I think a discussion about what it would take to evolve Distill from the stack to toolkit. Some architectural discussion would be appropriate. We can then flush the output to a wiki and cross reference on this ML. > > Yep, there is no problem with us essentially branching DISTILL into a > 'stack' or 'legacy' branch and then continuing on master with your > proposal. > > I really like this idea, I can get started on this, and build out a new > master as a pypy package. > ack Please let me know when you are free to discuss and we can tagup. BTW, the ASF has a Slack at the-asf.slack.com which we could use... fyi
RE: [DISCUSS] DISTILL Product Direction
Hi Lewis, I’m working with another community that’s doing the same exercise. They want a Python environment, which was always Distill’s intent, however they want to exploit the gamut of PlotLy and Dash. I’ll arrange an introduction, but that will have to be OFFLINE. “Maybe an hour-long technical session is required to hash out the proposal more fully then we post it for community input?” I like this idea. Can you spec out a little more what you’d like to go over in the “session” is this just a telecon, webcast discussion, or more of a demonstration? Yep, there is no problem with us essentially branching DISTILL into a 'stack' or 'legacy' branch and then continuing on master with your proposal. I really like this idea, I can get started on this, and build out a new master as a pypy package. Josh Joshua C. Poore, Ph.D Behavioral Scientist, Technologist Apache Flagon PPMC Find me on LinkedIn & ResearchGate From: lewis john mcgibbney Sent: Monday, September 9, 2019 12:03 PM To: dev@flagon.apache.org Subject: Re: [DISCUSS] DISTILL Product Direction Hi Josh, This is somewhat difficult for me top provide too much input on... I say that because the team I am working with is still prototyping what the Flagon product suite can do. As I recently moved teams I am still in the early difficult but exciting days of technical evangelism with Flagon being one of my subjects. I'm also not too intimate with the DISTILL product as it currently resides... I did however know that it was in need of some tlc. To be honest, right now I can't even install DISTILL having run into an issue with the first command. Responses inline On Thu, Aug 29, 2019 at 7:05 PM wrote: > > ... > > Context: > > UserALE.js is and will likely always ... > Thanks for the context. It really helps to understand how DISTILL is what it is. > > Proposal: > > My proposal is to refactor Distill to expedite analytical content > development. This involves pulling back the product focus from a > server-side stack component to a Python package that users can pull into > their own Python and ‘Conda package. We can then provide some of the basic > functions (e.g., make elastic queries, aggregations) Distill offered > through third-party dependencies (e.g., elasticsearch-dsl), and quickly > begin generating analytical libraries to distribute through the package. > I think this sounds like an excellent proposal describing how DISTILL can evolve to become more user-oriented, flexible and relevant moving forward. I am in support of it. > > Depending on demand, we can revisit the concept of a server-side stack > component serving various front-ends, but capitalize on other streamlined > visualization packages like PlotLy for visualization. > Yep, there is no problem with us essentially branching DISTILL into a 'stack' or 'legacy' branch and then continuing on master with your proposal. > > This will require major repository restructuring. However, this lessons > the work needed to get to analytical content generation and dissemination > and expedites community growth. > Agreed. I feel that publishing Python library(ies) really makes things simple and also keeps Flagon in business of providing simple, well written highly capable client-side functionality. > > > Please share your thoughts. As we reach consensus, we can move to a VOTE > to steer toward this proposal or others that arise through Discussion. > > Maybe an hour-long technical session is required to hash out the proposal more fully then we post it for community input? Lewis
Re: [DISCUSS] DISTILL Product Direction
Hi Josh, This is somewhat difficult for me top provide too much input on... I say that because the team I am working with is still prototyping what the Flagon product suite can do. As I recently moved teams I am still in the early difficult but exciting days of technical evangelism with Flagon being one of my subjects. I'm also not too intimate with the DISTILL product as it currently resides... I did however know that it was in need of some tlc. To be honest, right now I can't even install DISTILL having run into an issue with the first command. Responses inline On Thu, Aug 29, 2019 at 7:05 PM wrote: > > ... > > Context: > > UserALE.js is and will likely always ... > Thanks for the context. It really helps to understand how DISTILL is what it is. > > Proposal: > > My proposal is to refactor Distill to expedite analytical content > development. This involves pulling back the product focus from a > server-side stack component to a Python package that users can pull into > their own Python and ‘Conda package. We can then provide some of the basic > functions (e.g., make elastic queries, aggregations) Distill offered > through third-party dependencies (e.g., elasticsearch-dsl), and quickly > begin generating analytical libraries to distribute through the package. > I think this sounds like an excellent proposal describing how DISTILL can evolve to become more user-oriented, flexible and relevant moving forward. I am in support of it. > > Depending on demand, we can revisit the concept of a server-side stack > component serving various front-ends, but capitalize on other streamlined > visualization packages like PlotLy for visualization. > Yep, there is no problem with us essentially branching DISTILL into a 'stack' or 'legacy' branch and then continuing on master with your proposal. > > This will require major repository restructuring. However, this lessons > the work needed to get to analytical content generation and dissemination > and expedites community growth. > Agreed. I feel that publishing Python library(ies) really makes things simple and also keeps Flagon in business of providing simple, well written highly capable client-side functionality. > > > Please share your thoughts. As we reach consensus, we can move to a VOTE > to steer toward this proposal or others that arise through Discussion. > > Maybe an hour-long technical session is required to hash out the proposal more fully then we post it for community input? Lewis
