Ask HN: Proper etiquette to add maybe-mission-inconsistent changes to Git repo?

3 points by elbigbad 10y ago ↗ HN

I forked a relatively popular repository. Made some changes to suit my own needs locally, which took maybe 60-70 hours. I wouldn't mind submitting a pull request to incorporate those changes to the master. I'm pretty new to github in general though.

And really I'm not sure the changes are "production ready" so wouldn't mind having other interested parties work on it a bit. Additionally I'm not sure the direction of the added features is necessarily the direction the main repo creators want to go, there are no outstanding issues requesting these features, for example, and perhaps even if they would want to implement these features they would want to implement them in a different manner.

The features work but aren't fully baked, ideally I would like to see them part of the master for the personal satisfaction of knowing I added a pretty cool feature set to a popular repository.

So my question is this: What's the proper etiquette here? Should I submit a pull request to the master? Should I submit one to a new branch I create? Should I talk to the owners and see if they're even interested?

Sorry if this is basic!

3 comments

[ 2.4 ms ] story [ 17.5 ms ] thread

MalcolmDiggs 10y ago ↗

If your changes are generally-useful to the userbase, your code is fully tested, and it doesn't break any existing features, I'd just submit a pull-request to get the conversation going.

You never know, someone on the main team might have had the same idea for the feature long ago, but never mentioned it or had time to implement.

As far as new-branch vs master branch, go with whatever precedent the repo has laid out. (Review recent pulls, and any guidance the authors have laid out in the docs). It's a personal preference thing for the authors, there's not really a right or wrong way.

elbigbad 10y ago ↗

Thanks for the response.

It works pretty well, but probably not in 100% of cases, so it could use a little tweaking from someone more knowledgeable of the codebase. It doesn't break anything else though for sure.

Really liked working on this though, want to continue development, and don't want to get a bad reputation with the creator by flubbing things on my first pull.

brudgers 10y ago ↗

There seem to be two orthogonal considerations:

1. Are the changes consistent with the roadmap.

2. The code is not production quality.

The first is out of your control. The second is entirely within your control. The idea that someone else should do something about it is really the question of etiquette. An offer to improve the code quality yourself should accompany the pull request.

Good luck.