Draft Gno.land Developer Call move to improve

[michelleellen]

Topic

This issue is to discuss and provide an improved structure to the current Gno.land Developer Calls.

• Make the call bi-weekly with a 1 hour time slot dedicted to updates

Proposed new structre

Duration:

• first hour structured updates from the core engineering team and highlights from core contributors
• second hour (optional) to build a list of issues to discuss that require an open forum for feedback, similar to the previous modus of operandi

1st hour

What to gno

• What are the main topics that the builders need to know about current development, a short summary of sorts: testnet updates, faucet updates...etc. This will be a succinct introduction into the TL;DR of what the technical topics that need to be highlighted and will be expanded upon. Any major milestones..etc.

Gno.land Blockchain

• Updates on faucet for example
• Client
• SDK
• Portal Loop

Token economics

• update on the status of DAO strucutures, fees.. etc.

VM and gnolang

• what is happening and what is upcoming

Tendermint 2

• client updates
• what is happening and what is upcoming

Contributor updates:

• demos
• blockers
• feedback

Q&A

2nd hour free form with issues and discussions that can be presented and discussed to show the deliberation and document the process of decision making.

Process of preparation: Every two weeks, we will have a GitHub issue opened a day before the call with the main buckets from above that the person providing updates can fill in. The information will be taken and compiled into a presentation format that will be used during the call to guide the conversation.

The call will be recorded, uploaded on YouTube and used to create The More You Gno recap.

[leohhhn]

I love this. I think it will allow for structure and also open discussion as we discussed. @michelleellen, if you need any help leading the call or making an agenda, please ping @waymobetta or me, we are more than happy to help you as you know :)

[thehowl]

Some additional ideas I've been thinking of and discussing:

• Timezone concerns
  The current call time happens to be extremely unconvenient for our Asian partners, who have to stay awake up to very late to join the call.
  What I propose: alternate between calls at 09:00 CET (00:00 Los Angeles, 03:00 NY, 17:00 Seoul) and 17:00 CET (08:00 Los Angeles, 11:00 NY, 01:00 Seoul).
  This will create a "split" in participation during the calls, both in the core team and in our partners. As we grow and have more core team members/partners, this may turn out to be positive.
  The "core team" presentation section as such should contain a summary of the work and open issues of the previous 2 weeks (unless partners tell us that they'd watch the other recordings anyway, in which case we can cut it down to the previous week).
• Partners showcase
  This informally already happens in our current dev calls, but let's make it so that during the first hour, aside from maybe a quick round-table (~3 mins each, more/less depending on the size of the team and grant scope) to touch base on everyone's progress, partners have a formal time-slot they can ask to be put in the agenda to present their work. This can generally be used for live demos.
  All the while, demos needn't happen exclusively during the calls: I really appreciate @jefft0's efforts documenting Berty's builder journey and think video demos should probably be heavily encouraged on each partner's builder journey. This way we can focus the calls on discussions still, and also make it so that the main "source-of-truth" for seeing a partner's "progress report" is through their builder journey issue.
• For clarity: while this is a push to make the calls more structured and focused in their first hour, I still want to remark that during this first hour we should still encourage questions and clarifications which don't require in-depth discussion (and deferring these to be discussed during the second hour). Otherwise, we could just make a weekly video 😉

One more thing that I think @michelleellen forgot to mention is that we should probably axe our private calls in favour of making them all public: they are rarely much different anyway, and if there is private information to be shared the Signal group is a good option.

Furthermore, I should still heavily stress that at this point we're looking for feedback and proposals from our partners, as you folks are the main reason these calls exist in the first place. If your feedback is "This is all stupid; we should just keep calls the way they are, as that is what is most useful to us" it is fine, as a core team we've just been observing things for the past few months and have tried to come up with ways to make the calls more efficient, focused, while still providing a "central forum for discussion" for all things related to the Gno project.

See you all later!

[jefft0]

I haven't said much because the proposals sound reasonable. It makes sense to have a quick round table and then discuss issues that have already been added to the agenda. This should help managing the meeting time.

alternate between calls at 09:00 CET and 17:00 CET

Of course this is good for us in the CET time zone. ;-)

we should probably axe our private calls in favour of making them all public

I would agree.

[dongwon8247]

Thank you for opening this issue, @michelleellen.

Here's my suggestion for the sync calls:

1. Core Sync Call (Bi-weekly, an hour call)

• This call should be prepared and presented by the core team.
• Suggested Agenda
  • Road to mainnet (Need a full picture of the roadmap. Share where we are today, what needs to be achieved for mainnet and this is our priority)
  • What has been done in the past two weeks (PR and issue reviews, which are important for mainnet, picked by the core team)
  • What we will work on for the next two weeks (I find this very informative and important for contributors/partners to be aligned with the core direction of the project)
  • Q&A session

2. Contributor Sync Call (Bi-weekly, an hour call)

• This call should be prepared and presented by the contributors/partners.
• Prior to the call, contributors are encouraged to provide updates on the topics they plan to share in the call in the gnolang/meetings. This will help the call host effectively manage the time to accommodate all contributors.
• Suggested Agenda
  • Introduction of new contributors/partners
  • Contributor updates (round-table)
    • Share what we've been working on (demo)
    • Issues & blockers
    • Get support/advice from the core team
  • Q&A session

As a contributor/partner, I'm personally always more curious to know how things are going/priorities/challenges in the core team.

Having the topic of the calls completely separate like this will benefit contributors by expecting a regular formatted update from the core team, which will help contributors align more with the project. This also benefits the core team by having a dedicated public call to solely focus on contributors' updates and get deep into the issues. I believe if it goes well, the Contributor Sync Call can go completely community-driven without the core team's effort.

[michelleellen]

Thank you all, something I also consider that as we move to next year, the off weeks that don't have a Developer Call (these will always be considered public), we could have a short 'road ot mainnet' update from @moul or potentially another team member. This would be a short 'what you need to know that is happening' in the technical progress to mainnet, following the roadmap, and live stream on YouTube so people can eventually ask questions and follow along interactively.

I would like to point out that the new format does require more work from the core engineering team as they will need to submit the main highlights related to each bucket and section. I think it is great, but I want to make sure it is sustainable.

The idea of this call was always in the vein of the Ethereum PM calls which go through discussion topics on GitHub and try to come to some consensus on how to move forward and a documentation of their decision making process.