[policy, no patch] Publishing / Maintaining JS libraries produced by Drupal that do not have a dependency on Drupal

+1 to this idea! Having an "official" Drupal Github space would be an excellent step for hosting source code that shouldn't need to be in core.
Not only would it allow us to standardize on the expectations for a Drupal flavored javascript project, but it could open up future integrations with d.o such as links to project pages, maybe even some form of issue credits, and allow for the possibility of a core "ecosystem" - projects that don't live directly in core but extend it.

Suggestions for existing libraries to try this with:

• jquery.once - this was the library mentioned in this IS, and the work is already nearly done rewriting it in #2402103: Add once.js to core. Maybe a follow-up issue could be to move the js to github?
• jquery UI - the source code was added in 9.x in #3087685: Remove deprecated jQuery UI components and fork remaining source code into core, moving that source to a github project would be straightforward. I'm not sure if we could run the original qunit tests in Github actions but if so, that would be a big bonus and let us consolidate the tests being added in #3093172: Test coverage for forked jQuery UI components

There are future / in progress projects which would benefit from this organization as well:

• CKEditor5 - there's discussion and a prototype in #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10 but because it requires a build step we would need to consider having the source files for just the "build" in core. Putting that build on github would be cleaner and allow for faster iterations.
• JS Menu component - there will likely be several smaller js projects which won't even necessarily be used directly in core, having an "official" home would be a big benefit to give these projects legitimacy and have a single place for developers to find them.

Create an official space in github to "host" JS libraries produced by Drupal

I believe the DA has ownership of the drupal GitHub organization.

people contributing have to follow the Drupal community guidelines

GitHub has a norm of putting this sort of thing in a file named CODE_OF_CONDUCT.md. We could link directly to the Drupal Code of Conduct from that file as I've done here.

Documentation must be exhaustive and up to date (in code, probably generated from jsdoc, not on a wiki page in github)

💯

Require a few commands to be defined and working: build, docs, test regardless of what is used to perform those actions

❤️ this.

Drupal maintainers/committers are the only ones that can push new releases to npm

+1 to the restriction on who can commit. I think this is vital to the stability and "official-ness" of these projects.

Do you mean Drupal maintainers AND committers or do you mean maintainers OR comitters?

IMO, I think only committers should have push access, but I think we should consider a small expansion the number of Drupal committers.

The expectation is that a project manages it's own lifecycle and tooling, the "contract" is to ship quality code ready to use.

I think I agree with this, but "manages its own lifecycle" is a bit concerning. I don't think we want these libraries to increment 3 major versions within a single major version of Drupal—unless we clearly document what constitutes the public JS APIs (i.e. there aren't any) such that Drupal can upgrade to newer major versions of these libraries in minor versions of Drupal.

I see that you later you say:

Release cycle of libraries are not tied to Drupal release cycle, JS in general moves faster than core (for better or worst), making those packages (possibly) more useful to client projects outside of core

and it does make sense that we should be able to release more quickly than say, once a month, but that should only be applicable to minor and patch releases.

Perhaps there's a middle ground whereby these projects promise to maintain a particular major version as an LTS branch? It's really only the major versions that concern me.

There is less of a need to audit development dependencies (within reason of course), core will only make use of the generated result so security issues in the testing framework will not impact core for example.

Frankly, I think we should maintain a loose no-3rd-party dependency policy (excluding dev deps). I.e. no dependencies outside the Drupal org except in well-justified circumstances. We could start with this policy and relax it if it turns out to be unsustainable.

Almost a detail: we would ship with more minified code

I don't understand this. Can you explain why this is a benefit?

We will have many different tools to do one thing (different test tools, build pacages): will be necessary for some libs, not enforcing a tool doesn't mean we can's suggest one "by default"

Did you consider a JS mono-repo? If you did, what made you decide against it? I say that with a lot of trepidation because I don't want to derail this conversation with a bikeshed.

I discussed this with @nod_ shortly before this issue was posted. @zrpnr in #4 already brought the main points I was planning to make in support of this proposal. But a few additional benefits come to mind that I think are worth mentioning.

