[DISCUSS] How to manage our video conferences going forward.

[leerho <le...@gmail.com>]

Folks,

As our mentors have pointed out we need to figure out a way to provide more
openness to our video conference sessions and at the same time retain the
spontaneity and interactiveness that the video format provides.  Here are
some thoughts to start off a discussion.

*Background*
The number of research scientists worldwide that have chosen to specialize
in the theoretical foundations of mergeable streaming algorithms is quite
small, probably a couple of dozen or so.  And of these, the scientists that
are also interested in the engineering and high-performance implementation
of these algorithms specifically targeted at massive data processing
systems is smaller still.   This paucity on the scientific research side is
not helped by the fact that very few universities offer doctoral programs
or even graduate courses in this field.  From an informal survey we found
only about a half-dozen universities in the U.S. that offer coursework in
mergeable streaming algorithms, and even in these schools, the courses are
not offered every semester or even every year.

On the engineering, software development side, the number of developers
that are even aware of these algorithms is also small as these topics are
not taught at the undergraduate level.  The chances are much better if the
SW engineer has had at least a Master's degree at one of the top
universities with strong computer science offerings.  It is not required
that a SW development engineer have the rigorous theoretical math
background required to push the science forward.  But curiosity and
interest in learning about the science certainly helps. Nonetheless, with
some experience and exposure to this field many developers become
fascinated with the performance and power of these algorithms and are open
to learning more.  With this experience and exposure the number of SW
engineers that would be interested in contributing to this discipline could
be vastly larger than it is today.

From the beginning, the core contributors to this project has been made up
of two types of folks, scientists that love engineering and engineers that
love science.

Because we were small it was convenient to set up a video conference to
keep in touch.  And, over time, this conference has been used as follows:

*How we have used the Video Conference Format (VCF) so far.*
1. The VCF provides a relaxed environment for us to get to know one
another.  Seeing someone's face adds a human touch and spontaneity to the
discussion.
2. The VCF allows the participants to toss around ideas about what
algorithms would be useful to have in the library and to allow the
scientists to spontaneously suggest algorithmic approaches that may be
quickly dispelled or reinforced based on issues of practicality,
complexity, theoretical provability, etc.
3. The VCF also allows us to use whiteboards to quickly write down
mathematical approaches or programatic structures to clarify the
discussion.
4. From the engineering side we also would like to understand if there are
already published useful algorithms that we could be working on and
ultimately add to the library.
5. The participants in our current sessions are all deeply familiar with
all of our sketching algorithms and have years of experience using them and
understand and how they work.  This has allowed the discussions to move
rapidly across a number of topics.

*Analysis of the above items*
1. Clearly #1 has scalability issues if we believed that the size of the
group of folks interested in participating would grow very large.  Perhaps
#1 could also be recast as a means to get to know new members or
contributors initially and then scheduled only when new members join.
2. Items #2 and #3 are hard to do by email, period.
3. Item #4 could be handled by email. We just have to have the discipline
to write these down.
4. Item #5 is a challenge. If we allowed random people to join these
discussions who do not have the depth of understanding of this area it
could be quite disruptive and discouraging to the folks that want to move
through the topics quickly.  Nonetheless, interested folks still could be
allowed to listen in.  The sessions would have to be moderated so that if
remedial topics come up, they can be taken off-line and into a different
forum.

*Logistical problems with the VCF*
1. Time zones.  So far we have only had folks from the continental US
spread over 4 time zones.  Yet, I was recently contacted by a senior
engineer from Taiwan, that may be joining us.  And I'm sure there are folks
in Europe that would like to join us as well.  One solution might be to
have the sessions alternate morning and evening on alternate weeks.
Nonetheless, this is a tough issue.
2. Currently our video conferences are hosted by Verizon, and Verizon has
policies that we are not allowed to openly publish the URL to a video
conference for just anyone to join.  This means if we continue to use our
current host, joining the video session has to be by invitation.  This
could be as simple as contacting one of the core members or making a
request on @dev.

*A Possible Suggestion*
We could announce our meetings on @dev and on our website with
documentation of the objectives, how the meetings are conducted, and
instructions on how to get an invite.

I would like to invite your comments and suggestions, please!

Lee.

Re: [DISCUSS] How to manage our video conferences going forward.

[Evans Ye <ev...@apache.org>]

Agree with Kenny and Dave. Making  decisions trackable on mail list is the
way to let users and contributors keep up with everything happening in the
community, regardless of the nation and time difference.

