Presentation containing results and analysis has been shared with Tech Engagement team and will be discussed in person at our team offsite next week. After that, we'll be publishing on-wiki and sharing with / presenting to the larger community.

Just a note that in T323837 https://wikis.world/@mediawiki was created and is documented at https://www.mediawiki.org/wiki/Project:Mastodon

Task update: Raw data analysis is complete; synthesis / summary of results -- and preparation for presentation -- starts Monday 27 Feb.

In https://wikitech.wikimedia.org/wiki/Help:Trove_database_user_guide#Launch_a_Trove_instance, I documented a few of these items based on discussion with @Andrew about guidance that we could provide (at least in docs, if not in the UI itself).

Status update: met with @Andrew to finalize the draft (weeks ago); published on-wiki and updated links: https://wikitech.wikimedia.org/wiki/Help:Trove_database_user_guide

This has been published, thanks to @apaskulin and to all the authors! It's a great post :-) https://techblog.wikimedia.org/2023/02/24/from-hell-to-html/

As of 2023, we are temporarily pausing new blog posts as we work to clear out our backlog of unpublished posts and figure out how to manage the blog going forward. The Developer Advocacy team has reduced capacity in the first half of 2023, so we hope you will be patient with us as we try to work towards a more sustainable way to share tech stories.

I don't have any context on this project so I can't provide really specific guidance. My general advice is that you should structure documentation around user tasks, not around the tech you're building, so the documentation should be around things like "how to deploy your first project" and "how to set up automatic deployment" rather than "build_service". You probably already have documentation about many of the user tasks / workflows that this new service will impact, so you should look into updating that instead of creating new separate docs. So, for example, you would probably need to integrate the changes that the new Build Service provides into documentation like this https://wikitech.wikimedia.org/wiki/Help:Toolforge/Auto-update_a_tool_from_GitHub (I am just guessing; I haven't had time to really develop technical expertise in this area of WMCS yet, but hopefully you get the idea behind what I'm saying).

Status update:

I tweeted about this on MediaWiki's Twitter: https://twitter.com/mediawiki/status/1620845204357120001
And retweeted that tweet from @wikimediatech.

Task update: I've shared a first revision of this doc with @Andrew and need to follow-up / get answers to comments before I can share a more polished final draft.

I had a thought about this upon waking and am sharing to hopefully be helpful and not annoying: after the first week or so of necessary meetings and setup tasks, it would be great if our onboarding docs could be more structured around topics or core competencies instead of just by timeline. In my experience and in what I've observed in subsequent team members' onboarding, the timeline as laid out in the current template our team uses doesn't reflect reality, and is not very balanced in terms of the types of tasks or content -- it's very reading-heavy, but some things you should read very early, like the Code of Conduct, aren't even listed until week 2.

There is a bit of related content at https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge. It should probably be combined with the info at https://wikitech.wikimedia.org/wiki/Portal:Toolforge/Admin/System_Overview or connected, but in a way that provides affordances for both users who only want the high-level info and users that need to navigate further into the detailed system info.

@apaskulin has kindly agreed to help out with this since Developer Advocacy has low capacity due to Melinda's departure from WMF. Thanks everyone for your patience!

Marking this as Declined due to inactivity and change in direction.

I finished copy-editing the text of this post, and left just a couple of clarifying questions. I also added captions to as many of the graph/dashboard images as I could. This is ready to be published as soon as we resolve the open comments on the doc. Thanks!

After discussion with the team, I'm going to remove it as a sub-task of the social media strategy task (T327213) because it is more about defining the role of Developer Advocacy in facilitating the flow of information between various spaces across the tech community, especially between volunteers and WMF, with potential goals like creating connections and reducing duplicate work. So, it's larger than social media strategy, but also is still stalled because we remain in need of a clear set of team goals and policies around this type of work.