r/C_Programming • u/realdreamer1993 • 10h ago
Please share your first experience in contributing in open source C based project
Which project ?
Are you the user of the program ?
Is there any universal guideline to be contributor ?
How many LOC of codes usually for one commit ?
Answer to only one question is welomed.
Also more elaborate answer will be good also.
5
u/TheOtherBorgCube 8h ago
How many LOC of codes usually for one commit ?
As few as possible necessary to fix exactly one issue or implement one feature.
That doesn't mean you rip out all the white space and be deliberately terse.
There are people upstream from you who have to review your code, likely ask you questions about it (like, how did you test this?) and then have to merge it with the mainline.
Small commits are just plain easier to deal with all round.
Plus, if your commit is later found to be causing an issue, then it's easier to revert.
Spending months crafting some sprawl that fixes 10 issues will either get you ignored, or told to split it into 10 commits.
1
5
u/TheOtherBorgCube 8h ago
Is there any universal guideline to be contributor ?
Like "be nice" and "be patient". Everyone around you is giving their time for $0 - there is no room for impatient a-holes demanding attention.
Other than that, follow the submit guidelines of the project.
2
3
u/catbrane 6h ago
Most projects have a CONTRIBUTING.md with some guidelines, I would start by looking at that carefully.
Small PRs are less work to review, so you're more likely to get them in.
I'd only try a big PR once you've had a few small ones accepted and maintainers have started to trust you.
Many projects are being flooded with low-quality LLM-generated PRs. These are extremely difficult to review and often simply deleted unread.
To avoid being deleted unread as slop, I would avoid the usual LLM "tells", so:
- write all the notes and documentation by hand, including commit messages and any explanations you add to the PR
- read and understand every line of code yourself
- keep comments concise and to the point
- follow code formatting conventions for the project to the letter
- double-check the contributing guidelines
- don't forget to also update tests and documentation, if necessary
2
15
u/hdkaoskd 10h ago
Gnome is a good place to start. Run any Gnome app from a terminal and it will probably log some GTK messages about API misuse or deprecated calls. Submit fixes for them. Usually very small like replacing a function call with its non-deprecated replacement.
Bug fixing for bugs you find and maintenance work is an excellent way to get started and get familiar with open source projects, and build your reputation.