5

I would submit a pull request updating a library or a language. I would do so even if there are breaking changes (ex. Python 2 -> Python 3). I would submit a pull request that adds a new library if it is relevant to the functionality.

However, I am struggling with the acceptability changing the implementation language via a pull request, so would like to hear community's thoughts on: is it acceptable to change the implementation language via pull request?

To give an concrete example, there are lots of little packages on npm, and there are lots of type definitions hand-rolled on DefinitivelyTyped. For some projects it would be a trivial matter to add type annotations (making the file TypeScript) so it generates always-up-to-date definitions and nearly identical JavaScript (whitespace differences), but I hesitate because that would be a language switch and I question if that is socially acceptable.

I know the simple solution would be to open an Issue asking about it first, but I find often times that can lead to too long of feedback loop because maintainers are busy and may take a week or more to reply, so for small things will often create a PR directly eliminating the first feedback cycle.

| improve this question | |
  • 1
    Does using TypeScript require an additional step in the build process? (to transpile down to js)? – Alexander Jun 20 '17 at 16:28
  • It does. Any PR would include the relevant modifications. – vossad01 Jun 20 '17 at 16:38
  • What do you mean by "acceptable?" Is this a question about etiquette? As a practical matter, issuing a pull request requires that the project maintainer approve or reject the change on its merits, so why wouldn't that be an acceptable arrangement? – Robert Harvey Jun 20 '17 at 18:19
  • 1
    @RobertHarvey I suppose not wasting the maintainers time with things that are out of scope, the example in my head is, "Contributor: Your project is great, but it would be even better in LISP, here your go." "Maintainer: ...but this project is a Java library". – vossad01 Jun 20 '17 at 20:59
  • 1
    @Delioth context would be open source projects on the Internet with no previously established relationship. – vossad01 Jun 20 '17 at 21:00
9

I know the simple solution would be to open an Issue asking about it first, but I find often times that can lead to too long of feedback loop because maintainers are busy and may take a week or more to reply, so for small things will often create a PR directly eliminating the first feedback cycle.

I think opening an issue is the correct way to go even if it takes a while for maintainers to address it. Issues are the correct place for discussion about whether switching languages is the correct choice, and it's a good place for you to state your case for why you think it's an important change.

If you feel like it you can immediately submit a PR against the issue so the maintainers can see the impact of the changes, and they may be more open to changing languages if it means no additional work for them. I think this is perfectly socially acceptable.

You're going to have to wait for somebody to address your PR, so I don't think that's a reason not to create an issue.

If you need changes to an open source library for a project you're working on immediately, you should make them in a fork and publish to a private (or local) repository so you can use your changes immediately while your PR goes through the review process and gets released eventually. You shouldn't try to rush the process.

| improve this answer | |
4

is it acceptable to change the implementation language via pull request?

Everything is "acceptable" for you to propose... but not everything may be accepted. If you were to submit a PR to one of my project that support Python2 and 3 and that your PR makes it support Python 3 only, I will very unlikely merge your PR unless I am ready to abandon Python 2 support. In most cases I may just politely decline.

Even more so for TypeScript where the change would have even more impact (as a new compilation/transform would be needed).

So you surely need to discuss this on a ticket and/or on a case by case basis. Any such change will likely raise eyebrows and make a discussion around merging more involved.

If you feel strongly about it, fork and maintain your own forks and packages: that's the beauty of FOSS after all!

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.