Hacker News Reader

Comment by Xdes | Hacker News Reader

I'm terrible at open source because I usually fix things that don't need to be fixed (aka refactor). Then people yell at me to go away.

View on HN

Every good open source project I've seen will happily accept and merge refactoring pulls, as long as the refactoring:

-Actually makes the code cleaner.

-Reduces redundancies.

-Above all, actually results in there being less code than there was before.

If you can achieve clean code + negative lines of code after a refactor, with identical functionality, they'd be fools to not merge it.

It's possible the refactors you submitted didn't meet these requirements. Or the project owners simply were too possessive of the code they wrote with their own fingers.

The project lead explained that he didn't accept unsolicited commits. My code ended up getting merged with some other guys refactored code which eventually made it into the code base.

> The project lead explained that he didn't accept unsolicited commits

Isn't that sort of contrary to OSS?

> Isn't that sort of contrary to OSS?

No, OSS is a licensing model not a development model. With OSS, if the existing project has a dev model you don't like, you can always fork it and start a project with a dev model you do; with proprietary software (even if the source is available), if you don't like the development model (among other things you might not like) you're, well, forked.

You're dealing with terrible project maintainers then. Refactoring is super, super important and any project that rejects it must have a strange codebase.

Either that or the project owners/maintainers have a lot of pride.

That strikes me as a bit of an odd stance to take. While refactoring is certainly a portion of the work done to most any project, I wouldn't think that refactoring would be attractive as a first commit for someone who may be viewed as an outsider to a project.

Even if you overlook that getting code that matches a projects style guides might be rarer than it should be refactoring (at least in most cases that I need to deal with it) requires a good understanding of how everything fits together and a better idea of how it should work. There are some simple cases in which this might not be the case at all, such as grouping together a whole bunch of copypasta style code, but even under those circumstances any refactoring is likely to yield a fair bit of work for the maintainer to verify (regressions/style/changed organization) with fairly limited benefit.

As such it doesn't really seem that effective to try to impose something like this on a project without a good justification. If a good justification can be made, then sure refactor away, but otherwise the maintainer would logically think that the work was a waste of everyone's time.

From experience, I get really excited receiving small refactoring changes from newcomers, usually with the message "Hey this is my first time contributing to an open source project!"

I guess "small" is key. I agree a large refactoring would be troublesome to verify.

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.

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.

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.

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.

Or the refactor doesn't make sense...

http://tirania.org/blog/archive/2010/Dec-31.html - "Open Source Contribution Etiquette"

Reply on news.ycombinator.com