Skip to content
loading...

re: The Importance of Knowing Your Gems VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Yep! Depending on the size of the monkey patch we will also do that. If it is a one liner then putting it in our code is so quick we go with that. ...

Why are Kenna trying to enforce that? That does make it more difficult to contribute back, both by needing an admin to fork and by diminishing the individual developer's contribution. Seems like an odd policy. Is it something to do with licensing of the contribution (like where large projects require a contributor license agreement)?

We used to point at personal repo forks, but as we have grown the policy has changed a little bit.

The reason we do it this way is so we have better control over the gems we use and in case a developer leaves. Relying on open source to be maintained is one thing, but sometimes you can't rely on a single person's fork to be maintained. For example, if a developer forks a repo, then Kenna points to that developer's fork and then the developer leaves Kenna and no longer maintains the repo it's not a great situation. Ideally, the developer's fork gets merged and we go back to pointing at the original open source gem but since that is not always the case this is how Kenna has chosen to deal with it.

We require an admin to fork a repo to Kenna's organization to ensure we don't end up with a lot of unused repositories.

Would definitely love to hear how other organizations deal with personal repo forks!

That certainly makes sense regarding being able to maintain the fork within the company. I've not had this issue at a company I worked at, so don't have any further insight I'm afraid.

code of conduct - report abuse