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
- Done:
Project type on Drupal.org for 'libraries/components'#2474007: Add a “General” project type to Drupal.orgWebIDE - Just comes with GitLab- Follow-up: #3195258: Provide a way of identifying projects that are part of core
- Done:
Enable GitLabCI for pipelines Integrated Workflow and Build PipelinesConfigure initial 'instance size' for GitLabCI runners/k8s clusterReserve this for *just* the decoupled initiative project for now, so we can make changes quickly- Test: Secrets management
- Test: Publishing to NPM
- Follow-up: Verify additional configuration/bugs found when configured for the first project.
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
@drupalprojects 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
Comment #2
drummComment #3
hestenetComment #4
hestenetComment #5
hestenetComment #6
xjmPosted #3195258: Provide a way of identifying projects that are part of core.
Comment #7
hestenetComment #8
hestenetComment #9
xjmAnother 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).
Comment #10
xjmI 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.
Comment #11
hestenetComment #12
hestenetComment #13
xjmAs 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".
Comment #14
drummAll the child issues are done, and I’m not seeing any other todos.