Move gem to group ownership

[atz]

Increase bus factor. Options include: projecthydra-labs, code4lib, sul-dlss, etc.

[atz]

See: https://github.com/sul-dlss/engine_cart

[cbeer]

-0 . I disagree that it increases bus factor, and instead actively lies about who is supporting the gem (historically, just @jcoyne and myself..)

Of the options you list, 👎 on sul-dlss. It isn't a DLSS maintained gem, and I suspect there's litte code DLSS is using that cares. If it goes anywhere, it should go to projecthydra, but the process overhead is unappealing to me personally (but, happy for someone else to do the leg work..).

[atz]

Folks on projecthydra slack seemed uninterested in receiving the repo, saying "it's not Hydra-specific". I countered that basically the Hydra community is the userbase. Response: no, other people use it, too... like blacklight. Me: Essentially the same community, that's my point.

Right now we seem to be in denial about our dependency on this gem. It is no surprise that it is unmaintained when it has the appearance of not being "ours". Right now, you, me and jcoyne are all in sul-dlss, so I forked based on that.

[dazza-codes]

In my recent attempts to work on this, I had to fork it somewhere to create a PR on it. Since all my work on this falls under the Stanford DLSS agreements, it seems reasonable that I should be able to work on it in a repo that permits direct access to it. As my work at DLSS includes agreements with Hydra community, I don't care if it's in DLSS or Hydra github orgs. I do prefer that we have org access to create direct PRs on it and maintain it as org(s) under relevant org agreements and IP contracts.

[cbeer]

In my recent attempts to work on this, I had to fork it somewhere to create a PR on it.

I'm not sure I understand the problem here. Github supports pull requests across forks just fine.

[dazza-codes]

The problem is that this is used in various orgs and only one person can approve or deny PRs etc.

[dazza-codes]

I have to add that it's also possible that I might want to see other branches contributed by org-collaborators, without all the hassle of tracking N git remotes for all their forks.

Legally, I'm not sure what the status of this repo is with regard to my DLSS project work and whether I may be legally required to work on org-repos only. In general, I almost never worry about that, but I would be more comfortable working on this gem under an approved org github repo.

[dazza-codes]

I'm not sure I understand the problem here. Github supports pull requests across forks just fine.

I think the point of this issue is community ownership/contribution/maintenance should improve the contribution experience and the turn-around for contributions. In my recent experience, it's difficult to get fast turn around on contributions for various @cbeer repos, either because the PR review delay is on the order of weeks or because the requirements on some specific details need to change and the changes required are not specifically clear, so a PR can be left hanging for a while (like weeks). In the worst case, the PR takes a few weeks to get a review, the review requires changes and then those changes take a few weeks for further review and so on. The PR turn-around is on the order of weeks to months.

[jrochkind]

Is anyone using this for anything but blacklight/hydra related things? Or rather, is anyone who isn't employed by a blacklight/hydra-developing institution using it? How often do others developing blacklight/hydra run into a problem or issue of some kind of on engine cart that effects their development?

That seems relevant to me.

Much of hydra is historically only maintained by cbeer/jcoyne. I don't think that's an argument to move everything to live under github.com/jcoyne or /cbeer, or an argument for keeping anything there.

Of course, this is cbeer's code, copyright cbeer. He can solely make the decision of what to do in or with this repo. It's also open-source licensed code, which anyone, including the hydra org, can fork and do what they will with.

[jrochkind]

Whether Stanford wants to let mission-critical code be something cbeer owns and deals with in his spare time (?) is up to Stanford, I guess.

[jrochkind]

and of course, another possibility is adding some additional committers to this repo right here.