Have you ever contributed to a very large project like LLVM? I would say clearly not from the comment.

There are pitfalls everywhere. It’s not so small that you can get everything in your head with only a reading. You need to actually engage with the code via contributions to understand it. 100+ comments is not an exceptional amount for early contributions.

Anyway, LLVM is so complex I doubt you can actually vibcode anything valuable so there are probably a lot of actual work in the contribution.

There is a reason the community didn’t send them packing. Onboarding new comer is hard but it pays off.

▲ thesz a day ago | parent [-]

  > Have you ever contributed to a very large project like LLVM?

Oh, I did. Here's one: https://github.com/mariadb-corporation/mariadb-columnstore-e...

  > I would say clearly not from the comment.

Of course, you are wrong.

  > It’s not so small that you can get everything in your head with only a reading.

PSP/TSP recommends writing typical mistakes into a list and use it to self-review and to fix code before sending it into review.

So, after reading code, one should write down what made him amazed and find out why it is so - whether it is a custom of a project or a peculiarity of code just read.

I actually have such a list for my work. Do you?

  > You need to actually engage with the code via contributions to understand it. 100+ comments is not an exceptional amount for early contributions.

No, it is not. Dozens of comments on a PR is an exceptional amount. Early contributions should be small so that one can learn typical customs and mistakes for self review before attempting a big code change.

That PR we discuss here contains a maintainer's requirement to remove excessive commenting - PR's author definitely did not do a codebase style matching cleanup job on his code before submission.

▲ StopDisinfo910 a day ago | parent [-]

The personal dig was unwarranted. I apologise.

> So, after reading code, one should write down what made him amazed and find out why it is so - whether it is a custom of a project or a peculiarity of code just read.

Sorry but that’s delusional.

The amount of people actually able to meaningfully read code, somehow identify what was so incredible it should be analysed despite being unfamiliar with the code base, maintain a list of their own likely error and self review is so vanishingly low it might as well not exist.

If that’s the bare a potential new contributor has to cross, you will get exactly none.

I’m personally glade LLVM disagree with you.

	▲	thesz a day ago \| parent [-]
		`>The amount of people actually able to meaningfully read code, somehow identify what was so incredible it should be analysed despite being unfamiliar with the code base, maintain a list of their own likely error and self review is so vanishingly low it might as well not exist.` List of frequent mistakes gets collected after contributions (attempts). This is standard practice for high quality software development and can be learned and/or trained, including on one's own. LLVM, I just checked, does not have a formal list of code conventions and/or typical errors and mistakes. Could they have that list, we would not have the pleasure to discuss that. That PR we are discussing would be much more polished and there would be much less than several dozens of comments. `> If that’s the bare a potential new contributor has to cross, you will get exactly none.` You are making very strong statement, again.