@wouterj I want to make sure I get this merge correct: this should apply toonly the 2.3 branch, correct? And so when this merges into 2.4, we'll need to revert it there.

@weaverryan That's right. Theversionadded directives for the data collector extension already have been added in#3887.

@xabbuh I decided to remove all class directives in the sidebar, to be consistent and they don
don't add any value

@wouterj I understand your concerns. Though having fully qualified class names rendered in the documentation looks pretty ugly to me. That's why I'd prefer theclass here in favour of putting the FQCN in literals.

@xabbuh tbh, I don't like to use the:class: API links everywhere in the documentation. In most cases, they don't add any real value. The only good thing about them, is that it allows us to "hide" the FQCN, but at the same time making it also available on hover.

I think we should make a new directive which does only that, without the link.

Of course, building such a directive should be very easy since we could reuse most of the code from theclass directive. Though, what do you dislike of the the API links?

@xabbuh let's take this case as an example. The class shows as an implementation example of the listener for a specific event. I don't care what the signature of the class is (in fact, everyone with a basic event system knowledge knows that it has agetSubscribedEvents method, another method and properbly a constructor), I care about the implementation. If there is anything the classname should link to, it should be the github code.

I agree. Inthis case, we're saying "hey, look at this core code so you can learn from it!" - so in this case, the API docs don't help (and like Wouter said, a link to the GH source code if anything would be appropriate - perhaps having an extension to make this link with the proper version would be nice). Anyways, I'm +1 for what we've done here, and in general, we'll just be thoughtful whenever we have a class :).