4 ms·

What does make a good first commit? I ask because I'm just starting to try to work on open source. The first commit I made on the one project I've already start

What does make a good first commit? I ask because I'm just starting to try to work on open source. The first commit I made on the one project I've already started getting involved with was adding more content (especially where there was a "TODO: more of this" comment), and correcting spellings. I wouldn't know how to start on something less content-based, though.

fundamental 13y ago
I'd say bug fixes, tiny typo fixes, documentation additions, unit test additions, performance enhancements, and relatively minor features are all good candidates. The actual scope of any set of changes that will be quickly accepted can vary wildly depending upon how well defined the project is and what group of individuals is maintaining it. I'd say the defining characteristics would just be easy to read the diff and understand how things are exactly altered and that the benefits are proportional to the risk and time for integration. An adequately written documentation addition for instance would be a easy to check for consistency and structure in one pass and the benefit is generally obvious after reading the diff. Large changes for a first commit can be reasonable, but some extra time has to be expected with some discussion on those changesets.
yizzerin 13y ago
Docs are a good place to start. In the projects I've worked on, new contributors usually enter when they've found a bug/desired-feature and worked out a fix for themselves. Aside from that, good first commits are usually smaller, so it's easier to review, and address a single concern. After you get a commit accepted, you can start claiming commits. Answering questions on Stack Overflow / mailing lists / issue trackers can be a good way to build up trust in your abilities and a working relationship with other contributors. Often projects label things that are "good for a first commit" and you should check out those. All that said, most projects are eager to include new people, and personally I enjoy helping new contributors feel comfortable and get their commits accepted.
rakoo 13y ago
Write tests. Tests are a way to delegate trust. Instead of trusting the developer, you trust the code. It's a huge huge relief. If you can remove that burden from the shoulders of the maintainers, I guarantee you will be welcomed with open arms. The side-effect is that you don't need to _add_ content/functionality, so the maintainers don't have to think about your new shiny feature. And if you fix something that was supposed to work in their own view of the project, then you start being noticed.

fundamental 13y ago

I'd say bug fixes, tiny typo fixes, documentation additions, unit test additions, performance enhancements, and relatively minor features are all good candidates. The actual scope of any set of changes that will be quickly accepted can vary wildly depending upon how well defined the project is and what group of individuals is maintaining it. I'd say the defining characteristics would just be easy to read the diff and understand how things are exactly altered and that the benefits are proportional to the risk and time for integration. An adequately written documentation addition for instance would be a easy to check for consistency and structure in one pass and the benefit is generally obvious after reading the diff. Large changes for a first commit can be reasonable, but some extra time has to be expected with some discussion on those changesets.

yizzerin 13y ago

Docs are a good place to start. In the projects I've worked on, new contributors usually enter when they've found a bug/desired-feature and worked out a fix for themselves. Aside from that, good first commits are usually smaller, so it's easier to review, and address a single concern. After you get a commit accepted, you can start claiming commits. Answering questions on Stack Overflow / mailing lists / issue trackers can be a good way to build up trust in your abilities and a working relationship with other contributors. Often projects label things that are "good for a first commit" and you should check out those. All that said, most projects are eager to include new people, and personally I enjoy helping new contributors feel comfortable and get their commits accepted.

rakoo 13y ago

Write tests. Tests are a way to delegate trust. Instead of trusting the developer, you trust the code. It's a huge huge relief. If you can remove that burden from the shoulders of the maintainers, I guarantee you will be welcomed with open arms. The side-effect is that you don't need to _add_ content/functionality, so the maintainers don't have to think about your new shiny feature. And if you fix something that was supposed to work in their own view of the project, then you start being noticed.