Different users need to have different configurations based on welcome survey responses, edit history, and time. These configurations should be in sync with configurations leading to different emails in the email engagement project.

One of the themes with the modules, which I'll comment on more later, is whether we try to decide for the user what they see, or if we give them the ability to control their dashboard. There is also a middle ground – provide some sensible defaults based on the user's survey responses / edit history, and then make it clear to the user about how to override those defaults.

We need to consider options such that a given user's homepage is not visible to other users. In other words, users should only be able to see their own.

Right. Although we may want to make the "contributions module" at least configurable to be public, and we should keep the option open for a public facing side to other modules; for example Also, maybe we could provide an option for experienced editors to "Suggest a task" that gets displayed on the "recommended tasks" for a user, while keeping that users recommended tasks private to just that user.

---

Here are some existing ideas around where this homepage could be located:
For newcomers, replace Main Page with this new content.

From what I've seen, this could be pretty challenging to implement and might break things. We could, however, do something like:

1. user visits homepage
2. is user in treatment group? redirect them to Special:UserHomepage
3. Provide an ability to opt-out of the redirection in the prefs or directly on Special:UserHomepage, so that the user can get to the actual Main_Page again

Include it as an enhancement to Watchlist.

I'm skeptical about this. How do the two fit, conceptually? On a technical side, we'd have to work adding/overriding two special pages (Special:Watchlist and Special:MobileWatchlist). There's also already a lot of JavaScript loaded on Special:Watchlist, and adding our homepage content will make loading slower.

Include it as an enhancement to the user's Contributions.

Similar to above, we'd need override an existing Special page (both desktop and mobile, they're different) . I'm hesitant to add to that one.

Add it is a link up where the other tools are (Watchlist, Contributions, Preferences, etc).

This is the cleanest and simplest solution, without requiring us to interfere with anyone else's work.

Make it part of a user's User page.

If we make it part of the user page, would we just push the user page content down? Would this be part of both the view and edit of the user page? Would users be confused if they didn't see any of the changes they make in the modules as part of the user page history?

Make it an additional tab when they visit their User page, so that there are three tabs: User page, Talk, Homepage.

Yeah. Or we could mimic the "Contributions" menu item, which has three sub links (on enwiki anyway), and have "KHarlan (WMF)" expand to contain "User page, Talk, Homepage".

Instead of making it a page, make it a panel that can be opened from anywhere in the wiki.

We already have a proof of concept from doing this from the help panel, so we don't have to reinvent everything here. If we do this, we should still make the content accessible at a Special page for users without JavaScript, or users who decide to switch off the floating button but still want to be able to get to their customized homepage.

We could also consider the panel version of the homepage to contain just a subset of the modules (especially on mobile) and direct users to the Special page for the full experience.

---

Enumeration of modules:

Task recommendations: comprised of different task type tabs/subsections (copy editing, translation, expand a stub, add references, Create new article, "more"), with suggestions potentially configurable (e.g. "because you've edited")

For the first rollout, I would suggest we build off of the APIs being created for T209997 and T206504. We (I) need to research more on what APIs are available for populating the task recommendations feed.

Am I correct in viewing this as the cornerstone of the newbie homepage? Is this where we should focus most of our efforts?

Related changes in Topic, where Topic is one of those selected during welcome survey. Should allow adding/removing/changing topics.

Need to look into if there is existing code we can reuse for this.

Featured experienced editors, and number of edits in past 7 days,

Should the experienced editors list be configurable by admins per wiki? Or should it be based purely on stats?

Mentor: activity (edits in past 7days) and Talk page contact link, if mentorship was ticked in the welcome survey

What does the mentor–mentee connection process look like? If I want to list @Trizek-WMF as a mentor, do they have to approve this? Likewise, can mentors specify somewhere who their mentees are?

Should this relationship info be made public anywhere?

Your contributions (cross wiki, and latest edit)

This should be pretty straightforward.

Help (customized to user level), with link to help desk

Triggering display of different links based on user level (autoconfirmed users and non-autoconfirmed? some either criteria?) this shouldn't be too difficult. Wondering if we might want to consider changing the help links based on the task recommendation box, or providing an interface to toggle the links.

Looking at MediaWiki-extensions-GettingStarted, two example queries:

• https://en.wikipedia.org/w/api.php?action=query&list=gettingstartedgetpages&gsgptaskname=morelike&gsgpexcludedtitle=Egg_tart&gsgpcount=10
• https://en.wikipedia.org/w/api.php?action=query&list=gettingstartedgetpages&gsgptaskname=copyedit&gsgpcount=10

For the first one, we could look at page(s) the user has already edited and use that to populate suggested pages, we'd then have to look at those pages and figure out which ones need specific changes (copy edit, translation, etc) made to them.

For the task recommendations, we're probably also going to want the user to be able to click "Don't show me this again" for an individual recommendation, and that implies another UI for the user to manage their blacklist.