OTOH, there are many ways to contribute to an Apache project. Not just
scientist and engineer who write code and research  algos. You can have doc
writter to make the doc more freindly to engineers w/o to much math. You
can have event organizer to help expand the community. You can have one
contributor  who just answering questions in user list, but really helpful.
All the above are things that can make a project successful.

Evans

Dave Fisher <wa...@comcast.net> 於 2019年10月8日 週二 11:58 寫道：

> Kenn’s advice is good. Having discussions that are asynchronous,
> archivable, and global is a core aspect of The Apache Way.
>
> If it is on the mailing list it can be found years from now. Put it
> another way - “if it didn’t happen on the list it didn’t happen”.
>
> This aspect of Apache Governance is the most difficult to grasp.
>
> I’d like to hear what the DataSketches team thinks.
>
> Best Regards,
> Dave
>
> Sent from my iPhone
>
> > On Oct 7, 2019, at 8:44 PM, Kenneth Knowles <ke...@apache.org> wrote:
> >
> > There are more problems than the ones listed:
> >
> > 3. Newcomers. Someone new to the project should be able to come up to
> speed
> > on both technical decisions and rationale via the archives. The same goes
> > for long-time contributors who wish to reference past technical
> discussions.
> > 4. Oversight is similar. I don't have a concise description, but here is
> an
> > example: being a top-level Apache project gives users confidence that a
> > project's roadmap is not dominated by any one interest and that it will
> > survive even if contributors depart. The dev list is a principal source
> of
> > evidence for this.
> >
> > I would suggest starting with reporting at least the big picture of what
> > was discussed on the call, and any decisions that came up, explicitly
> > inviting discussion.
> >
> > Kenn
> >
> >> On Wed, Oct 2, 2019 at 7:15 PM leerho <le...@gmail.com> wrote:
> >>
> >> Folks,
> >>
> >> As our mentors have pointed out we need to figure out a way to provide
> more
> >> openness to our video conference sessions and at the same time retain
> the
> >> spontaneity and interactiveness that the video format provides.  Here
> are
> >> some thoughts to start off a discussion.
> >>
> >> *Background*
> >> The number of research scientists worldwide that have chosen to
> specialize
> >> in the theoretical foundations of mergeable streaming algorithms is
> quite
> >> small, probably a couple of dozen or so.  And of these, the scientists
> that
> >> are also interested in the engineering and high-performance
> implementation
> >> of these algorithms specifically targeted at massive data processing
> >> systems is smaller still.   This paucity on the scientific research
> side is
> >> not helped by the fact that very few universities offer doctoral
> programs
> >> or even graduate courses in this field.  From an informal survey we
> found
> >> only about a half-dozen universities in the U.S. that offer coursework
> in
> >> mergeable streaming algorithms, and even in these schools, the courses
> are
> >> not offered every semester or even every year.
> >>
> >> On the engineering, software development side, the number of developers
> >> that are even aware of these algorithms is also small as these topics
> are
> >> not taught at the undergraduate level.  The chances are much better if
> the
> >> SW engineer has had at least a Master's degree at one of the top
> >> universities with strong computer science offerings.  It is not required
> >> that a SW development engineer have the rigorous theoretical math
> >> background required to push the science forward.  But curiosity and
> >> interest in learning about the science certainly helps. Nonetheless,
> with
> >> some experience and exposure to this field many developers become
> >> fascinated with the performance and power of these algorithms and are
> open
> >> to learning more.  With this experience and exposure the number of SW
> >> engineers that would be interested in contributing to this discipline
> could
> >> be vastly larger than it is today.
> >>
> >> From the beginning, the core contributors to this project has been made
> up
> >> of two types of folks, scientists that love engineering and engineers
> that
> >> love science.
> >>
> >> Because we were small it was convenient to set up a video conference to
> >> keep in touch.  And, over time, this conference has been used as
> follows:
> >>
> >> *How we have used the Video Conference Format (VCF) so far.*
> >> 1. The VCF provides a relaxed environment for us to get to know one
> >> another.  Seeing someone's face adds a human touch and spontaneity to
> the
> >> discussion.
> >> 2. The VCF allows the participants to toss around ideas about what
> >> algorithms would be useful to have in the library and to allow the
> >> scientists to spontaneously suggest algorithmic approaches that may be
> >> quickly dispelled or reinforced based on issues of practicality,
> >> complexity, theoretical provability, etc.
> >> 3. The VCF also allows us to use whiteboards to quickly write down
> >> mathematical approaches or programatic structures to clarify the
> >> discussion.
> >> 4. From the engineering side we also would like to understand if there
> are
> >> already published useful algorithms that we could be working on and
> >> ultimately add to the library.
> >> 5. The participants in our current sessions are all deeply familiar with
> >> all of our sketching algorithms and have years of experience using them
> and
> >> understand and how they work.  This has allowed the discussions to move
> >> rapidly across a number of topics.
> >>
> >> *Analysis of the above items*
> >> 1. Clearly #1 has scalability issues if we believed that the size of the
> >> group of folks interested in participating would grow very large.
> Perhaps
> >> #1 could also be recast as a means to get to know new members or
> >> contributors initially and then scheduled only when new members join.
> >> 2. Items #2 and #3 are hard to do by email, period.
> >> 3. Item #4 could be handled by email. We just have to have the
> discipline
> >> to write these down.
> >> 4. Item #5 is a challenge. If we allowed random people to join these
> >> discussions who do not have the depth of understanding of this area it
> >> could be quite disruptive and discouraging to the folks that want to
> move
> >> through the topics quickly.  Nonetheless, interested folks still could
> be
> >> allowed to listen in.  The sessions would have to be moderated so that
> if
> >> remedial topics come up, they can be taken off-line and into a different
> >> forum.
> >>
> >> *Logistical problems with the VCF*
> >> 1. Time zones.  So far we have only had folks from the continental US
> >> spread over 4 time zones.  Yet, I was recently contacted by a senior
> >> engineer from Taiwan, that may be joining us.  And I'm sure there are
> folks
> >> in Europe that would like to join us as well.  One solution might be to
> >> have the sessions alternate morning and evening on alternate weeks.
> >> Nonetheless, this is a tough issue.
> >> 2. Currently our video conferences are hosted by Verizon, and Verizon
> has
> >> policies that we are not allowed to openly publish the URL to a video
> >> conference for just anyone to join.  This means if we continue to use
> our
> >> current host, joining the video session has to be by invitation.  This
> >> could be as simple as contacting one of the core members or making a
> >> request on @dev.
> >>
> >> *A Possible Suggestion*
> >> We could announce our meetings on @dev and on our website with
> >> documentation of the objectives, how the meetings are conducted, and
> >> instructions on how to get an invite.
> >>
> >> I would like to invite your comments and suggestions, please!
> >>
> >> Lee.
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@datasketches.apache.org
> For additional commands, e-mail: dev-help@datasketches.apache.org
> ?

