Links as variables about onboarding-to-bitcoin-core HOT 4 CLOSED

@kouloumos I agree that this would have been a nice approach, in fact, this is how I had it back around 57a8809 !

I then reverted to this format, as, although it makes the unrendered text a bit more "messy" to work with, contributors would be able to visit links directly from within their editors without having to append (shift+click to open in Alacritty for example).

I also got frustrated with how few of the asciidoc features github enabled, and it felt very freeing to be able to use the full featureset again once I dropped the asciidoctor-reducer precommit hook step. In addition to this, rebasing (which is probably unnecessary tbh) became a real nightmare with the reduced document, as it always needed manual adjustment between diffs.

Overall I felt that it was not going to make sense either for upgrading, as if we, for example, wanted to change from our current commit to v23.0, every link's lines would need to be manually checked and updated anyway, so the link variable would not help us much here either.

from onboarding-to-bitcoin-core.

Great! Your points are valid, the approach has been tried and dismissed so I'm closing this.

from onboarding-to-bitcoin-core.

I have to say, now that i'm not targeting GitHub rendering I am kinda more persuaded to go back a leverage that "full asciidoc functionality"... (it works rendering to asiidoc without the reduce step btw). But, 🤷🏼‍♂️

from onboarding-to-bitcoin-core.

I didn't persuade this further mainly because of Github rendering and your comment

contributors would be able to visit links directly from within their editors without having to append

Apart from that, I still think that variables would make future upgrades easier by separating changes in context and changes in links. But still, if that's the only benefit, a parse/find-and-replace script could be written when we reach that point.

from onboarding-to-bitcoin-core.