I'm one of the Community Relations Specialists. I talk with readers, editors, volunteer developers and staff so that they can know each other, know what they do, what they expect and what they hope for. I mostly work with the Growth team and the Editing team around new features that help newcomers to become mong-term editors successfully.
User Details
- User Since
- May 25 2015, 2:42 PM (461 w, 3 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Trizek (WMF) [ Global Accounts ]
Yesterday
Wed, Mar 27
As we deployed the feature on Discussion Tools/VE for talk pages with a way for users to opt-out, I think we are safe to deploy, as users who opted-out will remain opted-out from auto-subscription no matter which editing surface they use, correct?
I just published the report: https://www.mediawiki.org/wiki/Structured_Discussions/Deprecation/Report
Mon, Mar 25
As a reminder, the extension's name is CommunityConfiguration, while the public name is Community Configuration (without 2.0 anymore).
Thu, Mar 21
Special:Log/abusefilterblockeddomainhit lists all attempts to add a blocked by URL to a wiki. Peter and I discussed this yesterday and agreed that a new tag might not be needed because of the log.
Do you mean editing messages locally?
If so, as we are progressively moving to Community Configuration, I think it would be better to have it inside EC's configuration.
If not, can you clarify, please?
Wed, Mar 20
The link we will add to know more must be community configurable, and a fallback link should be provided.
Debrief with @jijiki:
The read-only time can happen between 14:00 and 14:30 - the time window allocated by SRE - depending on how smoothly the process goes. As a consequence, the banner shown on wikis should stay longer: at the moment, it is displayed from 13:30 to 14:01, but it should be scheduled to last until 14:30. SRE and Movement Communication reach at each other to declare the read-only done, and then the banner is deactivated.
I updated the documentation accordingly.
Tue, Mar 19
I just tested it in production, and it seems to be working as we designed it.
The few reactions I observed from communities came from users who thanked me for the information message I sent last Friday.
Fri, Mar 15
Thu, Mar 14
Wed, Mar 13
Tue, Mar 12
Thu, Mar 7
Mon, Mar 4
The message was updated to remove the idea of a test. As everything is okay, I can continue with the next steps.
Fri, Mar 1
Thu, Feb 29
@jijiki, I'll be your host on this journey.
Feb 26 2024
Thank you @jijiki! We will start the process very soon.
Feb 23 2024
Feb 22 2024
Feb 21 2024
For Tech News:
The [[mw:VisualEditor_on_mobile|mobile visual editor]] is now the default editor for users who never edited before, at a small group of wikis. [[mw:VisualEditor_on_mobile/VE_mobile_default#A/B_test_results | Research ]] shows that users using this editor are slightly more successful publishing the edits they started, and slightly less successful publishing non-reverted edits. Users who defined the wikitext editor as their default on desktop will get the wikitext editor on mobile for their first edit on mobile as well.
Feb 19 2024
I am waiting for the two last tasks to be finish before resolving this one.
Feb 16 2024
I confirm the bug, at other wikis.
I agree on the severity, but it is not an absolute blocking bug (VE not loading at all would be): I lower the priority and ping the engineers. (Don't forget that we are Friday.)
Feb 15 2024
My understanding:
- This page was created to show the local configuration of notifications and to allow users to edit it (the latter was never built).
- two levels of personalization were set: newcomers and experienced editors
- we now have the possibility to enable local configuration of notifications but only based on a start date: "before" users would have a different state than "after" users.
- the special page would become useless, as it won't reflect the date state
- upgrading this special page takes time and is not scoped.
Feb 14 2024
Okay, it makes sense. I agree with you: solution 2 is the best choice. It requires a little bit of design, but as most listed elements are defined with a pivot date, we can have a state for before and a state for after.
Using my WMF hat there, I think we should be careful about enabling this feature.
Feb 13 2024
Thank you for the precisions, Tacsipacsi. I think all my tests with this demo are just perfect failures! 😓
From T345298, we can proceed with the following wikis:
- arwiki
- afwiki
- frwiki
- itwiki
- jawiki
- ptwiki
- swwiki
- yowiki
- viwiki
- zhwiki
Reducing priority, as I'm just monitoring Spanish Wikipedia.
I'm getting a "No valid recipient found" message, but I assume this is due to the test environment. Otherwise, it looks nice!
Thank you @matmarex.
Feb 12 2024
The page was created to allow communities to see the defaults, and, possibly, to allow them to edit it.
This page is not really used AFACT, I use it sometimes to check if a config wasn't changed locally. While it is good to remove unused or replaced features, if we remove anything here, we have to document it.
I must be dumb on this, but aren't we supposed to have a test account given for each patchdemo?
Feb 9 2024
I documented the limitation in the docs, I'll update it when the proposal will become a patch.
@nayoub told me he prefers alt 2.
Yeah, I suspected that we could not do much there. Perhaps adding a community configuration to generate short links as the default link?