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 <[email protected]> 於 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 <[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] > ?
