Assumptions:

• There is an API for fetching image recommendations for specific articles, managed by another team. The API is fast so we don't need to cache recommendations in the DB.
• There is a corresponding "outcome" API (user accepted / rejected), also managed by another team.
• Invalidation of recommendations is not handled by us (or, initially, not handled at all).
• We will use the search index to identify tasks. Loading data into the search index happens outside of GrowthExperiments.
• As with Add Link, we are using a VisualEditor-based task interface ("Concept A") instead of something entirely custom-made on some special page.

Reusable / new parts on the backend:

• Most backend classes (the configuration loader system, the task suggester, the tracker) can be reused without any changes.
• Use the extension points for a new task type (subclass TaskType, TaskTypeHandler, TipTree).
• Generalize HomepageHooks::onBeforePageDisplay (which preloads the recommendation when rendering a task) to handle multiple recommendation types:
  • add an API client (the equivalent of LinkRecommendationProvider) for Add Image;
  • add a PHP type (something similar to LinkRecommendation + LinkRecommendationMetadata)
  • probably move the logic from LinkRecommendationHelper::getLinkRecommendation into the provider
  • probably have some TaskTypeHandler method for getting a provider
• Create the equivalent of the growthexperiments_link_submission table and AddLinkSubmissionHandler; create a generic SubmissionHandler interface.
• Make the VisualEditorApiVisualEditorEditPostSave hook use the appropriate submission handler.
• Update the form definition for SpecialEditGrowthConfig to handle image recommendations (needs to be done for link recommendations as well).
• Maybe generalize AddLinkSuggestionsHandler? We don't really use it though.

Reusable / new parts on the frontend:

• Update GrowthTasksApi.js to load image thumbnails from the image recommendation API instead of RESTBase
• Split AddLinkArticleTarget into a generic part (make the document readonly, hide the toolbar, disable or replace editor mode selection etc) and an Add Link part.
• Update Guidance.js to select the appropriate structured task module + onboarding dialog to load.
• Create the onboarding dialog for Add Image.
• Include some sort of error detection for things like the Commons image having been deleted, as initially there won't be any invalidation.
• Create the main dialog for accepting / rejecting images.
• Logic for finding the position to insert the image at. This involves:
  • detecting infoboxes
  • for pages without infoboxes, finding the top of the text (the border between top-of-article templates and text of the lead paragraph)
  • for pages with infoboxes, finding the image parameter and its syntax (just file name vs. full name with namespace prefix vs. full image markup)
  • maybe finding the parameter/format for image caption
• Do we need an annotation or something similar? Maybe a placeholder image, to be replaced by the real image?
• Create the Add Image equivalent of AddLinkSaveDialog.
• On save, accept/reject needs to be sent to the API. (Alternatively, this could be done on the server side, in VisualEditorApiVisualEditorEditPostSave.)
• Update instrumentation: create the equivalent of the link_suggestion_interaction schema, and generalize LinkSuggestionInteractionLogger to select the correct schema based on task type

Not counting the infobox part, which is hard to predict without having a more detailed plan / requirements, I'd guesstimate this to be something like 20-30 person-days to write. Assuming four engineers, no parallel project, half of work time spent on writing planned code (with meetings, code review, maintenance etc), and a Hofstadter factor of 2, that's 4-6 weeks.

Per T273236#7180828, we'll probably want to do T260522: Optimize number of results requested from API as well.

Most of these are now tasks under T288796: Add Image: backend tasks for initial release.

These have not been turned into tasks because they are more closely related to design, so they will be part of the corresponding design task:

• Create the onboarding dialog for Add Image.
• Create the main dialog for accepting / rejecting images.
• Do we need an annotation or something similar? Maybe a placeholder image, to be replaced by the real image?
• Create the Add Image equivalent of AddLinkSaveDialog.

Also not turned into a task because it needs an instrumentation plan first:

• Update instrumentation: create the equivalent of the link_suggestion_interaction schema, and generalize LinkSuggestionInteractionLogger to select the correct schema based on task type

(A part of T289211: Add Image: Generalize Add Link ResourceLoader modules is somewhat related.)

Changes based on recent discussions:

Invalidation of recommendations is not handled by us (or, initially, not handled at all).

It will be handled by us, but we'll only invalidate pages after a structured task action. That's similar to what we are already doing for Add Link, except that for Add Link we are also invalidating on normal edits and we don't want that here, so we'll need to make the logic a little more flexible. Tracked in T289217: Add Image: Handle differences in invalidation logic.

Logic for finding the position to insert the image at. This involves: (...)

We limit iteration 1 to articles without infoboxes so it doesn't actually involve most of what's written there.

We need to filter out articles with infoboxes. Could be done when generating the suggestions in T285816: Add an image: generate static file of suggestions but maybe better to keep it dynamic as adding infoboxes to articles is not that rare, and it seems like very little work. The task for it is T289216: Add Image: Allow excluding templates/categories per task type.

In T284778#7288282, @kostajh wrote:

Just noting that in T289024: Add Image: Backend handling of user acceptance/rejection of image recommendations it looks like we will be the ones managing this, similarly to link suggestions.

Indeed, AIUI Platform has no plans for working on that API for iteration 1.