• Without this sort of policy, adding sufficient test coverage would likely require the addition of many new JS dependencies. An example of how unwieldy this can get can be seen in this agnonizing dependency evaluation of over 60 items for the jQueryUI fork tests. Drupal doesn't need the burden of additional test-only dependencies for a single library, and no contributor should have to create a 60 item table listing them.
• Earlier it was mentioned that this could "make those packages (possibly) more useful to client projects outside of core". There are specific issues that could potentially benefit from this a great deal. There are several issues, such as #2346973: Improve usability, accessibility, and scalability of long select lists where we are searching for UI libraries and are having difficulty finding ones that meet Drupal's accessibility standards. The option of creating a new library that meets our requirements is more feasible with the policy suggested here. Drupal is far from the only project looking for multiselects/datepickers/etc, there is legitimate demand for this. If the UI libraries developed for Drupal's needs are not inherently tied to Drupal (and D.O.), these libraries can benefit from a much wider range of contributors, and boost overall awareness of the project.

Two small things regarding the policy come to mind:

• Would "second party" libraries benefit from a change to the directory they live in, to distinguish them from third party ones? something like core/assets/vendor/drupal/<library dir>? A specific place this could help is to provide an additional cue that jquery.ui is a custom fork and not the main libray
• Similarly, would this benefit from introducing a documentation standard, perhaps something in the opening @fileblock that makes it evident that this project is under the Drupal umbrella, despite not being something that should be altered within core?

Sort of vague on purpose :p Like you said, committers only for NPM release + increase number of committers to take up the additional workload.

👍. I'm curious what @lauriii thinks would be a good policy suggestion to make regarding this.

whatever you document for other people to use is the public API (unless you tag something as @private and document just for reference).

I assume this is reference to https://jsdoc.app/ and #2182153: [Meta] Document Drupal JavaScript using JSDoc. Let's be sure to include this in each project's standard CONTRIBUTING.md file. Idea: once we have a few examples, perhaps we should make a template for new libs.

I agree with that: standalone vanilla-js libs only to start with and see how it goes.

👍

today all the *.js files are not minified, if we move some code outside, we can provide *.min.js files for core to use. …

Thanks for the explanation.

… monorepo …

Thanks for the reasoning. This satisfies my curiosity. I like the idea of reconsidering this after we have a few libs to manage.

For context, my thoughts were not very well collected when I brought this up. I was thinking that it would be nice to share a single .prettierrc file between all the projects, for example. It might also make it easier to manage evolution of the libs when they have interdependencies. But, like I said, I like the idea of reconsidering this later after we have some experience with these thing. A monorepo feels like and early optimization for problems we may not actually have.

Drupal doesn't need the burden of additional test-only dependencies for a single library, and no contributor should have to create a 60 item table listing them.

😱

Drupal is far from the only project looking for multiselects/datepickers/etc, there is legitimate demand for this.

This is a wonderful example. Providing high-quality, open source libs for these things will probably do more for Drupal's penetration into the JS developer community than any other thing we've tried!

Similarly, would this benefit from introducing a documentation standard, perhaps something in the opening @fileblock that makes it evident that this project is under the Drupal umbrella, despite not being something that should be altered within core?

I must be lacking some context because I'm not exactly sure what this is suggesting. @bnjmnm, can you expand on this a little bit? I like the idea of a documentation standard, do we already have a similar standard somewhere for PHP (or even JS) that we could draw from?

The remaining tasks at this point are:

Remaining tasks

1. Agree this is a good idea
2. Try it out on a library
3. Define the policy in details, find answers to the questions above and
   • which licence are allowed? GPLv2, MIT only?
   • Mirror code from github to drupal.org
   • Are we building the package published to npm from the code in gitlab or the one in drupal.org, etc.

