Enhancing developer involvement and code review visibility

[luke-jr]

In light of recent events, it seems desirable to make it easier for new devs to get involved in Knots directly rather than via Core. Many people also seem confused by GitHub stats and lack of visibility of code review.

How can we improve the development flow? Should we start doing PRs on Knots' repo directly more often?

Is there a way to post reviews publicly after the commit, other than GitHub? I looked a bit at git itself, but it seems sorely lacking in this area. It would probably not be very hard to extend it to have a "review" type for such things, but I've attempted to make much more trivial improvements to git before and my submission was basically ignored. :/

Any other thoughts?

[SatoshiNakamotoBitcoin]

A PGP signer option would also be good, for those of us who can't get involved for security or other reasons, we could guarantee it with our signature.

You could create a list of PGP signers who sign Knots, as we don't think anyone would sign anything dishonest.

[ghost]

Should we start doing PRs on Knots' repo directly more often?

If there's the review bandwidth for it here, I don't see why not. Willing to eyeball changes and help out where I can, but I'm not a C++ dev (not that learning the language is a big deal, but there's a gulf between understanding the syntax, and knowing idiosyncratic C++) and until the last few days had only looked at the Core and Knots codebases in a "check what I'm running" context. Changes can still be upstreamed to Core if they want them, whether by their maintainers, or the person developing the feature. Can probably convince some other people in the Bitcoin Discord (already pretty bullish on Knots) to start thinking seriously about contribution here, review and code.

Is there a way to post reviews publicly after the commit, other than GitHub?

Perhaps not super useful as it's not immediately available, and still in the 'thinking about it' stage, but I've been playing with the idea of mutable DHT torrents as a GitHub (or other repository hosting & collaboration service) replacement for a while now. Threw together a basic spec to put what's in my head so far into writing this morning, invite comments. Once I'm reasonably happy with the baseline plan to mostly manually construct a repo for the project itself, then build a basic impl. Requires a different way of thinking about than with these centralized platforms as there's not a 'canonical' repository for a project.

[bigshiny90]

First, I’m just posting to say I’m here and looking for ways to participate. Second, good questions re: GitHub altogether. I’ve not used GitHub for quite some time (my dev company has been using internal gitlab for a while). But I will dig in.

[frenzyball]

I have a long-weekend at the end of the month, and will focus on code-reading in core and knots and maybe set up a local lab. In the short-term I can contribute by reading code and commenting.

We use Azure Devops with git repos at work, and have only used Github as code-sharing for smaller tools and data. I have not been coding in C/C++ since 2004, but have been coding in C# after that as main language (windows).

How can we improve the development flow?

At work we use Visual Studio live sharing and pair coding, plus Microsoft Teams meeting with screensharing and discussion solutions within our company developers and/or partners. We often discuss solutions before we start coding and doing code review if the testing show weakness (either in automatic and/or manual testing). But in most cases the code is good enough to be merged into main branch since we have been discussing it during development.

I'm not sure how this could work here, but we could use the meeting planner (across time zones) if someone need to discuss a change. Or team up developers/reviewers in same or adjacent time zones for better coordination.

https://www.timeanddate.com/worldclock/meeting.html

Should we start doing PRs on Knots' repo directly more often?
Yes, in my opinion. If this makes it more visible and transparent. If the Knots changes are visible and show how these changes make the nodes better, it will get more traction IMO.

Is there a way to post reviews publicly after the commit, other than GitHub?
Other than inspecting the feature/branch it self? Not sure. If I'm given a branch I would an explanation of what is changed and the intention of the change, before I'm diving into the code reviewing it. Otherwise, it would be a "how does this code comply with our coding standard" review.

[michaelfolkson]

Should we start doing PRs on Knots' repo directly more often?

I think so. It would help with (public) review.

Is there a way to post reviews publicly after the commit, other than GitHub?

There are alternatives to GitHub of course (GitLab etc) but they're centralized also. It seems to be a choice of centralized repo or emailing patches to the maintainer right? I haven't seen a decentralized alternative where reviews of a PR are all viewable in one place and can be assessed together. Perhaps something based on Nostr.

Any other thoughts?

I think the contributing guidelines for Core are generally strong and should be applied here too. I do suspect (and @luke-jr can correct me if wrong) that Luke will effectively be the lead maintainer on this project and that if you can't convince him to merge a particular PR or NACK a PR then he will overrule you. The discussion can still be useful (as can the additional code review and eyeballs) and it is possible Luke is convinced to change his mind. But I think people have got used to the lack of clarity on Core merge decisions without a lead maintainer and they assume Knots will be the same way. Just trying to get out ahead and manage expectations before people start accusing Luke of not caring about views of new contributors and starting flame wars on social media etc.

[luke-jr]

Should we start doing PRs on Knots' repo directly more often?

I think so. It would help with (public) review.

I'm not sure it would. PRs on Core can still be reviewed (at least until Core maintainers close and lock them).

[michaelfolkson]

I guess that's a decision you're going to have to make. My personal view is that the recent uptick in Knots users and interest is because some users do want to use mempool policy as a tool to filter spam (non-monetary transactions that meet consensus rules etc) and that isn't Core's priority objective when designing mempool policy. Hence if that is the major code diff between Knots and Core those kind of pull requests are unlikely to be merged into Core. Core may very well merge pull requests that aren't related to mempool policy restricting spam e.g. wallet improvements.

[luke-jr]

Trying a new Discord here: https://discord.gg/e3t2Byy7

[trevarj]

One of the arguments I've been seeing is that people are claiming there are
tons of erratic changes being committed that will cause an accidental
hardfork.

I think this critique could be easily disproved by having a better branch
workflow. For example, having a Knots 28.X release forked from Core 28.X and
then a single rollup of commits that include all Knots feature changes which
were done on a dev branch. This way a bozo like me can come and do a review of
the release and how it differs from Core.

Curious if anyone has opinions on how to be more transparent with the changeset, at
least until the codebases diverge too greatly (imagining a neovim and vim
situation).

FYI Discord link is expired...I'm more of an IRC fan anyway 😏

[luke-jr]

One of the arguments I've been seeing is that people are claiming there are tons of erratic changes being committed that will cause an accidental hardfork.

Good thing there aren't tons of erratic changes... not to mention unfounded speculation that overlooks the past 14 years of proven success.

I think this critique could be easily disproved by having a better branch workflow. For example, having a Knots 28.X release forked from Core 28.X and then a single rollup of commits that include all Knots feature changes which were done on a dev branch.

That's already how it works...?

FYI Discord link is expired...I'm more of an IRC fan anyway 😏

Sadly, IRC is mostly dead :(

https://discord.gg/Uu4ybVPqSE

[trevarj]

That's already how it works...?

I believe now it's just merge commits.
I meant a single merge on a release branch, so that it isn't pages of merge commits:

Instead like this (not squashed or fast-fowarded):

*   Knots release/28.X (HEAD)
|\  
| * c6       (HEAD of dev branch)
| * c5
| * c4
| * c3
| * c2
|/  
*  c1  Core release/28.X
*  c0

Anyways, just a nit, so ignore me.