Add DDEV Drupal Contrib for ease-of-maintenance

So long as it is kept up to date.

If it becomes neglected we should not hesitate to remove relevant parts.

For local dev also, this project will install everything it needs for linting by a `composer install && make lint` in the project directory. This should continue to work also.

I dont really operate like this with my contribs though, I typically install a contrib within the context of a site, whether ddev or not, alongside other contribs.

A relevant note: I recently rejected ddev scaffolding like this on SM, as I actively maintain that project and don't want ddev pieces. But since you are actively maintaining, I will not hold back in this project.

Thanks for the thoughtful response! Totally fair—if the DDEV setup ever becomes neglected, I have no problem with it being removed. I’m happy to keep it up-to-date as long as I’m actively contributing here.

Also, thanks for the note about make lint. I hadn’t noticed that was already in place—very helpful. The DDEV setup shouldn’t interfere with that workflow at all, but I’ll add a note in CONTRIBUTING.md to clarify how it fits alongside the DDEV tooling.

Another approach could be to include all the commands in the CONTRIBUTING.md file, to get the optimal DDEV environment up and running for a project, since I see there are commands to run in CONTRIBUTING.md:

https://git.drupalcode.org/project/calendar/-/blob/8.x-1.x/CONTRIBUTING.md

I wonder which commands are saved by including the .ddev folder? If it is mainly running ddev config --project-type=drupal and installing Drush, then it seems to me a bit overkill (and in danger of versions getting outdated) to commit .ddev, and the commands ddev config [...] and ddev composer require --dev drush/drush could instead be included as well, but maybe there are a fair deal more commands, and adjustments?

@ressa It definitely will get out of date eventually—no argument there. I may be able to wrap something like make lint into a ddev lint command, but I’ll probably keep them separate for now to avoid stepping on existing workflows.

The main benefit for me is having a consistent, isolated way to stand up this project for manual testing, without relying on a possibly patched version from another project or a contrib testbed with unrelated modules. I totally get the concern about long-term maintenance though, and I’m happy to revisit the setup if it becomes a burden. Though I am planning on keeping it up-to-date, so the burden is on me.

Thanks for clearing that up @joelpittet. I do get the benefits of having a consistent and predictable development environment, which you know the ins and outs of -- that's always great to have.

Also, we can only progress by experimenting, and trying new things out, and the insights gained might result in constructive feedback-worthy experiences for the DDEV Drupal Contrib project itself, which may get implemented, so that it may improve, to the benefit of all the other Drupal projects in the end.