Problem/Motivation

Using this issue to prioritize the tooling improvements to Drupal.org that are needed to properly support JavaScript development using Drupal.org issues and our GitLab integration.

  • Choosing to put it in this queue rather than the Drupalorg Customizations queue so that it is easily visible to the initiative team.
  • We want frequent touch-points to ensure we're working on the most critical priorities first.
  • Child issues may live in the drupalorg customizations project.

Tooling Gaps and Prioritization

These gaps have been identified in this example GitHub repository: https://github.com/jsdrupal/js-client/wiki/d.o-Wishlist

Critical/Blocker priorities

Major priorities

  • Merge request pipeline testing - check whether this is a config option
  • Static page documentation publishing? Scope and determine core policies

Normal priorities

  • Credit work on official @drupal projects as if it were work on core
  • Discuss at Initiative Meeting Jan 26th - Ensure that configuration of the following types of CI jobs is possible:
    • Automated dependency updates/CI
    • CodeQL or other scanning and alerts
    • Automated dependency scanning(and updates?)/CI
  • Automatic publishing of documentation changes to api.drupal.org?
    • Current pattern: Parsing doc-comments from code and displaying on api.drupal.org
    • Related conversation: In-place api docs in Drupal admin interface?
    • Related conversation: Drupal's core apis vs apis added in libraries/modules?
    • Related conversation: documentation in code?

Nice to have

  • Pending further feedback: Improved project management tools (Kanban? Milestones? Issue moderation? Code owner delegation? Easier commenting/image upload
  • Complete(Pending further feedback):Gitlab and Drupal.org Integration: Managing code review comments/annotations in issue.

Comments

hestenet created an issue. See original summary.

drumm’s picture

hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
xjm’s picture

hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
xjm’s picture

Another non-critical followup for later on, /ht @nod_ -- Once npm publishing is working, we should see if there's a way to fill in usage statistics based on the npm stats for the JS projects, since they don't get usage data in the traditional sense.

It's a bit apples to oranges since their stat is "weekly downloads" rather than "weekly sites reporting usage", but we could probably aggregate total downloads from their data, and might be able to at least use the data somehow to provide project rankings (and in the marketplace algorithm).

xjm’s picture

I thought of a better solution for #9 in the middle term -- contribution to core packages as per #3195258: Provide a way of identifying projects that are part of core is core contribution, and should be weighted according to core's weight for the marketplace etc. If we hardcode that to start, we can work out down the road how to more fairly weight other non-core projects.

hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes

As per #3195258-4: Provide a way of identifying projects that are part of core, adding a bullet that work on the official JS packages should be credited as if it were work on core. I waffled between making it a normal priority vs. a major one. Added as "normal" for now, but feel free to bump the priority to "major".

drumm’s picture

Status: Active » Fixed

All the child issues are done, and I’m not seeing any other todos.

Status: Fixed » Closed (fixed)

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