This ticket cannot be closed until we have removed data concerning wikidata sidebar link clicks from superset, therefore waiting for the go ahead from @Ifeatu_Nnaobi_WMDE

Findings from investigation:

• some of the service wiring tests just repeat the service wiring code ( “test that the code does what the code does”) for future maintenance. This means it is not super important have both TermLookup and PrefetchingTermLookup
• we have a few classes that only implement TermLookup but not PrefetchingTermLookup, and a few places that use those classes… but those places construct a special-purpose TermLookup for themselves (e.g. EntityTermsViewFactory::newPlaceHolderEmittingEntityTermsView)
• Ultimately, removing the getTermLookup loop (and always using getPrefetchingTermLookup) did not produce a noticeable reduction in load time for createSchemaElement, the object of this ticket's parent ticket. As a result, I don't think this ticket is worth it for the gains in efficiency

We will try a few small subtasks to address the load time for the schema:

1. T379169 - Remove a redundant getTermLookup - this redirects a few times back to getPrefetchingTermLookup, so it would be simpler to directly use the latter method.
2. T379170 - Create a new fetching method, getFirstRevisionTimestamp, for use in createSchemaElement which only fetches the minimum creation timestamp rather than whole revision history and ordering them for the oldest.

Hi @thcipriani, I haven't yet received the training on this so I'm not sure exactly what I will need, but I trust your judgement! I will also confirm with @LucasWerkmeister when he is back from AL, but restricted group sounds sensible. I can always reopen this if it turns out deployment is strictly required.

Patch set for Change #1083819 was mistakenly assigned to this ticket - please disregard

Hi all, I believe I have previously signed the NDA when I got basic LDAP access (https://phabricator.wikimedia.org/T366145) and confirmed when I got access to analytics-privatedata-users (https://phabricator.wikimedia.org/T371584). I'm happy to sign again though, or is it a different NDA?

We suspect that this ticket cannot be resolved until there is a more stable way to track usage in Parsoid, as per T354877. Therefore we will remove it from our prioritised tasks and continue to watch the Parent ticket.

I believe I have already signed the NDA when I got basic LDAP access (https://phabricator.wikimedia.org/T366145). In terms of access, I currently just need to use analytics-privatedata-users data, (requesting: Individual shell (posix) membership in analytics-privatedata-users group ), but I don't need the next row down (requesting: SSH key entry)

Yes I will need access to private data, just not ssh key entry