To summarize what I've written above for how we're going to populate the content in the task recommendation box, we will make two API calls, one to find a list of "morelike:" pages e.g. https://en.wikipedia.org/w/api.php?action=query&list=gettingstartedgetpages&gsgptaskname=morelike&gsgpexcludedtitle=Egg_tart&gsgpcount=10, and then a second API call will identify a list of of potential issues (copyedit, translate, add references).

Overall, I'm concerned that the scope for the task recommendations module might become too big for Q3.

One potential way to find articles to recommend is to search for articles in given task categories. For example, on the English Wikipedia there is a category called All articles needing copy edit. You can pass that as a parameter to search to restrict articles to that category, e.g. find articles about electric guitars that need copy editing.

You should be able to also use "morelike:" in that type of query, but I couldn't quickly write an example URL that works.

If the wikis we work with have similar categories, we could either have a specific search string for each topic, or a key article for each topic, and feed that to search to find articles.

Overall, I'm concerned that the scope for the task recommendations module might become too big for Q3.

I have the same concern. If we scope it down a lot, and take some shortcuts like the category thing Morten suggested, we might be able to do something more quickly. But I think it would be better to focus on simpler modules first. I'll dive deeper into some of the possible backends that were floated for task recommendations, and write a separate comment about that later.

The "neighborhood" module (recent changes related to topics chosen during the welcome survey) is simpler than task recommendations. It has some of the same challenges (having to identify which articles are about which topics, possibly using categories as a proxy, but then nested categories are an issue), but once we have a way to identify articles, embedding related changes should be pretty straightforward. (Rendering it in a nicer way as shown in the mock-ups is a little bit more work, but not all that much I don't think.) However, there's also talk of auto-detecting the categories the user is interested in based on their edits, and I think that'll be more complicated/challenging.

I think the "mentor" module (showing the person's mentor, their activity, and a link to their talk page) is a good idea, and pretty straightforward. Most of the work would involve tracking who mentors who, automatically assigning mentors to new users, and having a way to define the pool of mentors (and maybe a way to add mentors, or let them add themselves). With that infrastructure is in place, the "mentor" display is straightforward. The "featured experienced users" module would then be straightforward too, if we define "featured users" as users in the mentors pool (maybe excluding the user's own mentor to avoid duplication). We could also have two pools of users (one for mentors and one for featured), but I think it'd be good to reuse the mentors pool so that new users can feel free(er) contacting users they see in the featured users feed.

The "own contributions" module is probably the easiest one, and is also something that we might want to consider reusing elsewhere and in public view (maybe on people's user pages, or as part of a future user profile project). Cross-wiki edit counts are already available on Special:CentralAuth. However, I can't find a mockup of this now, and it looks like this idea has since been replaced with the impact/pageviews idea?

The impact/pageviews module is not listed in this task, but since it is in some of the Google Docs we've been using I'll talk about it too. The PageViewInfo extension provides reasonably easy access to pageview data for each page, broken out by day, for the past 60 days. Combining that with the user's contributions to figure out which pages they've edited and how many pageviews those pages have received since their edit should be pretty doable, with a few caveats. First, since the data is only broken out by day (not by hour or minute), it would take a while before recently-edited pages start appearing. Relatedly, we'd have to define whether the day of the edit counts (meaning we overcount) or doesn't count (meaning we undercount), and this affects how quickly we get a nonzero pageviews-since-day-of-edit number for newly-edited pages (0-24h or 24-48h respectively). We'd also have to define what happens if a user edits the same page twice, on different days. (We could also sidestep all these issues by showing pageview counts for the last N days regardless of when the user edited the page.) Second, sorting the list by number of pageviews (e.g. showing the ~5 most-viewed pages the user has edited) becomes infeasible once the user has edited more than a small number of pages (say, >50). We might instead want to show pageview numbers for the most recent ~5 pages the user has edited.

Lastly, I think "help" will be the easiest module of them all, because we've already written most of that UI elsewhere. Lifting and shifting this code will take a little bit of effort, but probably less than any of the other modules.

Lastly, I think "help" will be the easiest module of them all, because we've already written most of that UI elsewhere. Lifting and shifting this code will take a little bit of effort, but probably less than any of the other modules.

Hmm, I'm not sure it will be the easiest. It will be somewhat easier in that we already know what the configuration should look like, as well as the interactions but on the other hand:

• we probably want this and other modules rendered on the server-side
• user level is mentioned in the design slides but not in the "Engagement emails and homepage -- planning" doc; we don't yet have a configuration in place for showing links based on user level, nor AFAIK the criteria for what determines the user level
• the proposed help-panel-like interaction for posting a question to the help desk without leaving the page is going to be slightly different from the help panel implementation

So overall I'm not sure how much help panel code we can actually re-use.

---

Since we talked about the "Email status module" I'll add some notes for that here:

1. This module would show for users who do not have a verified email; users with verified email would never see it.
2. Users who have entered an email but have not verified it would see some visual cue about how to verify the email, and be able to trigger resending it
3. Users who have not entered an email would be able to input an email at which point they'd see the same content as the previous step above (here's how you verify)

This one would be straightforward to implement.