Symfony follows a somewhat established pattern when creating class hierarchy-internal APIs - typically, interactions between a base class that implements an interface, and subclasses of that base class that extend the base implementation provided - see, for example, the EventDispatcher:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Eve...
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Eve...
We've had a few debates around this kind of thing before. Example: prepending an underscore used to be in vogue, but was criticized at least for being a PHP4 convention as it was used to indicate a method was private - that became redundant with the native language support for visibility. IMO, there's no really ideal word to put there, but 'do' is at least nice because it's short, and actually does describe what's often happening: the base class is delegating the actual *doing* of the work to a subclass by calling this internally-agreed-upon method.
So I figure, this seems like another Symfony convention that it wouldn't hurt us to adopt. I've started by patching block plugins because I know we tried to achieve this same pattern by prepending the public interface method with 'block'. I'd argue that not only does 'do' make more sense for the block plugin case in particular, but there is good reason to adopt this as a convention even in cases where it may make a bit less sense: a consistent prefix helps to identify a consistent design pattern that *is* the exact same across all these different use cases. That is, were we to adopt this convention and I had never seen block plugins before, but I was aware of the convention, then by simply skimming the method list I would immediately know that this type of pattern is at play, and I could reasonably infer the relationship between the do-prefixed methods, the corresponding prefix-less methods, and the public interface.
There might be other examples of it, though, and if so then we should fix em all together at once.
...assuming we can agree that this is a good idea. :)