1. Who do we need to get agreement from? I think everyone who has responded thinks this is a good idea. Are we done with this step?
2. I think the consensus is that the "once" library is the obvious first candidate for such a library. Agreed? If so, what is a concrete step we can take to "try it out"? Do we want to do this using the drupal GH org? If so, we need someone from the DA to help us get a project created. If not, maybe we should create an x-drupal github org (or reuse the jsdrupal org) and pretend we're using the drupal or for all intents and purposes. WDYT?
3. It seems like this is blocked on #1, above.

Doesn't drupal.org move to gitlab (self-hosted) soon? Rejected?

I'm leaving Drupal contribution because the slow commit rate and unfair treatment. (In another word: waste my time.)

Drupal maintainers/committers are the only ones that can push new releases to npm

If I don't own my code, I can't see how can I keep my productivity at contribution. Most great JS libraries are opinionated code. It's developed and maintained by a single person usually.

It's only benefit for current passion contributors + sub-maintainers. They can skip the commiter's approval now. Less reroll :s

we need core committer (especially release managers) to have a look and see if they agree with the proposal.

I will ping @catch and @xjm in their capacity as release managers. Also @lauriii and @larowlan since they most often interact with JS issues.

I'd like to have the thoughts of the people involved with the modernize initiative too because if I'm not mistaken, that's pretty much what they've been asking for this whole time.

I will also ping @webchick as a committer and as a PM for the JS modernization initiative. Finally, @justafish as a coordinator of that initiative and as a JS maintainer.

Doesn't drupal.org move to gitlab (self-hosted) soon? Rejected?

Drupal.org has been using self-hosted GitLab for over a year now. Per-issue forks for workspaces, #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces and merge requests, #2205815: Merge requests in Drupal.org issue queues?, are in opt-in beta testing right now, and we plan to enable them for all issues on all projects on November 10.

Cross posting from Slack

Other stacks and frameworks rely on independently developed components. Many projects even produce them so they are used cross-frameworks. They are typically hosted in whatever code hosting platform the people working on them feel more comfortable with. Then the project using them grabs those from a registry (npm, packagist, ...). This has the benefit to:

• Allow independent code hosting, ticketing, workflow, CI, etc.
• Provide independent governance.
• Allow different progress speeds.
• Attract devs from outside the parent project (realistically this is not ofthen the case).

Is the main concern the impact on governance?

Not speaking on behalf of the core maintainers, but knowing some of their concerns from prior discussions about Drupal.org tooling - I would say that the concerns are, yes, about governance, but also about fragmentation of effort/contribution.

Here's what I mean - for a project hosted on Drupal.org:

• The maintainer has registered an account on d.o (we have contact info)
• The maintainer has agreed to the Code of Conduct, Terms of Service, and Git Access Agreement
• Drupal.org maintainers can handle a mainatainership migration should the code be abandoned
• Issues are part of the same queue (credit is part of the same queue)
• The project is searchable on Drupal.org
• The project page + documentation + issue relationship is the same as any other Drupal project.
• All projects have the standardized GitLab repositories and collaboration tools (and as of Nov 10th, all projects have merge requests)
• All projects have access to DrupalCI and are included in our Composer endpoint.
• There is a standard process for security coverage for D.O hosted projects, and some integrated tooling (s.d.o)

That said, several of these points are much less relevant to JavaScript projects:

• We don't really have robust javascript testing infrastructure
• We don't need packagist endpoints for javascript components, we need npm
• And, as was said above, we already have other components of core that are not D.O hosted (Symfony, etc)

The Drupal Association does already control the Drupal namespace on GitHub, which gives us some, but not all, of the governance tools:

• We can control the maintainers of the Drupal namespace, and the repositories underneath it
• We could set up any necessary mirroring
• We can control CRUD operations for repositories and forks
• We could integrate into GitHub's existing tooling for javascript testing
• We could integrate with GitHub's existing npm listing capability

We would lose a lot of the workflow and change management processes if this were all hosted on GitHub, but we would be able to enforce the most fundamental governance that we might need.

I suppose the question is - do the benefits outlined in the IS outweight the decentralization of Drupal contribution in this area - and could many of those benefits be replicated in our now much more modern GitLab stack?

