Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Meeting Pace #684

Closed
glozow opened this issue May 25, 2023 · 11 comments
Closed

Change Meeting Pace #684

glozow opened this issue May 25, 2023 · 11 comments

Comments

@glozow
Copy link
Contributor

glozow commented May 25, 2023

We currently do meetings weekly. Here are a few observations and disadvantages:

  • For attendees, it's difficult to prepare every single week. It's also easy to decide to skip a week, since there will be another in 7 days.
    • There has been a clear decline in attendance over the past year or so.
  • We often don't have enough time to dive into the PR at a deeper level. Meetings often only cover the basics. When we do two-parters, many people have forgotten about the PR by the next week.
    • This can also come from the fact that notes aren't posted early enough so people don't have time to prepare.
    • I imagine the surface-level discussion also deters people from attending.
  • This structure also doesn't encourage people to review consistently. I see a lot of "Concept ACK" from review club and then no further reviews. This isn't the ideal PR review process and I imagine it is frustrating for the authors as well.
    • I observe this most commonly in myself, not trying to just criticize others. My list of "half-reviewed PRs" is extremely long (for many reasons I'll admit, but it's not helped by the need to devote time to a new PR every week).
    • We never intended to use review club to "get things merged," but the goal is to teach people how to review PRs and dig into the codebase. Consistency and depth are part of that.
  • It's difficult to find hosts every week. Stephan and Larry have been regularly hosting, but it's quite common for Stephan or me to host back-to-back. I once had to host 4 in a row. Notes/questions increasingly require our attention on weekends. I've been burning out for months and luckily Stephan has picked up my slack (thank you 🤗) but this is unsustainable.
    • More volunteers to host is nice, but difficult to rely on. Reviewing notes, attending meetings, and posting logs still requires minimum 2 hours every week.
    • It's very difficult to justify this given the low attendance. There is currently a big asymmetry in the amount of work Stephan and I put in vs. the amount of learning time for people who use this meeting as an educational resource.

Ideally:

  • Attendees and hosts are excited about each PR and have ample time to prepare for the meeting.
  • During the meeting, all questions are welcome, but we really dig into the PR. Attendees really review the PRs in depth and consistently, experiencing more than just the "concept ACK" stage.
  • We do not burn out.

Proposal:

  • Reduce the frequency to 1 PR per month
    • We could also perhaps do 2 per month, e.g. the 1st and 3rd wednesdays
    • "every other week" doesn't work because it's really easy to forget which week is a review club week, for both hosts and attendees.
  • Instead of a single 1hr meeting weekly, 2 meetings on the same week. The first meeting covers concept/approach, and the second meeting is implementation and code (or something).
    • e.g. wednesday 17UTC and thursday 11UTC.
    • maybe multiple times will help accommodate people in different timezones!
    • We can cover bigger PRs more thoroughly without leaving 7 days in between to lose attention
  • We won't necessarily meet for less time (e.g. if we do 2 per month), just changing the pace.
@glozow
Copy link
Contributor Author

glozow commented May 25, 2023

cc @stickies-v

@stickies-v
Copy link
Contributor

stickies-v commented May 25, 2023

Concept ACK. I agree that the current frequency is not ideal, not for the hosts and not for the attendees. I agree with your observation that we're not getting the review depth and consistency that we'd like, and I think for these meetings to be maximally helpful I think it's important we also make it worthwhile not just for newcomers (who remain a prime focus of this club) but for the more seasoned contributors, so everyone learns from them.

Both once or twice per month seem good options to me.

e.g. wednesday 17UTC and thursday 11UTC.

I think it's best to do the same time for both meetings, since we hope people can attend both. With two times we just increase the chance that people can't attend at least one. If the current time is suboptimal, I'm open to adjusting that and/or adding another (duplicated) meeting at a different time, since that doesn't add too much prep overhead?

@glozow
Copy link
Contributor Author

glozow commented May 25, 2023

I think it's best to do the same time for both meetings, since we hope people can attend both. With two times we just increase the chance that people can't attend at least one. If the current time is suboptimal, I'm open to adjusting that and/or adding another (duplicated) meeting at a different time, since that doesn't add too much prep overhead?

Yeah this makes sense. I've gotten a few pings over the years about accommodating asian timezones. Perhaps we can encourage more questions/discussions in the channel outside meetings - all I'm hoping is to provide a beginner-friendly space for everybody.

@darosior
Copy link
Contributor

I'm only a casual lurker but i noticed much of your observations, and what you suggest makes sense to me. Concept ACK.

@pablomartin4btc
Copy link

Once or even twice a month look fine to me, not sure how practical would be to have 2 on the same week where the first one is Concept/ Approach ACK and the second one is implementation/ coding/ testing, perhaps ppl that already did the Concept/ Approach ACK skips the first or viceversa, but it could be useful for cases like more complex changes e.g. I remember this one: nVersion=3 and Package RBF.

@kouloumos
Copy link
Contributor

Concept ACK. I almost never manage to be fully prepared for any meeting and that's why I've started looking at the back catalogue instead of preparing for upcoming meetings. I've especially felt that when I first started participating, as for newcomers the required preparation time for a PR Review Club is correlated to the amount of already established context, making it difficult to be prepared in time.

Also, having more time between the meetings could fit nicely with #429 as "recommended/related material" for participants that want and have time for more preparation before the actual meeting.

cc @rajarshimaitra who is doing a similar effort with https://github.com/Bitshala/Bitcoin-PR-Review-Club

@ismaelsadeeq
Copy link
Contributor

Concept Ack, I understand your point about sometimes not being able to fully review and understand the PRs discussed in the previous review club meetings. It can be challenging to switch gears and prepare for the upcoming review club while leaving the previous PR behind. There might be some PR's that will not require two sessions, so complex or large PR's can be two days, Wednesday and Thursday.

@rajarshimaitra
Copy link

Thanks @kouloumos for the tag. Concept ACK

We have observed similar feedback from the participants. Though our club is more geared towards conceptual discussion than in-depth reviews, a bi-weekly pace seems more suitable than weekly one. If the notice is announced with the review topic with ample time, that should also give participants enough time to ponder over the PR. Sometimes for new-comers it takes time to figure how to approach the review or what questions to ask. This only grows over time (years).

At the same time, it's essential for maintainers and hosts not to burn out.

@LarryRuane
Copy link
Contributor

Concept ACK. As the codebase becomes more mature and optimized, it's inevitable that PRs are becoming more complex, requiring more background understanding and thus more preparation time. I would prefer once per month over twice per month.

@stickies-v:

I'm open to [...] adding another (duplicated) meeting at a different time, since that doesn't add too much prep overhead?

That's a really interesting idea; as a host, I wouldn't mind doing that. The host may have a conflict at one of the times, but someone else could step in, and with the notes and questions already written, it probably wouldn't be too much work.

@stickies-v
Copy link
Contributor

Thanks for the feedback everyone, really appreciate it. Looks like everyone here is in favour of reducing the frequency so from July 5th we'll be starting with a monthly meeting, as implemented by glozow in #692. We'll communicate in the IRC channel as well once that's merged.

@glozow
Copy link
Contributor Author

glozow commented Jul 6, 2023

Closing as implemented via #692. See you all on August 2nd, we'll be reviewing Silent Payments with @josibake :)

@glozow glozow closed this as completed Jul 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants