Introduce recurring "Bisq-Calls"

[freimair]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

With 2020 and its necessary changes, attempts have been made and structures have been installed to address issues around how to craft and maintain Bisqs roadmap. The budget has been introduced, the concept of projects has been introduced, and an entity, namely the project management committee, has been installed to triage projects and thus, shape the roadmap of Bisq. However, this committee did not gain members to actually perform as intended, reasons being, among others, the initial overhead of creating project proposals, big projects, a limited work force and, hence, slow progress.

All of the above and the lack of communication started to paint a false picture of how things are handled and threatens to result in people loosing interest. By installing a new recurring Bisq call format, we hope to clear things up.

Proposal

We propose to revive the ol' dev calls but with a slightly changed format. The new calls are to follow a tight agenda. The agenda is designed to keep it rather compact and focused:

• Review ongoing/completed projects Get a feeling of what is going on in the project, make ourselves aware of what is being done currently and how things are moving along. Summarize every project by recapping the written project updates
• Adjust priorities of ongoing and new projects Discuss the priorities of all projects (ongoing and new) and come to a rough consensus what is important and urgent to do next.
• Assign people Ask for help on the projects to be taken over and driven forward. Find people that are willing to take over project leads as well as people which are willing to support bigger project by eg. help testing stuff if the time comes. Note that when a healthy number of high-priority tasks are taken care of already, we can fill our pipelines with less urgent but equally important stuff.

In a way, we propose to let the the call participants be the formerly installed project management committee. Thus, we propose the call to follow these ancillary characteristics:

• Open to everyone Literally everyone is welcome to join the calls. These calls should serve as a brewing ground of THE Bisq team, everyone can just passively suck up the information that is provided, people can join the discussion and bring their arguments into the mix and last but not least, people can stand up and commit themselves to certain projects or tasks.
• Weekly We propose to start with a weekly call and see how it goes. We can adjust the frequency as needed.
• 1h We aim for a call duration of 1h max. That is to not take up too much time for everybody but have some reserves when settling on priorities just takes a little longer. However, when nothing changed to the previous call (ie. no new projects, priorities stay the same, ...), such a call can be completed in 10min or less. Again, we always can adjust if it seems necessary.
• Meeting minutes There will be NO recording of the calls, however, there will be meeting minutes.
• Infrastructure We are to try Jitsi meet as an infrastructure, so everyone with a browser can participate easily. The calls will be tracked in our event list, where you can also find the minutes of past calls and agendas of upcoming calls. There will also be a calendar entry in our calendar and participation links will be distributed via the event issue, the calendar and the #general keybase channel.

Open Questions

• time/date. maybe thursdays, 13:00 UTC?
• host? a team maybe, in case someone cannot participate.

Closing words

These calls will be quite a challenge as we attempt to honor a lot of different opinions and reach a rough consensus over what is important and urgent for Bisq. We, however, are eager to try it and maybe, just maybe, it might just work out as expected. 🚀

[cbeams]

As discussed yesterday, a big +1 from my side on establishing these calls. I'd lean toward a once-per-week cadence and back off if that feels like too much. As I've mentioned at #182 (comment) and bisq-network/projects#1 (comment), I think these dev calls can be an excellent way to implement the (bi-)weekly reviews specified in the project management process (see https://bisq.wiki/Project_management#Review). That part of the documentation should be tweaked as appropriate to make it clear they are weekly, and that review happens as part of the dev calls, not in its own dedicated call, but my point is that they are, or can be, really one and the same thing. The project management process can be used to drive (much or most of) the dev call agenda. Talk about in-flight high-priority projects that need assistance, talk about new projects that have been proposed since the last call, etc.

In any case, I think these calls are a big opportunity to rally current and future @bisq-network/bisq-devs around what's most important, to better focus our efforts, and to really lock in the project management process as a core part of the way we work.

[dmos62]

As I've mentioned in the other thread, I think this is a good idea.

Not sure what form the calls should take though, especially concerning inviting the general public and streaming to youtube. I think regular calls could help build a sense of cohesion and some sense of privacy would help that. I guess I'm concerned that hyper-public conversations would be rigid.

If we want to invite users or outsiders for discussions, maybe that could be something separate and not for the dev team to undertake (growth team?).

[cbeams]

I'm concerned that hyper-public conversations would be rigid

Based on prior experience with various kinds of calls around Bisq, I doubt that we'll have a problem with too many people joining. So long as we're not broadcasting invitations to the calls e.g. via Twitter, it will likely be something that folks already interested in Bisq (i.e. hanging out in Keybase) will pay attention to.

Regardless of how many people join the call in real time, though, I agree that posting the calls after the fact to YouTube can have a chilling / self-censoring effect, and will definitely prevent certain contributors from showing their faces and in at least one case from using their voice.

I think the main thing would be to get the calls scheduled and happening, to iron out a good process / regular agenda, and to evaluate as we go what the right tradeoffs are with recording and publishing the calls. We could err on the side of being more private / ephemeral for a start if that's what feels more comfortable. I think recording calls and uploading them to Keybase is a nice option; doesn't have to be YouTube. The value of the recorded calls is going to decay pretty quickly; the main use case for recording and uploading them is probably just to make sure those who would have but couldn't attend the calls can catch up afterward. I don't see a strong requirement to make them permanent and "hyper-public" on YouTube.

