This paper seems like a superb introduction to making contributions to Bitcoin Core:
@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
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
If you look at https://bitcoincore.org/en/releases/0.19.0.1/ 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.
Taking a random item from the changelog: https://github.com/bitcoin/bitcoin/pull/16863
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.
@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
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
we really need to get away from the idea of telling people that contributing = opening PRs and that meaningful contributing = opening meaningful PRs
thanks for the feedback, michael, really helpful... i updated the article quite a bit based on it
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 :)
ok, more rewriting and a new title. it seems better now:
"On Reviewing, and Helping Those Who Do It"
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!