So far all we've gotten are questions at the Village Pump discussion, no suggestions. Let's keep an eye on it though.
Here's what the email notifications look like now:
There has been a failed attempt to log in to your account from a new device. Please make sure your account has a strong password.
@Niharika: Thanks for digging into this. Future developers and wiki admins will thank you!
Yes, I'm available for the ArchCom meeting next week. I've added myself to the calendar invite.
Would anyone object if I pick this up and run with it? I'm thinking of scheduling it for Friday, May 12th. Does that conflict with anything important?
@Umherirrender: Moving an article seems like an "edit" to me (in the general sense) as you are changing the title of the article. Same for creating a redirect. While it's true that it isn't done with the Edit tab, it's still making a visible change to the page.
We still need to report this data back to the page patrollers on English Wikipedia and would really appreciate any assistance. Unfortunately, this is an out-of-process request that arose from an emergency situation (English Wikipedia threatening to restrict article creation to auto-confirmed users). Without good data we don't have much influence in this situation, or even a way to make an informed decision about the WMF's position on the issue.
Thu, Apr 27
@Umherirrender: I'm confused. You're saying that we shouldn't try to make user_editcount more accurate?
- Specifying the content-type of content within a set of tags. For example, specifying that content inside <phptag> tags should be highlighted as PHP code or that content inside <ref> tags should be highlighted as WikiText code. This seems sensible and needed.
- Adding class attributes to all tags. This allows anyone (users, wikis, extensions) to customize the highlighting of the tags. For example, a user could edit their User CSS to only highlight ref tags if they are especially interested in improving references. It would also be possible for a wiki to customize the highlighting for all users of that wiki by styling the classes in the Common.css for the wiki (although this is not a likely use case). It would also be possible for an extension to customize the tag highlighting for any particular group of users (or all users) with it's own CSS file. That doesn't mean that extensions are actually going to utilize this ability, and as Pastakhov mentioned, abuse of this could be prevented via code review. All tags will be highlighted as green by default, so there won't be any expectation or need for extensions to create their own custom tag highlighting (unlike Pastakhov's previous implementation). If we want to support the ability for users to customize their own highlighting (which seems like a legitimate and useful use case), this seems like the best way to achieve that. Unfortunately, there isn't any practical way to allow users to customize the highlighting for themselves that couldn't also be used by extensions or wiki admins to customize the highlighting for everyone.
Sounds good to me.
@srishakatux: This might be a good Hackathon project.
In that case, it sounds like we need to call $user->incEditCount() during page moves.
@DannyH: Understood. Since this is also going to be the page linked to by 3rd party wiki login notifications, we should probably host it on MediaWiki.org rather than Meta.
I bet @aaron will know :)
@DannyH: "Help:Login_notifications" seems a bit limiting in scope. How about "Help:Account security"?
It looks like we don't use the user_editcount column because it is considered "approximate", which begs the question, why is it approximate?
Although I support everything suggested by @jmatazzoni, the original scope of this request was just the developer documentation. Perhaps other tasks could be created for the User and Requesting documentation.
Wed, Apr 26
Now we just need to wait for Addshore to cut a new version.
@Niharika: Merged. The only thing left to do on this task is to correct the documentation for LoginNotifyEnableForPriv (see discussion above).
See question at T163916#3214766.
Why do we not want to use the user_editcount field in the user table?
Mon, Apr 24
This is pending a Tech News announcement which should happen next Monday (May 1).
@Gradzeichen suggested changing the wording to "Please make sure your account has a strong and unique password."
... account. Please make sure your account has a strong and unique password.
Seems worth considering. It is true that we want to keep the message short, but encouraging people to use a unique password is also a good idea. @DannyH: Any thoughts on this.
@Niharika: Draft looks good.
Sun, Apr 23
@Halibutt - PageAssessments (https://www.mediawiki.org/wiki/Extension:PageAssessments) is mostly a tool for WikiProjects, which is not a concept that exists on all wikis. It's data model is:
Page : WikiProject : Class : Importance
This data is used in a variety of contexts, many of which display the WikiProject assignments. We could theoretically set up PageAssessments on Polish Wikipedia, but because Polish Wikipedia doesn't have WikiProjects (as far as I can tell), I don't think it would work that well We would have to assign all the assessments to 1 imaginary WikiProject and this imaginary WikiProject would show up in all the interfaces that use the WikiProject data from PageAssessments (like CopyPatrol). I think a better fit for Polish Wikipedia would be to use the Wikidata badges (https://www.wikidata.org/wiki/Help:Badges) since this corresponds closely with the Polish quality assessment categories (good and featured articles are both supported), but isn't tied to WikiProjects.
Sat, Apr 22
Here's the current email notification (for failed attempt from unknown IP):
There have been multiple failed login attempts to your account. Please make sure your account has a strong password.
Let's set the default for LoginNotifyAttemptsNewIP to 1 in the extension.json as well since it solves the bundling issues.
Chart of EventLogging data to date (courtesy of Niharika):
Fri, Apr 21
@JGirault: Thanks for the great suggestions!
@jeblad: I tested this out locally to investigate the propagation issue. When a user is blocked from editing due to a block-cookie, it does not create a new block record for the new IP address. In other words, you can always work around a block-cookie by deleting the cookie, as the block does not propagate via cookie blocking. The only time a block propagates is when an autoblocked user tries to edit from a new IP address with a blocked user account. That behavior hasn't changed.
@Pastakhov: Thanks for the explanation. Now it all makes sense to me. I think 349260 + 346499 + 348673 seems like a sensible solution.
@Pastakhov, @Niharika: We still need to make some distinction in the color coding between tags that are parsed and tags that aren't parsed (i.e. valid and invalid tags). Tags that aren't parsed should just stay black (as they do now). Instead of registering each valid tag with CodeMirror from separate extensions, which will be a maintenance headache, I wonder if we could just output the list of valid tags to the client (since MediaWiki already knows this information). We could get the list of valid non-HTML tags from Parser::$mTagHooks and the list of allowed HTML tags from Santizer::getRecognizedTagData(), instead of having CodeMirror rely its own lists. (Community Tech can help implement these core changes if needed.)
Yeah, T11838 is probably the best place for us to put that info.
I like it. The extra context helps me know if the notification needs attention or not. For example, I can probably ignore "18.104.22.168 left a message on your talk page in 'Testing'.", but I wouldn't know that from the truncated version.
Thu, Apr 20