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 <[email protected]> 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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
