admin
admin copied to clipboard
Transfer DataDog/import-in-the-middle to the org
Several years ago, we (Datadog) created import-in-the-middle. Modeled after require-in-the-middle, it provides a simple layer for intercepting module loading using roughly the same API as require-in-the-middle, but for ESM, using Node.js loaders. It also manages differences in the loader API across Node.js versions, since our users use a wide range of Node.js versions with ESM.
The project has been a resounding success, and is now in use by several other organizations in the APM space, such as Elastic, NewRelic and OpenTelemetry. As a result, these other groups have submitted PRs, and been helpful in collaborating. At this point, we'd like to open it up even further, handing over governance of the project to a wider group, to ensure that Datadog is not a blocker for releases or maintenance.
Rather than form a separate entity/org to own this, we think that the Node.js org is an ideal place for this library to live. To that end, we're requesting a transfer from the DataDog GitHub org to the nodejs GitHub org, with governance by the TSC, but delegated to the Diagnostics WG. This governance structure aligns with other projects in this GitHub org.
Anticipated Questions
- Why this org and not another one, like OpenTelemetry?
- The Node.js project already shows a commitment to observability, and while OpenTelemetry might seem like another good home, we think
import-in-the-middleis much lower-level than OpenTelemetry (in much the same waydiagnostics_channelis), and has use cases outside of OpenTelemetry's scope.
- The Node.js project already shows a commitment to observability, and while OpenTelemetry might seem like another good home, we think
- Why this org and not a higher-level scope, like OpenJSF?
- We think that the correct scope for
import-in-the-middleis Node.js, since the library can only be used with Node.js, and exists only in that ecosystem.
- We think that the correct scope for
- Why the Diagnostics WG?
- There's already a lot of overlap between the Diagnostics WG and the set of stakeholders in
import-in-the-middle. Primarily this means APM vendors. That said, if desired, a new team could be formed specifically for maintenance ofimport-in-the-middle, initially composed of its most frequent comitters. This team could also be under the Diagnostics WG's purvey.
- There's already a lot of overlap between the Diagnostics WG and the set of stakeholders in
cc @nodejs/tsc
SGTM
SGTM
SGTM
+1
SGTM
@bengl What remains to be done here? Can we press the button now?
@bengl Can you initiate the transfer to the Node.js organization?
We're happy to transfer it, so long as the receiving party (@nodejs/tsc, or more likely @nodejs/diagnostics?) indicates that it is prepared to maintain it.
I'm interested in maintaining it.
cc @nodejs/tsc wdyt?
As a representative of @nodejs/diagnostics I think we're good with owning that, but of course contributors need to exist for maintenance to happen.
+1 :)
Also interested in maintaining it 💪🏼
On behalf of the Node.js agent team at New Relic, I am willing to participate as a maintainer.
Hi all - what is the status on this?
As part of the JS team at Sentry, I'm also happy to participate as a maintainer, and I know some others on my team are interested.
The Sentry team has also started to contribute some PRs as fixes (https://github.com/DataDog/import-in-the-middle/pull/78 and https://github.com/DataDog/import-in-the-middle/pull/79), and we're putting time into helping triage and solve more issues!
I'm also happy to dedicate some time to this as we're using this package over at the open-telemetry/opentelemetry-js repository. :slightly_smiling_face:
@Qard @bengl Because OTEL depends on this package, this became a blocker for us (Sentry). Is DataDog still interested in moving this to Node.js organization?
@nodejs/tsc If DataDog is not interested, would you be interested in forking and releasing under "@nodejs/import-in-the-middle" to ensure that it is maintained properly under Node.js organization?
To be clear, yes we/Datadog is still interested in moving this to the Node.js org. Apologies for unintended delays. I'm ready to make the transfer happen (unless there are permissions issues that I'm not aware of, which I'd sort out promptly), but some things need to be addressed:
- Once it's transferred, maintenance needs to not be blocked by process, or waiting to see who maintains it. Is @nodejs/diagnostics taking on that responsibility, or will it be a new team? I'm guessing this should be discussed and resolved in https://github.com/nodejs/diagnostics/issues/634 ? (Note: I'm fine with deferring on this as long as the repo doesn't go unmaintained in the interim. I just want to make sure that no one's blocking anyone who relies on this repo today.)
- How should the transfer of the npm package proceed? (i.e. to whom)
- Does the repo require any changes (e.g. in metadata, Markdown files, etc.) in order to be transferred to this org?
I'm happy to help with maint as well.
I think to move this forward and make sure that maintainers/maintenance can continue we should
- create a team called import-in-the-middle-maintainers that we can use to configure who has maintainer rights on the project once it is in the nodejs org.
@bengl can you provide the list of people you think should be in that list to start. Going forward it would be up to the existing maintainers to nominate/add new maintainers.
- add the nodejs-foundation npm account to the package in npm. To start that would be a backup so that the project can add additional maintainers if necessary at some point. It may be used for automation at some point but that could be later. Seeing that the only current maintainer is datadog I think we should also add the inviduals who are expected to publish so they can do so manually until any automation is setup.
@bengl does that makes sense to you?
can you provide the list of people you think should be in that list to start.
Here's a starting list, but I'm sure there will be more I've missed. Note: If I've missed your GitHub handle on this list, my bad. Let's rectify that ASAP.
- @bengl
- @Qard
- @trentm
- @jsumners-nr
- @timfish
- @anonrig
- @AbhiPrasad
I think that covers 3 different APM vendors, plus OTel.
add the nodejs-foundation npm account to the package in npm.
~I can do that this afternoon. Will edit this msg when that's done.~ This is now done.
Created @nodejs/import-in-the-middle-maintainers team and invited people in the list. Please let me know if you wish to be on the team as well.
@bengl could you verify if you have sufficient priviledge to transfer the repo?
accepted the invite so that the nodejs-foundation npm account now has access to the package in npm.
@legendecas verified.
Here's a screenshot of the UI allowing me to do this.
@bengl please feel free to go ahead. Once it is transferred, I can help with setting up the access with @nodejs/import-in-the-middle-maintainers.
A Code of conduct, Developer Certificate of Origin, and a license line could be added to the repo after the transfer. (example)
Hey folks! I'm going to go ahead and transfer the repo within the next hour or so, barring any hiccups. A TSC member will have to assign the rights to the team. I spoke with @mhdawson about that since we're in the same time zone, and we'll coordinate the timing on Slack so that there's no (or minimal) interruption in maintainership.
cc @jeremy-lq
The repository has now been transferred.
I just added the import-in-the-middle-maintainers to the collaborators and teams with the maintainer role.
I also left @bengl and @Qard as admin for now until we make sure that things are all set up.
Closing as the repo was transfered and access was setup.