This paper seems like a superb introduction to making contributions to Bitcoin Core:

@waxwing tbh i felt it unfortunately reinforces the idea for new people that contributing = opening PRs, instead of reviewing PRs and testing issues

i've been writing on this topic for months (

@waxwing that said, i'm open to the idea that i've been doing this all wrong

@jon that is actually a very good point. When i was reading it, that point occurred to me, but then i just kind of forgot about it and kept reading.
I'm for sure aware of your very great efforts in this area and they're appreciated (I remember that podcast e g.).
Maybe it's still a good article though because of all the detailed suggestions, even with that flaw? Or would you say other things are wrong?

@waxwing hm... it's a personal article and my interest is more from the pov of bitcoin

here's a WIP counter-point article that i've been writing

@jon Nice work.

And it's a pretty easy read and clear.
Here's my thought: I wonder if we can somehow elevate the status of testing more. My own experience of contributing to open source software is that I have to spend a lot of time reviewing specifically where I'm sort of the (or one of "the') subject matter expert(s). I spend probably 70-80% of my Joinmarket time reviewing and testing because there's at best 1 or 2 other people that could do it.

But when you're not in that situation.. (1/2)

@jon of being "one of the experts" it seems like you should gravitate more towards the testing side .. it's a natural way to get into the nitty gritty of what actually happens in the guts of the software.

I mean I'm just talking about what to emphasize, you describe it already here in this doc.

@waxwing i agree. are you thinking more of manually testing issue reports, or writing tests and improving the coverage?

@jon I mean both, but I don't think I'm saying anything different from what's already been said by multiple people including you, so it's probably not an interesting comment.

When I started contributing to lnd (not in a big way, just couple things), I did first spend some time running tests. I found one area (transport layer) that (a) was in my wheelhouse (crypto) and (b) had somewhat lacking tests, so I added tests that were clearly needed.

@waxwing that's great tho, and quite rare.

what i wouldn't do for your crypto knowledge. you're lucky i don't live nearby or i'd pester for mentoring :p

@waxwing @jon
"I wonder if we can somehow elevate the status of testing more."

I think that's the key point.
Testing is not seen as sexy; software development is. Testing/reviewing is also often portrayed as a stepping stone to the 'real' work.

Another big problem is that it isn't visible (to most ppl).
When you look at the 'standard' metrics, you see who *committed* a change. When you look at someone's GH profile, the green blocks represent commits, not reviews.
Etc. I think you get the idea

@waxwing @jon
If you look at there is a section wrt testing (scroll FAR down), but again, it's only commits wrt testing(-suite).
Listing review 'scores'/contributions at the top of the changelog would make it WAY more prominent. You'd probably have to collect statistics yourself though.

Also, most people don't know how to test and subsequently report that.
Having periodic review weeks/months where everyone participates and *loudly announced*, may also help.

@waxwing @jon
Wrt green review blocks:
That's a step in the right direction :)

Taking a random item from the changelog:
fanquake got a green checkmark
kristapsk, emilengler and promag did not.
For people who can spend all their time on bitcoin development, this doesn't go unnoticed. The other 99% probably have no clue.

So increasing visibility should probably the first step.
Getting people to understand how insanely valuable and useful it is, will take longer.

@waxwing @jon
Rewriting/restructuring and/or providing an index in could be a way to increase visibility.
The 'REVIEW' section is in the bottom 1/3. If it is in the top 1/3, FAR more people will see it.
It will also make it clear that it has a high priority.

@FreePietje @waxwing the reviewers do have the option of getting a github point for the review if they use the review interface instead of the comment one (that said, this PR was minor / quick enough that i understand why they did not use it)

@jon @waxwing I get where you are coming from Jon and it is certainly well intentioned. I do think you need to differentiate between experienced open source contributors (e.g yourself) and non-experienced. What fields in life do you have people reviewing other people's work without first learning the ropes by actually doing the work? Students don't generally grade their professor's work.

@jon @waxwing That's not to say non-experienced new contributors shouldn't learn the review process. They should and they should participate in the PR review club and learn the review process. But I don't think they should be held to the same review expectations as someone with experience or someone who has found their feet on the project. Attempting a few good first issues is probably a better use of time than reviewing something they don't understand.

@michaelfolkson @waxwing i’d say to begin by testing issues, then reviewing for some time before opening PRs, because more value is provided by the first two, new people will learn more, and they will know better what to do when they open PRs

testing issues and releases seems super valuable and easier than opening valuable PRs

@michaelfolkson @waxwing my previous experience wasn’t of much use coming to bitcoin. i think the most translatable experience would be the social process part, e.g. how to go about it

that said, i could agree this isn’t necessarily the best strategy for an ambitious contributor looking for employment or funding, which i have been very bad at, but better from the point of view of the project

@michaelfolkson @waxwing expectations could be lower in terms of difficulty of PRs reviewed, definitely, but the ratio of testing or review to opening PRs would be the same

we really need to get away from the idea of telling people that contributing = opening PRs and that meaningful contributing = opening meaningful PRs

@michaelfolkson @waxwing at least, that’s my opinion, which is probably a minority one :)

@michaelfolkson @waxwing i don’t consider myself a good reviewer yet but as long as people are trying and learning and improving i think that’s great

@michaelfolkson @waxwing

thanks for the feedback, michael, really helpful... i updated the article quite a bit based on it

@jon @michaelfolkson

Btw on the "humming" concept in the article: people often don't click through links, and without doing that the concept doesn't come out from the article(?). Maybe quote the key part of the RFC for that?

Also, does the analogy apply? I understood it to mean that with humming rather than say raising hands, you get only a noisy smearing of "votes", not individual people identified; platforms like github don't have that, right?

Maybe we can use ring sigs here :)

@waxwing @michaelfolkson

i agree it's not ideal... maybe should drop that reference; "voting" made more sense but the word raises hackles... this article has been evolving

@waxwing @michaelfolkson

ok, more rewriting and a new title. it seems better now:

"On Reviewing, and Helping Those Who Do It"

Sign in to participate in the conversation
unidentified instance

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!