For myself, I find the proposal in the IS compelling, particularly since we're talking *specifically* about components that aren't dependent on Drupal and might be used outside Drupal. But I can certainly see both sides.

Not proposing an answer yet, just more food for thought.

Just wanted to say that this is a superb discussion. I can't think of any additional points to raise 😊I think this is the right time to reassess how we handle this.

#3176918-18: [policy, no patch] Publishing / Maintaining JS libraries produced by Drupal that do not have a dependency on Drupal is a good summary of what I'd have written. We've been very concerned about fragmentation of PHP code (and while we have non-Drupal PHP dependencies, we have a lot of trouble managing their varying release/support cycles these days), but this isn't really an issue with JavaScript - our problem is really the opposite that it gets stagnant in core.

Also when we added jQuery, it was a nice centalized solution along with jQuery UI, but whatever we do now to get off it is going to rely on multiple different libraries, since there's no modern equivalent that handles everything - so even a project maintained by two Drupal developers on github may quickly end up more active than some of the third party dependencies we've been looking at.

So broadly in favour of them being hosted and developed as separate projects - also most of our targets for this, at least initially, are going to be relatively small and self-contained.

I don't think the projects should rely on the existing set of core committers for commits - since there are only about three of us who can usefully review JavaScript as it is, so we'd either need to add additional core maintainers with a specific focus on js, or come up with some kind of new system where the github maintainers have an official role (like subsystem maintainers in core) that gives them commit access on github. Initial commits to core and updates would still end up going through the core issue queue.

we'd either need to add additional core maintainers with a specific focus on js, or come up with some kind of new system where the github maintainers have an official role (like subsystem maintainers in core) that gives them commit access on github. Initial commits to core and updates would still end up going through the core issue queue.

The second part of your remark makes me worry that we would still be treating core as the One True Project while holding these JavaScript libraries at arm's length. There's value in the perception of security and stability that comes with being part of Drupal core and I would like these JS libs to earn that same reputation. IOW, saying "that guarantee comes from it being committed and brought into core," it's slightly different than saying "that guarantee comes with this code because it _is_ core."

I think we can foster that perception by having some ritual for packaging releases of these libraries and pushing them to NPM so that they get the imprimatur of being an "official Drupal project".

It is probably too early to start solutioning but I don't imagine Drupal will bring in the dependencies with loose dependency contraints. In other words, to have Drupal core rely on @drupal/super-library-they-write from v1.2.3 to v1.3.4 there will be a core committer in the Drupal project pushing that button. So the "sign-off" per se will likely still exist.

Yeah we have issues like #2874198: Create and run dependency regression tests for core but it's not up and running yet, so at least until then we'd be having a Drupal.org issue every time we want to update to a specific version.

The second part of your remark makes me worry that we would still be treating core as the One True Project while holding these JavaScript libraries at arm's length. There's value in the perception of security and stability that comes with being part of Drupal core and I would like these JS libs to earn that same reputation.

