Can you flag those tickets as "blocked" or "awaiting feedback" if they're not Paulo? That way they show up in the kanban board and are easily visible.
I spoke with Jon and Jordan last Friday about the project mgt side of things; we've dropped the ball on that front since beta but are planning to get back into the saddle on sending more frequent status updates as well as trying to prune and clean up that list and move things along that get blocked. More to come. On Mon, Sep 28, 2020 at 10:27 AM, Paulo Motta <pauloricard...@gmail.com> wrote: > 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.ramirez@ > 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! > >
