Thanks for the detailed context Patrick! I see a lot of value on videoconferences for presentations and brainstorms but I tend to prefer mailing list as a medium for consensus-seeking discussions for the following reasons: - Asynchronous - gives folk time to think and digest (as mentioned by Ben on the Kubernetes thread); - Timezones - allows people from all timezones to participate; - Inclusivity - accommodates more people in the discussion.
Regarding the proposed agenda of going through the unassigned issues to improve visibility on what needs to be done to ship 4.0 GA I think this is a great start but only covers part of the problem. I think we have 3 outstanding issues that are hampering visibility of 4.0 progress: a) Quality testing issues with no shepherd; b) Quality testing issues with shepherd, but no recent activity (~2 months or less); c) Quality testing issues with no objective acceptance criteria/Definition of Done; In order to facilitate the discussion I classified on this spreadsheet [1] the quality epic (CASSANDRA-15536) subtickets into two categories: ON TRACK / NEEDS ATTENTION. An issue "Needs Attention" if it has one of the 3 problems mentioned above and is "On Track" otherwise. ## ON TRACK: CASSANDRA-15583 4.0 quality testing: Tooling, Bundled and First Party CASSANDRA-15584 4.0 quality testing: Tooling - External Ecosystem CASSANDRA-15977 4.0 quality testing: Read Repair ## NEEDS ATTENTION: CASSANDRA-14746 Ensure Netty Internode Messaging Refactor is Solid CASSANDRA-15537 4.0 quality testing: Local Read/Write Path: Upgrade and Diff Test CASSANDRA-15538 4.0 quality testing: Local Read/Write Path: Other Areas CASSANDRA-15579 "4.0 quality testing: Distributed Read/Write Path: Coordination, Replication, and Read Repair" CASSANDRA-15580 4.0 quality testing: Repair CASSANDRA-15581 4.0 quality testing: Compaction CASSANDRA-15582 4.0 quality testing: metrics CASSANDRA-15585 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation CASSANDRA-15586 4.0 quality testing: Cluster Setup and Maintenance CASSANDRA-15587 4.0 quality testing: Platforms and Runtimes CASSANDRA-15588 4.0 quality testing: Cluster Upgrade CASSANDRA-15921 4.0 quality testing: Materialized View So in order to address these I think we should: a) Seek volunteers to shepherd unassigned items; b) Update status of inactive tickets; c) Define objective acceptance criteria for each quality issue; I believe we should do A) by actively seeking via mailing list volunteers for each unassigned quality issue, while B) and C) should be coordinated independently by the shepherd of each issue. In my view this should improve accountability and transparency into 4.0 GA progress. I would love to hear the community's thoughts on this. [1]: https://docs.google.com/spreadsheets/d/1E70HIo63KXP4ggLUCRYfuLLh_oJZNLuyuPdkiT6dMVE Em sex., 25 de set. de 2020 às 14:08, Patrick McFadin <pmcfa...@gmail.com> escreveu: > Hi Paulo, > > I appreciate you bringing this up because I'm sure that means plenty are > thinking the same thing. Let me give you a little context and history. > > Last ApacheCon I proposed setting up a periodic zoom call to emulate some > of the high bandwidth discussions that happen in-person. There was a good > deal of discussion about how to do this appropriately, specifically by not > creating isolated pockets of decision making. By providing yet another > interaction method, increase participation in the project. I have seen > these types of meetings work well in other OSS projects I'm involved with > but it needs to be right for ASF guidelines. > > - No final decisions are made during the call. Any proposals go to the > mailing list > - Make a recording and post so nothing is exclusive > - Post the chat transcripts (This is where the introverts interact and > it can be quite lively) > > I consider our Zoom call as part of a package of how we interact. > Jira - Code/feature specific discussion > Mailing List - Official record of discussions and decisions > Slack - Fast discussions with searchable text > Video Call - High bandwidth discussions and presentations. Transactional in > nature with an agenda. > > Having 25 people on a call to make a decision is not the intent or even > reasonable. No matter what the setting is, even on email we don't get that > many people weighing in on a topic. > > Using this meeting I posted as an example, the agenda is a discussion > focused on the three unassigned Jiras. I expect we will have a few people > that can directly speak about them and everyone else is a spectator or > commenting in chat. The intent is to drive some activity on Jira. > > The timezone thing bothers me more than anything. I can't figure out how to > make it completely equitable. The proposal as we formed the contributor > meetings was to rotate the time to accommodate European timezones to > Australia. The Kubernetes SIG had tried the 2 meetings in different halves > of the world. Eventually consistent discussions don't work well. > > I don't want to go all Mandelorian and say "This is the way" so hopefully > with this background we can continue the conversation. I always have > considered this meeting to be a work in progress. > > Patrick > > > On Fri, Sep 25, 2020 at 7:40 AM Paulo Motta <pauloricard...@gmail.com> > wrote: > > > Thanks for the initiative, Patrick! > > > > I wonder if videochat is the most inclusive method of discussion, not > only > > due to time zone differences, as mentioned by Alex, but also because it > > makes it harder for introverts from voicing their opinions. In my > > experience video calls with more than 5 participants tend to be dominated > > by extroverts. Do we lose anything by making this discussion via email? > > > > Erick, I don't think you're an outsider at all, you're a very active > member > > of the community. I don't think it's healthy for the project to have this > > mentality of "inner circle of contributors" - as long as you want to > > contribute - either by participating in the discussions, answering > mailing > > list questions, contributing documentation or code - you're an equally > > valuable member of the community. > > > > Em sex., 25 de set. de 2020 às 06:14, Erick Ramirez < > > erick.rami...@datastax.com> escreveu: > > > > > Very well said, Patrick! > > > > > > I'm not part of the inner circle of contributors so I'm a bit of an > > > outsider. But as an advocate for Cassandra and the community, I'm > > > optimistic that we will collectively get past this bump on the road, > get > > > 4.0 GA in 2020 and do bigger things in 2021. Cheers! > > > > > >