If we want to invite users or outsiders for discussions

Again, I think if we target the invitations at @bisq-network/bisq-devs, that mostly who will attend is existing members or those who are interested in becoming members. (And for those who don't know, the criteria for inclusion in @bisq-network/bisq-devs is having had substantial contributions merged into the main repo within the last three months.)

[sqrrm]

I support this effort, but I won't join the calls myself as they would be recorded. I can however add my notes of current concerns to give a better picture of what's going on at the time of every call.

[freimair]

the thoughts behind publicly streaming/uploading are twofold basically:

• first, we always uploaded any dev-call in the past for the general public to view, mainly to provide the transparency the DAO and Bisq as an open source project should have.
• second, since Q1/2020 it felt like the open source structure has gone completely and some single individuals are making the calls on priorities and what is to be done - behind closed doors. A few of us know that this has never been true but it kinda felt weird. By making them as public as possible, we might counter-act and on the one hand show live how decision are made (in context) and on the other hand, publicly invite people to bring in ideas and concerns

yet again, this kind of openness may make people uncomfortable and not join at all.

I am just not sure if creating meeting minutes will cut it for showing the transparency. Yet again, it is significantly more transparency then we have right now. So I am glad to try it.

@sqrrm just to verify my understanding: would you actively join a public call with many unknown people attending if nothing is recorded?

[sqrrm]

No, I would not join a public call.

[freimair]

just refined the proposal. incorporated various discussions held in the past days.

[MwithM]

Maybe recording only one call per month/cycle, focused on reviewing monthly milestones makes sense.
That's the kind of meetings I'd like to attend or watch on Youtube, as I don't have much to say on day to day dev work. Day to day weekly calls don't need to be recorded.

[cbeams]

A couple thoughts:

• The title reads "Bisq Calls", but as I think we agreed (and as the text in the description and comments above reads), I think these are best called "dev calls" to clearly communicate the scope and intended audience. You might want to retitle the issue accordingly.

• One of the sticking points around better dev collaboration, and so a good thing to talk about in conjunction with these new calls, has been the lack of an effective dev email list. Any tech startup or larger software company would have this, and larger open source projects (e.g. Bitcoin, Linux) do too. I discussed this at https://github.com/orgs/bisq-network/teams/dao/discussions/1 a while back, and it came up again recently with @dmos at Improve incentives for Arbitrator (formerly known as Refund Agent) #222 (comment). The reason I think we need such a list is so that we can open up pure discussions, bounce around ideas, ask questions without (a) losing track of longer or more important conversations in the more ephemeral Keybase environment or (b) resort to prematurely creating proposal issues, which I think happens fairly often. If folks are agreed that a dev list would be a good thing, then the question becomes how to implement it. We have GitHub Discussions and could, for example, treat the @bisq-network/bisq-devs team as the Bisq dev email list, but the big downside of doing this is that the list isn't public. It can only be seen by those who are members of the bisq-network organization (and strictly speaking, we do archive all GitHub Discussion messages here), but that's a read-only firehose no one is going to read and use in practice. Furthermore, there is no guarantee that members of @bisq-devs have their notifications configured correctly such that they actually get email delivery of messages sent to that team. So GH Discussions are there, but not ideal. Another option would be to use our Mailman server to maintain a proper [email protected] email list, and deal with making sure that active Bisq devs know about it and subscribe if they want to participate. Sorry for the sort of breathless brain dump here, but I do think a bisq-dev list could really help and wanted to suggest it in the context of rolling out the new dev calls.

[dmos62]

@cbeams I like the idea of an email list. This would do better in a dedicated thread probably, but since there isn't one yet...

Not sure what advantages you see specifically. For me, the main problem with discussions on Github or Keybase is that they're flat. An email list, on the other hand, allows for a tree-like discussion (a discussion that can branch into multiple simultaneous discussions). Popular examples are Hacker News, Reddit. A "flat" discussion has to stay very focused on the principal topics and not drag on too long, because otherwise you'd end up with an unreadably long string of posts. Going on a tangent is a no-no, because you'd be doing it at the expense of the original discussion. Tree-like discussion threads don't have that problem.

If that's the main thing we want, we can just use some non-email-based forum software that supports it. Email has some usability challlenges. I've followed a few email lists, but participating for the first time was difficult and the email-thread readability and overview ability aren't great either.

[freimair]

• The title reads "Bisq Calls", but as I think we agreed (and as the text in the description and comments above reads), I think these are best called "dev calls" to clearly communicate the scope and intended audience. You might want to retitle the issue accordingly.

well, "dev calls" has always been a working title for me. And I am not sure we agreed on calling them "Dev Calls". And it seems that the term "dev calls" does not at all communicate the scope. Here is why:

• these calls will be there to keep Bisq's projects aligned and running and our projects are not dev-team only (and Bisq grew to be not dev-team only)
• if we limit these calls to the dev-team, then important projects of other teams do not get the attention they may need
• having non-dev projects out of scope will not improve triaging of non-dev projects

but certainly, I agree that the name needs to be more specific. Still a working title. Will think about it though.

[MwithM]

Closing as approved.