Dev-Call "About the Dev-Community"

[freimair]

Agenda

• How to attract more developers to the project (Dev Call "Seed nodes: Goals and strategies on how to get seed nodes more stable and reliable" #27 (comment))
  • "good first issues"
    • good first issues are actually used!
    • there are good first issue that are actually very difficult if not impossible to tackle
    • it is surprisingly time consuming to sift through the open issues, assess them and stick the "good first issue" tag on them or not
    • should we create one central point where all "good first issues" across the Bisq project are collected?
  • brainstorming session
    • twitter works surprisingly good
    • informal meetings in coffee shops, announce via twitter? yes, try it
    • code walkthroughs, online workshops?
      • we do not want to hold a developers hand throughout the process of onboarding
      • quite resource-hungry
    • a new dev might get the idea that only changes visible to the user (as in GUI) are the ones getting compensated
    • single resource where new devs can see compressed info on how to contribute
      • how to code style, PR size, ...
      • carreer on Bisq
    • how make the resource accessible
      • single line in Bisq repo Readme
      • PR template
      • in the Bisq software itself
• How to keep developers (some observations)
  • stakes are high, Bisq is successful, stuff that really fixes Bisq is not integrated easily, leading to a code freeze. Instead, non-important stuff is discussed often with no outcome at all.
    • How can we keep the evolution of Bisq going?
    • all about getting PRs merged
    • create a "role" for quickly review a PR, so that the dev can go back to work
      • not for the final Ack, but for stuff like formatting
    • every developer can review a PR and ask for compensations
      • however, that tends to create discussions on non-functional stuff and blocks the PR
    • the main issue is the lack of developers, however, the "carreer" a dev can go through is not broadly known (add it to the "single resource for new devs")
  • long-term developers take on more difficult stuff
    if one touches stuff which really fixes Bisq (performance-wise, security-wise, ...) the changes tend to be quite large, large changes are hard to review, reviews are not done, dev does not get compensated, Bisq does not get fixed
    if one touches small GUI stuff, changes tend to be small, fast review, compensation
    Hence, the smart thing to do is to do small fixes that do not touch the real issues Bisq has
    • how can we fix that?
    • big reviews take a lot of time, big responsibility, how to compensate maintainers?
  • if something has been agreed on, well defined, well confined and well documented, it might get reverted without being discussed, defined or documented.
    • is this a valid way to go? in a project with the size of Bisq?
    • no, it is not
    • maybe works for small teams, but a project the size of Bisq should keep records on the discussions leading to a decision, not only for reverting previous decisions
  • PR get blocked by small non-functional issues like the log-level or whether or not such a check should be made inside a call or not. All while the PR aims at really fixing Bisq.
    The repeating pattern is: no ack, no merge, conflict, rebase, no ack, no merge, dev looses interest, Bisq has another stale issue (has been fixed technically but will not be included and thus, has to be redone)
    • how can we fix that?
    • maintainer overrule, do not waste time on such small stuff
• Seednodes: Compensation (Add bonus payment for seed nodes operators when node has 99.9% availibility proposals#102)
  • skipped because no seednode operators have joined the dev-call

Schedule

When: Thursday, 2019-09-12 18:00 CEST
Duration: 1,5h
How: https://zoom.us/j/187978955, web link https://zoom.us/wc/join/187978955?pwd=

[m52go]

Update: we've had a good stream of new developers express interest in contributing to Bisq lately, based purely on word-of-mouth and digital outreach. While this is a good start, I don't think we should stop here. Discussing further efforts, especially from the perspective of newer developers, may help a lot.

Also, perhaps more importantly: I think we need to brainstorm things we can do to make "on-boarding" easier. Several of the new people who have come by left after not knowing how to proceed. Those that stuck around seemed to stumble a bit. At the risk of sounding like a bean-counter, the potential value of a good new developer is astronomical, so I think it's worth spending time and effort to make sure they have what they need.

Perhaps making the set of "good first issues" more current, making a basic code walk-though (as proposed elsewhere), etc. could help, among other things.

[blabno]

@m52go I agree with you. Weekly update of "good first issues" should be priority for one of maintainers.

[m52go]

Recording published here:
https://youtu.be/xiTzY9Vf7ms