Problem/Motivation

#2474007: Add a “General” project type to Drupal.org added a "general" project type that can be used for anything that's not a module, theme, or distribution, which is great! This was implemented primarily to support the RFC for standalone core JavaScript packages, but can be used for lots of other things as well.

However, we still need a way to identify which "General project" projects are part of core. There's an "Ecosystem" field on project nodes, but this doesn't really fit. It adds projects to a link labeled "Projects that extend this", which isn't a good fit because:

  1. All contrib modules and themes theoretically should be a part of that list.
  2. Anyone can add "Drupal core" as the ecosystem, but we want to create a list of projects that are officially a part of core, and only core committers and the DA should be able to add projects to the list.
  3. Many of the standalone JavaScript projects we want to create, like once.js, don't actually extend core at all -- core depends on them.

This issue might also relevant for publishing to npm, because it might be that only core projects should be published under the @drupal namespace.

Proposed resolution

Provide a restricted-access mechanism for indicating general projects are part of the Drupal core suite.

This is less important than publishing to npm in the first place or setting up custom GitLab testing build workflows for the projects, but will be relevant as soon as we start creating 1.0.0 releases for these projects.

Remaining tasks

?

User interface changes

?

API changes

?

Data model changes

?

Comments

xjm created an issue. See original summary.

xjm’s picture

Issue summary: View changes
drumm’s picture

This issue might also relevant for publishing to npm, because it might be that only core projects should be published under the @drupal namespace.

There won’t be any publishing to npm set up automatically. General projects might be JS, PHP, or any other language. They will all need to be hooked up to their respective package repositories one-by-one. For @drupal, we’ll use the credentials as little as possible.

xjm’s picture

Something I forgot to add to the issue summary is that work on the official standalone JS packages is considered work on core.

Since these projects aren't installed directly as modules, they don't get d.o's usage tracking and therefore by default don't get the commit credit weight of an installed project. I think anything that we agree to publish as an @drupal package should be hardcoded to grant the same weight of credit that is granted for core (e.g. for the Marketplace rankings etc.) We might also want to discuss a way to highlight this in the labeling of contributions on user profiles etc.

drumm’s picture

That is a good reason to make a field or some other way of storing this.

nod_’s picture

one topic is also the issue queue, by that i mean the actual list of issues related to core. Within core it's already a problem to keep up with javascript things (because we need to watch the Javascript tag on one page and the javascript component on another page), now we introduce a different issue queue that is part of core.

What I would like is to make a queue dedicated to core that aggregates issues from drupal, once, (and a couple other projects we'll build for core)
A nice to have would be to be able to filter based on component OR a taxonomy term.
(for now I have my own thing over here that does this)

drumm’s picture

Which projects exactly will be part of this initially? It looks like the JS is moving to a monorepo, #3221261: [policy] Decide what goes in the monorepo. Is https://www.drupal.org/project/once on the path to deprecation? Is https://www.drupal.org/project/ideas part of core too?

I see two components to this:

  1. Credit display on user & organization pages - Due to the complexity that was required of the issue crediting system, these Views are already complex and can be slow. I can’t think of a clean way to make a special case for merging issues for these projects under core. What can be done is additional labeling, such as “once.js in Drupal core” & “Drupal core ideas in Drupal core.” Depending on which projects this includes, the labeling might be redundant with what’s already in the project name. And I think showing the project name consistently will be more clear than trying to do something clever, like showing not-in-/project/drupal issues under Drupal core.
  2. Weighting when factoring issues for these projects into organization ranking

What I would like is to make a queue dedicated to core that aggregates issues from drupal, once, (and a couple other projects we'll build for core)
A nice to have would be to be able to filter based on component OR a taxonomy term.

Drupal’s issue queues are just Views, and I’m not aware of any modules which provide that level of flexibility for exposed filters. Anything for this would certainly be a separate issue.

  • drumm committed 26b33cc on 7.x-3.x
    Issue #3195258: Provide a way of identifying projects that are part of...
drumm’s picture

Title: Provide a way of identifying "General" projects that are part of core » Provide a way of identifying projects that are part of core
Component: Code » User interface
Assigned: Unassigned » drumm
Status: Active » Needs review
drumm’s picture

Status: Needs review » Fixed

This has been deployed. Credit listings now mention “in Drupal Core” after mentions of once & a11y_autocomplete.

The weights used for calculating organization rank have been updated for those two projects as well to have their usage equal to core’s usage when calculating marketplace rank for organizations.

nod_’s picture

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.