[policy, no patch] Exempt migrate_drupal from coding standards

We did the same when we introduced views into core though improved over time. I think promising something similar is a pragmatic approach.

+1, provided follow-up issues are added for code cleanup.

FWIW A lot of the spacing type issues might be able to be auto-cleaned with phpcs v2 with the new fixer functionality and the sniff standards from the coder project (coder sniffer sub project), you could run it and use the interactive git add to choose what was worth fixing, then just ditch the rest. Our initial testing of it was positive.

It makes a lot of sense provided followup issues for code cleanup, more tests.

If we're committing to fixing these coding standards problems, then I'd have thought it would be easier to do them before migrate is merged, on the basis that it's easier to get a patch committed to migrate than it is to core.

If we're not too bothered about the coding standard problems and don't mind if they are still around in a couple of years, then we should make this exception.

If automated tools can fix some easy ones then we may as well do that. Missing docblocks should probably be fixed, if only to help people who want to work on migrate in the future. Specifiying public/protected/private is definitely something better done sooner rather than later, because once people start using them it's hard to make them private.

If after that we've got some lines that are too long, or sentances missing their full stops, or whatever, then yeah, we should probably just commit it for the sake of progress and to more on to more important things.

I definitely think the migrate merge shouldn't be blocked on coding standards violations, especially not legacy ones. Views still wouldn't be in core if we had done that.

On the other hand, I do think coding standards should be respected in new commits being made to migrate, before and after any merges. To do otherwise is adding technical debt and future cleanup overhead needlessly.

I also agree with what's been said above about just trying to clean up whatever's easy (using automated tools or by hand) while it's still in a sandbox, because it's far easier to do so in the sandbox than in the core queue workflow. TBH those sorts of cleanups are best made in a non-patch workflow anyway.

The one thing we should pay more attention to is the minimum docblock requirements. We defined those to help contributors distinguish between what is critical to explain code, vs. what is simply intended to improve readability and scannability.

I'm -1 on this, but won't block it. I agree with others who've said that it's much easier to clean up these small whitespace or whatnot inconsistencies prior to commit into core. Especially since my understanding is there's an active migrate sprint happening right now at Drupal South.

And even though drupal_migrate is not an API, it is the only example core will ship with of how to write a migration from system X to system Y. That makes it arguably more important to get at least the docs gate right.

I'm plus 1 for not marking needs work for coding standards things that are not core gate minimums. But that's not an exception.

automated code styling cleanup sound fine to do now or later.

the sandbox has been speeding up things so they are not blocked on core commits...

but when coming into core, I think core gates minimums should guide us.
[edit: opened #2198733: core gates docs minimal requirements for next migrate merge with core ]

any core gates not met should get their own follow-up related issues to the issue that brings in the new migrate things so we can know and track what is still left to do (like tests, performance evaluation, etc...)

The problem with saying "it can be done later" is that it usually isn't, especially when it comes to documentation. So if you're going to make an exception, my vote would be that you need to be clear that it's a *permanent* exception and make sure you're willing to live with it. Permanently.

So, figure out what the minimum you're willing to live with is, and make sure that much is done. For instance, if I were reviewing a patch for an issue called "fix up the docs for...", I would care about indentation in doc blocks, but maybe not in this case. It doesn't maybe matter too much. On the other hand, completely missing doc blocks and undocumented code that someone is going to have to maintain down the road and try to figure out what's going on would matter more, I would think.

And if an exception is being made to the Core Documentation Gate, or any of the other Gates, also be aware that you're opening the door to other initiatives to want to do the same in the future.