Re: [DISCUSS] How to manage our video conferences going forward.

[Dave Fisher <wa...@comcast.net>]

Kenn’s advice is good. Having discussions that are asynchronous, archivable, and global is a core aspect of The Apache Way.

If it is on the mailing list it can be found years from now. Put it another way - “if it didn’t happen on the list it didn’t happen”.

This aspect of Apache Governance is the most difficult to grasp.

I’d like to hear what the DataSketches team thinks.

Best Regards,
Dave

Sent from my iPhone

> On Oct 7, 2019, at 8:44 PM, Kenneth Knowles <ke...@apache.org> wrote:
> 
> There are more problems than the ones listed:
> 
> 3. Newcomers. Someone new to the project should be able to come up to speed
> on both technical decisions and rationale via the archives. The same goes
> for long-time contributors who wish to reference past technical discussions.
> 4. Oversight is similar. I don't have a concise description, but here is an
> example: being a top-level Apache project gives users confidence that a
> project's roadmap is not dominated by any one interest and that it will
> survive even if contributors depart. The dev list is a principal source of
> evidence for this.
> 
> I would suggest starting with reporting at least the big picture of what
> was discussed on the call, and any decisions that came up, explicitly
> inviting discussion.
> 
> Kenn
> 
>> On Wed, Oct 2, 2019 at 7:15 PM leerho <le...@gmail.com> wrote:
>> 
>> Folks,
>> 
>> As our mentors have pointed out we need to figure out a way to provide more
>> openness to our video conference sessions and at the same time retain the
>> spontaneity and interactiveness that the video format provides.  Here are
>> some thoughts to start off a discussion.
>> 
>> *Background*
>> The number of research scientists worldwide that have chosen to specialize
>> in the theoretical foundations of mergeable streaming algorithms is quite
>> small, probably a couple of dozen or so.  And of these, the scientists that
>> are also interested in the engineering and high-performance implementation
>> of these algorithms specifically targeted at massive data processing
>> systems is smaller still.   This paucity on the scientific research side is
>> not helped by the fact that very few universities offer doctoral programs
>> or even graduate courses in this field.  From an informal survey we found
>> only about a half-dozen universities in the U.S. that offer coursework in
>> mergeable streaming algorithms, and even in these schools, the courses are
>> not offered every semester or even every year.
>> 
>> On the engineering, software development side, the number of developers
>> that are even aware of these algorithms is also small as these topics are
>> not taught at the undergraduate level.  The chances are much better if the
>> SW engineer has had at least a Master's degree at one of the top
>> universities with strong computer science offerings.  It is not required
>> that a SW development engineer have the rigorous theoretical math
>> background required to push the science forward.  But curiosity and
>> interest in learning about the science certainly helps. Nonetheless, with
>> some experience and exposure to this field many developers become
>> fascinated with the performance and power of these algorithms and are open
>> to learning more.  With this experience and exposure the number of SW
>> engineers that would be interested in contributing to this discipline could
>> be vastly larger than it is today.
>> 
>> From the beginning, the core contributors to this project has been made up
>> of two types of folks, scientists that love engineering and engineers that
>> love science.
>> 
>> Because we were small it was convenient to set up a video conference to
>> keep in touch.  And, over time, this conference has been used as follows:
>> 
>> *How we have used the Video Conference Format (VCF) so far.*
>> 1. The VCF provides a relaxed environment for us to get to know one
>> another.  Seeing someone's face adds a human touch and spontaneity to the
>> discussion.
>> 2. The VCF allows the participants to toss around ideas about what
>> algorithms would be useful to have in the library and to allow the
>> scientists to spontaneously suggest algorithmic approaches that may be
>> quickly dispelled or reinforced based on issues of practicality,
>> complexity, theoretical provability, etc.
>> 3. The VCF also allows us to use whiteboards to quickly write down
>> mathematical approaches or programatic structures to clarify the
>> discussion.
>> 4. From the engineering side we also would like to understand if there are
>> already published useful algorithms that we could be working on and
>> ultimately add to the library.
>> 5. The participants in our current sessions are all deeply familiar with
>> all of our sketching algorithms and have years of experience using them and
>> understand and how they work.  This has allowed the discussions to move
>> rapidly across a number of topics.
>> 
>> *Analysis of the above items*
>> 1. Clearly #1 has scalability issues if we believed that the size of the
>> group of folks interested in participating would grow very large.  Perhaps
>> #1 could also be recast as a means to get to know new members or
>> contributors initially and then scheduled only when new members join.
>> 2. Items #2 and #3 are hard to do by email, period.
>> 3. Item #4 could be handled by email. We just have to have the discipline
>> to write these down.
>> 4. Item #5 is a challenge. If we allowed random people to join these
>> discussions who do not have the depth of understanding of this area it
>> could be quite disruptive and discouraging to the folks that want to move
>> through the topics quickly.  Nonetheless, interested folks still could be
>> allowed to listen in.  The sessions would have to be moderated so that if
>> remedial topics come up, they can be taken off-line and into a different
>> forum.
>> 
>> *Logistical problems with the VCF*
>> 1. Time zones.  So far we have only had folks from the continental US
>> spread over 4 time zones.  Yet, I was recently contacted by a senior
>> engineer from Taiwan, that may be joining us.  And I'm sure there are folks
>> in Europe that would like to join us as well.  One solution might be to
>> have the sessions alternate morning and evening on alternate weeks.
>> Nonetheless, this is a tough issue.
>> 2. Currently our video conferences are hosted by Verizon, and Verizon has
>> policies that we are not allowed to openly publish the URL to a video
>> conference for just anyone to join.  This means if we continue to use our
>> current host, joining the video session has to be by invitation.  This
>> could be as simple as contacting one of the core members or making a
>> request on @dev.
>> 
>> *A Possible Suggestion*
>> We could announce our meetings on @dev and on our website with
>> documentation of the objectives, how the meetings are conducted, and
>> instructions on how to get an invite.
>> 
>> I would like to invite your comments and suggestions, please!
>> 
>> Lee.
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@datasketches.apache.org
For additional commands, e-mail: dev-help@datasketches.apache.org

