How do we handle forks of 3rd party repositories

[bilsch]

This may relate to milestone 2 and it may also be better suited to milestone 3.

A discussion was started within the slack channel.

Phil Norman [5:34 PM]
Regarding the community engagement, what about engaging with some of the Smart Columbus groups? Scode has multiple repositories and it looks like they are trying out different licenses, contributor guidelines and rules of conduct, etc. Maybe some of this sharing is already going on as there are cross members in both groups (. Are there limitations to dropping some of our artifacts, e.g., model orgs, into the Scode wiki and get feedback on their slack channel?

Bill Schwanitz [6:49 PM]
This is a great question. I think a number of the repos are forks from upstream with local changes.

These forks would retain their licensing. It then becomes a question of whether the changes are going to be accepted upstream and merged in or if we are then stuck maintaining this fork ourselves.

We being the scos platform/whatever branding
This is a really good thing to consider for the community engagement aspect. I'll get this into the correct GitHub issue. Let's continue this discussion there or here in slack

There are a few gotchas related to this question.

1. Is the upstream project likely to accept our pull request?
2. What happens if upstream rejects our pull request / issue?
3. If the upstream rejects the pull request / issue are we willing to take on maintenance of this fork?
4. Are there other options?

This list is not intended to be exhaustive but something to capture a few of the concerns

[jdenen]

1. Is the upstream project likely to accept our pull request?

We're not going to guess. We'll just open an issue to ask the maintainer(s) if they want a new feature we're considering.

2. What happens if upstream rejects our pull request / issue?

If it's because of a technical issue, we fix the technical issue. Because we ask about features beforehand, we don't put ourselves in this position for non-technical issues.

3. If the upstream rejects the pull request / issue are we willing to take on maintenance of this fork?

Again, we're not going to put ourselves in a position where we don't know if a feature will be accepted by a repo's maintainer(s). So from the perspective of rejected pull requests, this is a non-starter.

We fork for two reasons:

1. We plan on submitting back to the upstream repository. We do this for an obvious bug. If we plan to submit a feature back to the repo, we'll open an issue and ask if they want it first.
2. We plan to go another direction and the upstream project is a solid base from which to start. In this case, we know ahead of time that we're not submitting back.

Determining if we fork and -- if we do -- which direction we take the fork is entirely contextual. There's never a right/wrong choice.

4. Are there other options?

We can always roll our own. That's something we'll consider, but just like forking and maintaining, it's entirely contextual.

[bilsch]

Thanks for the feedback @jdenen very helpful!

When it comes to releasing a thing would we hold that up until the upstream issue / pr is merged/resolved or point at our fork?

[jdenen]

It depends.

If it's something that we can build/bundle/deploy easily, we'd point at our fork until the fix or feature is merged. Then, we'd do a small deployment to point at the updated repo when that happens.

If it's something that would require us to publish a forked artifact to use (think a Ruby gem in rubygems.org, etc), we would wait. This is still pretty highly dependent on the context. There are often temporary workarounds for these situations, but it's not something we can really plan ahead for.