[policy] Document development dependencies

Discussed this with xjm and the short answer is that these pages needs a rethink.

These were created when there were fewer dependencies and predate composer and yarn. We have more dependencies now and it is no longer sustainable to list every one. So, there needs to be discussion on what, if any, of these need to be recorded here. Keeping in mind that the purpose of the page is to provide contacts for our major dependencies.

xjm pointed out that the composer meta data provides some of the information, although not all projects define it. "And things like the release cycle info or our known community contacts for a specific project are definitely not in the composer metadata.", from xjm.

I am changing this to a policy to discuss this further. Still needs a better title but perhaps later.

If we look at core/composer.json these are the PHP dependencies that aren't 'symfony, twig':

doctrine
guzzle
egulias/email-validator
masterminds/html5
composer
asm89/stack-cors
mck89/peast
sebastian/diff

Of these, none of them have the same security or API surface as symfony or twig (or ckeditor5), which is the main reason to have active upstream contacts.

doctrine, masterminds/html5 will probably not be dependencies in a release cycle or two.

guzzle, composer, peast, diff, html5 are all single purpose libraries that most developers won't interact with directly.

So, I don't think we would really get anything from adding them to the documentation page, but also I'm not sure I could come up with a one sentence summary of what makes them different.

@catch, thanks!

I updated the proposed text.

• jQuery and jQuery UI should be on the list for sure; we are very dependent on their release cycles and we have contacts with their maintainers.
• We also will need detailed sections about the various Autoupdates PHP components.

I'll have a think about others that should be on the list too for release management and security stuff.

Thanks for filing this; it should make the page a lot more maintainable to focus only on the key dependencies.

Two other things:

1. We should establish a best practice for which dependencies have their versions listed. I believe the list still has dependencies that were removed in D10. I think we should:
   • Add a note on the page if the dependency is to be removed in the next major version.
   • Remove listings when the last version to require them goes EOL.
2. Maybe we should instead have a way of tracking dependency evaluation issues (new issue tag?), and those issues should be expanded to include the contact details etc. That way we could get the info at need for less-important dependencies, rather than having to maintain the information in a second place. There could be a link to these issues at the top or bottom of the doc.

Maybe the tag should be very specific, "core approved dependency evaluation"

Rather, "approved dependency evaluation"

I completed the following

• Updated https://www.drupal.org/about/core/policies/core-dependency-policies/depe... → with the suggested text.
• Added a note to Current JavaScript dependencies → and Current PHP dependencies → about what dependencies to document.
• made a tag as suggested in #17.
• Added the tag to one issue 📌 Add open-telemetry/sdk and open-telemetry/exporter-otlp as dev dependencies Active

Anything to change on the PHP and Javascript dependency pages can happen on an ongoing basis, it doesn't need this issue to remain open.

Yes that sounds good to me, I think we can mark this fixed, tweaks to pages can then happen based on the policy.

Only moving to RTBC based on @catch comment in #19.