Re: [DISCUSS] How to manage our video conferences going forward.

[Kenneth Knowles <ke...@apache.org>]

There are more problems than the ones listed:

3. Newcomers. Someone new to the project should be able to come up to speed
on both technical decisions and rationale via the archives. The same goes
for long-time contributors who wish to reference past technical discussions.
4. Oversight is similar. I don't have a concise description, but here is an
example: being a top-level Apache project gives users confidence that a
project's roadmap is not dominated by any one interest and that it will
survive even if contributors depart. The dev list is a principal source of
evidence for this.

I would suggest starting with reporting at least the big picture of what
was discussed on the call, and any decisions that came up, explicitly
inviting discussion.

Kenn

On Wed, Oct 2, 2019 at 7:15 PM leerho <le...@gmail.com> wrote:

> Folks,
>
> As our mentors have pointed out we need to figure out a way to provide more
> openness to our video conference sessions and at the same time retain the
> spontaneity and interactiveness that the video format provides.  Here are
> some thoughts to start off a discussion.
>
> *Background*
> The number of research scientists worldwide that have chosen to specialize
> in the theoretical foundations of mergeable streaming algorithms is quite
> small, probably a couple of dozen or so.  And of these, the scientists that
> are also interested in the engineering and high-performance implementation
> of these algorithms specifically targeted at massive data processing
> systems is smaller still.   This paucity on the scientific research side is
> not helped by the fact that very few universities offer doctoral programs
> or even graduate courses in this field.  From an informal survey we found
> only about a half-dozen universities in the U.S. that offer coursework in
> mergeable streaming algorithms, and even in these schools, the courses are
> not offered every semester or even every year.
>
> On the engineering, software development side, the number of developers
> that are even aware of these algorithms is also small as these topics are
> not taught at the undergraduate level.  The chances are much better if the
> SW engineer has had at least a Master's degree at one of the top
> universities with strong computer science offerings.  It is not required
> that a SW development engineer have the rigorous theoretical math
> background required to push the science forward.  But curiosity and
> interest in learning about the science certainly helps. Nonetheless, with
> some experience and exposure to this field many developers become
> fascinated with the performance and power of these algorithms and are open
> to learning more.  With this experience and exposure the number of SW
> engineers that would be interested in contributing to this discipline could
> be vastly larger than it is today.
>
> From the beginning, the core contributors to this project has been made up
> of two types of folks, scientists that love engineering and engineers that
> love science.
>
> Because we were small it was convenient to set up a video conference to
> keep in touch.  And, over time, this conference has been used as follows:
>
> *How we have used the Video Conference Format (VCF) so far.*
> 1. The VCF provides a relaxed environment for us to get to know one
> another.  Seeing someone's face adds a human touch and spontaneity to the
> discussion.
> 2. The VCF allows the participants to toss around ideas about what
> algorithms would be useful to have in the library and to allow the
> scientists to spontaneously suggest algorithmic approaches that may be
> quickly dispelled or reinforced based on issues of practicality,
> complexity, theoretical provability, etc.
> 3. The VCF also allows us to use whiteboards to quickly write down
> mathematical approaches or programatic structures to clarify the
> discussion.
> 4. From the engineering side we also would like to understand if there are
> already published useful algorithms that we could be working on and
> ultimately add to the library.
> 5. The participants in our current sessions are all deeply familiar with
> all of our sketching algorithms and have years of experience using them and
> understand and how they work.  This has allowed the discussions to move
> rapidly across a number of topics.
>
> *Analysis of the above items*
> 1. Clearly #1 has scalability issues if we believed that the size of the
> group of folks interested in participating would grow very large.  Perhaps
> #1 could also be recast as a means to get to know new members or
> contributors initially and then scheduled only when new members join.
> 2. Items #2 and #3 are hard to do by email, period.
> 3. Item #4 could be handled by email. We just have to have the discipline
> to write these down.
> 4. Item #5 is a challenge. If we allowed random people to join these
> discussions who do not have the depth of understanding of this area it
> could be quite disruptive and discouraging to the folks that want to move
> through the topics quickly.  Nonetheless, interested folks still could be
> allowed to listen in.  The sessions would have to be moderated so that if
> remedial topics come up, they can be taken off-line and into a different
> forum.
>
> *Logistical problems with the VCF*
> 1. Time zones.  So far we have only had folks from the continental US
> spread over 4 time zones.  Yet, I was recently contacted by a senior
> engineer from Taiwan, that may be joining us.  And I'm sure there are folks
> in Europe that would like to join us as well.  One solution might be to
> have the sessions alternate morning and evening on alternate weeks.
> Nonetheless, this is a tough issue.
> 2. Currently our video conferences are hosted by Verizon, and Verizon has
> policies that we are not allowed to openly publish the URL to a video
> conference for just anyone to join.  This means if we continue to use our
> current host, joining the video session has to be by invitation.  This
> could be as simple as contacting one of the core members or making a
> request on @dev.
>
> *A Possible Suggestion*
> We could announce our meetings on @dev and on our website with
> documentation of the objectives, how the meetings are conducted, and
> instructions on how to get an invite.
>
> I would like to invite your comments and suggestions, please!
>
> Lee.
>