So one possibility would be that people maintaining the js libraries on github are listed as core committers, but the minimum expectation would be that they review PRs on github (i.e. they wouldn't also be expected to review PHP or even front end patches on d.o, but someone could do both if they wanted to). Like a 'JavaScript library committer' role.

For what it's worth, I agree with #18, #21 and #24

And I think #24 is one of the most salient points here.

Sorry to be exhaustive about this, but I think it's important to be very explicit in order to avoid issues like these from getting caught in limbo states.

#24 and #25 indicate to me that, in principle, you both (@catch and @larowlan) think this is a good idea. Is that true? "This" being the proposed resolution minus the exact policy details we have yet to flush out.

If so, we'd probably like to to hear from @webchick and @justafish before we strike through the first step of the remaining tasks and move to try this out on a library, per #9, #10, and #14.

I'd like to have the thoughts of the people involved with the modernize initiative too because if I'm not mistaken, that's pretty much what they've been asking for this whole time.

Yes, I would love to do this! As well as hestenet's list in #18, in my mind there's been two major sticking points for this in the past -

• We'll need to hook into the script which packages Drupal as a tarball, as well as requiring node/npm|yarn for installation for people checking out Drupal from source
• If we can't do the above, core committers need to run the JavaScript build step when we change something, which they have not been comfortable with doing (which is totally fair - they already have a lot to do as it is!)

I keep getting pinged about this... I'm right in the throes of being absolutely slammed at work. so not sure when I can reasonably get around to responding (going to try hard to do so by the November 6 meeting)... no need to hold things up on me.

I will say though that I've read the IS and the comments so far and really appreciate the nuances that have gone into the brainstorming/discussion. In general, it sounds like folks are trying really hard to strike a good "middle ground" between quality control, governance, and developer empowerment.

@justafish #28

If we can't do the above, core committers need to run the JavaScript build step when we change something, which they have not been comfortable with doing (which is totally fair - they already have a lot to do as it is!)

There's a couple of (positive) caveats to this.

At the moment we only package specific versions of js dependencies in core, and each update requires a core patch. So development can happen on git***, and when there's a new tag to integrate into core, the core patch might have to build the js still. But this is one awkward patch each time core gets updated, not each commit to the library itself. A bit less work without actually changing anything (except the changes in this proposal...)

We also have an open issue for a core packaging build pipeline:

#3099100: Convert the release script to a Drupal.org build pipeline

WOOT! I think that's consensus on point 1!

Let's try this out on a library! I think we also have consensus that the jQuery once library is a good first candidate. @nod_, do you want to keep it under your namespace for the moment or should we move it to github.com/drupal? I'm indifferent.

As of this comment, we're here:

Remaining tasks

1. Agree this is a good idea
2. Try it out on a library
3. Define the policy in details, find answers to the questions above and
   • which licence are allowed? GPLv2, MIT only?
   • Mirror code from github to drupal.org
   • Are we building the package published to npm from the code in gitlab or the one in drupal.org, etc.

1. Done!
2. We're going to try this out w/ a jQuery.once() replacement.
3. Let's begin researching and drafting these policies.

Let's begin drafting these policies.

Where? Google docs? Drupal.org? Here?

Let's begin drafting these policies.

Where? Google docs? Drupal.org? Here?

My vote would be a Google Doc listed in the issue summary here for the initial policy draft - and then the canonical place should be part of the Core documentation on Drupal.org: https://www.drupal.org/about/core/policies

Your wish is my command @hestenet!

I started a doc here (I added it to the issue summary too). I took the liberty of ripping off the style and format of an IETF document (we'll call it "emulating" 🤣). I think this format makes it easier to communicate technical requirements and to discuss them.

Stopped discussions already? The current draft policy still very Drupal-specified. (I hope I'm wrong.) It's a dead circuit.

We have to make libraries reusable everywhere and able to acquire NON-drupal developers.

@see Chart below (click the link above for large version)

• To maintain MAIN repo in github.org, not shallow of d.org.
• Lean Code. Clean, Small, Fast!
• No same code requirements as Drupal is required. No Drupal Core maintainers only repo. (which can be 100% detached from Drupal I meant. You need not study a story book from d.org/doc to get started.) But yeah, reach a consensus on a basic standard is good for long-term development.
• Forked main repo as repo.drupal to add Drupal-specified code. Drupal Core Maintainers make their magic here to do slow releases to fulfill Drupal's requirements. Or the same workflow as now in d.org. Above main repo picked up 90~95% code development, only 5 ~ 10% left for Drupal-only. Drupal should always remove this 5~10 % to show it's flexible.) Sometimes, we should fork other libs before they join the Drupal foundation or upstream updates. For example, the VSCODE team forked and maintained their https://github.com/microsoft/chokidar version years before upstream pick up their requests.

Make Drupal Theme the same way, then we have a good Bootstrap-like framework for everyone. It's good for Drupal.

** chart source: https://excalidraw.com/#json=5726368989970432,GpM7O2zIggaa43ZUOBUdGg

The Drupal Association had our regular monthly check-in call with core maintainers today, and naturally this issue was a topic of some discussion.

@Lauriii raised some really thoughtful points, in particular, about some of the intangible impacts of our decision making.

Intangible Impacts

To paraphrase quickly:

• All of the considerations of tooling and testing are obviously hard requirements
• But we also need to improve that sense that javascript components and the initiatives to make them are first class citizens of the project
• And one of the let-downs of the last admin-ui javascript initiative is that the presence on github left them siloed from the Drupal project in terms of governance, visibility, brand, etc.

This is raising some new questions for me, and makes me want to hear from the current initiative participants, and javascript devs in general about what's important to them.

1. Setting aside the tooling - what are the intangible considerations that are important to you?
2. Is it important that these projects have a project page on Drupal.org (regardless of what toolset it links out to?)
3. Is it important that the work is recognized with Drupal.org contribution credits?
4. Is it important that the work is simply *visible* to the rest of the Drupal community?
5. Is it important that the work is happening in a 'familiar way' to other javascript projects?
6. Is it important that the work can receive easy participation from Drupal outsiders?

I know these intangible questions are very squishy and touchy feely - but understanding the answers would help bring us a lot closer to understanding the best way to solve the tooling and governance issues, I think.

For example, if the most important intangible element is 'being able to receive contribution from Drupal outsiders' that would suggest a different route than if the most important thing is 'being present within the Drupal community'.

Middle ground solution: Drupal.org + GitLab

When I think about all the ways that we've recently worked on making different kinds of contribution recognizable within Drupal, it at least makes me want to *offer* the best possible foot forward that Drupal.org could provide.

Remember, Drupal.org's git backbone is now GitLab and that does give us a lot of power.
We could:

• Make a new project content type for 'components' or 'libraries' with a drop-down for 'type' (e.g: javascript)
• Enable additional GitLab features for that project, such as GitLabCI and GitLab Pipelines, which can be integrated with many of the same javascript dev tools as GitHub(https://docs.gitlab.com/ee/ci/examples/), and could be configured by the maintainers, rather than being bottlenecked on the central DrupalCI config.
• Enable either the built-in GitLab NPM endpoint (https://docs.gitlab.com/12.10/ee/user/packages/npm_registry/), or automatically mirror to GitHub's /drupal namespace and publish to NPM that way (like we do for Drupal core components and packagist)
• Build new tools into api.drupal.org to handle javascript documentation parsing
• Suggest still using d.o issues - but we could even turn on GitLab's more simple issue queue so it could be used for kanban boards

These are all things we could do so that these Javascript efforts (and any other non-php Drupal efforts) can be first-class citizens of the project - with credit, d.o visibility, d.o documentation support, governance, etc - and the DA is absolutely willing to invest in that.

In the meantime, pre-release development of the new component could continue on GitHub, and we can compare feature by feature as the DA adds new capabilities.

How does that strike you all? Very curious for all of your thoughts.

I added some licensing recommendations based on the JS modernization iniatiative to the document - https://docs.google.com/document/d/1LkTeRac_UmEsXNx5du3IfXDwHEeR2nvw9zei...

Something happened today:

1.
I got the Drupal's Gitlab email today. At first sight, this is adding another extra layer to block your contribution more than help. I can't 100% tell what that Drupal Gitlab is and how it works by the way.

Simple tooling has never been a problem for developers, at least not for senior developers(, real contributors). Now, I can still fork it to use github/gitlab.com and that's FREE also.

2.
https://www.drupal.org/project/ideas/issues/2913628#comment-13686894
This is my first time knowing that an issue about Menu thing. That's 2 months late.

I want people without a drupal.org account to be Drupal contributors

Who are they? Drupal site builder? or anyone?

I've made a quick and dirty demo of how the D.O issue queue integration with merge requests presently works, just to provide something more concrete around that option: https://youtu.be/NIWCXE-aM6Y

If you have not been paying careful attention to the google doc, now is the time to sit down with it.

Please be sure to read the section on page 1 titled How to read and contribute to this document. Following those suggestions will ensure that no discussion gets forgotten/overlooked.

Our goal should be to alter the document until it represents something that we all agree on, not to decide up or down on exactly what it looks like today.

The first thing on your mind will probably be: Why does the doc look the way it does?

Since we tried to be extremely thorough and to consider every implication of our recommendations, from licensing to security coverage to governance (however small), it would be very difficult to discuss all the details via comments in this issue.

By using the RFC style (borrowed from the IETF and many, other, OSS projects) we can have discussions about specific details and collaboratively work toward a consensus on them without anything getting lost in the noise.

And one of the let-downs of the last admin-ui javascript initiative is that the presence on github left them siloed from the Drupal project in terms of governance, visibility, brand, etc.

I strongly disagree with this!

I'm +1 to @nod_'s sentiments

Just went through the whole issue, and now I wonder what in this is really JS-specific. Couldn't the consideration be extended to PHP components too, for the same reasons ?

Consider a very popular one like commerceguys/intl, for example. Used by lots of projects beyond Drupal, but still very much tied to Drupal, although for a contrib, not for core. Or the scaffold projects, currently on github.

Wouldn't these benefit from the same approach ? This would allow us to export some code (thinking of core/lib/Drupal/Component, specifically), to allow them independent maintenance instead of being just splits from core.

I think all the stakeholders have had time to weigh in on this. Uploading the Google Doc as a PDF so we never lose access to it (hopefully). There are still a few remaining TODOs and QUESTIONs, but I think we need to hash those out in practice within the library itself and the DA.

The DA has begun implementing many of the recommendations that it makes, @justafish and @nod_ have been appointed as new core committers to govern JS.

https://www.drupal.org/project/once has been published.

The next major milestone will be publishing that library to NPM.

Hopefully we can refer back to the doc to resolve some questions in the future :)

Our remaining tasks are as follows:

Remaining tasks

1. Agree this is a good idea
2. Try it out on a library
3. Define a set of policy recommendations in this Google doc
4. Agree upon the recommendations made above and canonicalize them here: https://www.drupal.org/about/core/policies

IOW, I think it's a little too soon to say we've have completed Try it out on a library since the project linked above doesn't have any releases on NPM, but we're close!

Once that happens, I think we can move to canonicalization/adoption of the RFC/policies and fill in any gaps and remove the TODOs/QUESTIONs in it.

Actually, Active is still more accurate, I think.

I scanned 20 pages. My summary is: "To share Drupal code to non-Drupal only"

It's very different from my expectations: To encourage and acquire more contributions [easy access & management + less Drupalism + better marketing portal].

I suspect this is what the original poster wanted also. Whatever, if this issue ends up in the current direction, I have another (better) suggestion.

First, isn't it more strict rules than Core development? (only 3.2.1 is more than Core.)

If so, why not change a bit of test standard in the current CORE development (, the only blocker) and build an automatic way to push part of code (components) to NPM. (It's very common in open sources) (Even as @fgm in #46 said: Make it to every components)

In Drupal (JS), the problem isn't a lack of committer to trigger Git. We have 100% RTBC patches commit rate. That's not enough Reviewer to set RTBC. Old contributors have no motivation and left the community or seek their own way to maintain patches privately
https://www.drupal.org/project/drupal/issues/2706483

Above 20 pages creating new (less power) maintainers. (and I can predict that's a very small group and may be the same current Core maintainers, no new players)

Now you can create a new role "SUPER REVIEWER" (as a virtual maintainer of this issue's suggestion.) and commit their work first. It's less work & confuses than the current new SPEC way.

Do the updates in #51 and #52 mean that this policy issue can be closed?

According to #52 there are documentation updates to do. What needs to be documented? Since this is tagged for an issue summary updated, it isn't clear if the information is the proposed resolution has been agreed to or not. At least, not to me.

What are the decisions here that need to be documented?

Wanted to bump this 1 more time or if it can be closed?

Working on reviewing this in detail with support from @nod_.

Created #3559157: Add 'Core JavaScript packages' core committers

The document needs to be reviewed to make sure it is using the new names for the core leadership team. For example, Drupal now longer has a BDFL.

And which guide will this be put into?