Page MenuHomePhabricator

Alsee
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Friday

  • Clear sailing ahead.

User Details

User Since
Feb 26 2015, 7:19 PM (280 w, 5 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Alsee [ Global Accounts ]

Recent Activity

May 15 2020

Alsee added a comment to T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles.

The current mainspace search count of about 2,250,000 matches up well with the category count when you include non-article mainspace pages, primarily disambiguation.

May 15 2020, 2:18 PM · Wikidata, MediaWiki-extensions-WikibaseClient

May 13 2020

Alsee added a comment to T246190: Reply v2.0: conduct usability tests (usertesting.com).

@Aklapper the word "you" was intended as a collective noun for the Foundation. If you maintain that raising concern with the Foundation's design and testing workflow is somehow "personal" I would be concerned with your definitions.

May 13 2020, 5:37 PM · Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools, OWC2020 (OWC2020 Replying 2.0)

May 10 2020

Alsee added a comment to T246190: Reply v2.0: conduct usability tests (usertesting.com).

@ppelberg when I edit an article and toggle back and forth between wikitext and visual editors, it does not corrupt the wikitext.

May 10 2020, 1:01 AM · Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools, OWC2020 (OWC2020 Replying 2.0)

Apr 22 2020

Alsee added a comment to T249293: Prevent DiscussionTools from being enabled on pages they should not be.

Content-specific whitelist

  • Reply links would only be appended to comments at a new level of indentation

I don't understand this one, but if it it's saying what I think it's saying then it does not sound correct. The indentation level of a comment shouldn't affect whether it has a reply link.

Apr 22 2020, 8:51 PM · Editing-team (Tracking), OWC2020, DiscussionTools

Apr 16 2020

Alsee updated the task description for T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles.
Apr 16 2020, 10:14 AM · Wikidata, MediaWiki-extensions-WikibaseClient

Mar 27 2020

Alsee added a comment to T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles.

I really hope this never happens

There was repeated consensus on this, and if you recall you participated in one. The Foundation handled things badly, but committed to terminating wikidata descriptions when we reached 2 million local descriptions. I expect the result would be Bad all around if the Foundation were to renege.

Mar 27 2020, 7:38 AM · Wikidata, MediaWiki-extensions-WikibaseClient

Mar 25 2020

Alsee removed a subtask for T187285: Magic word on English WP to replace Wikidata short descriptions: T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles.
Mar 25 2020, 11:14 AM · MediaWiki-extensions-WikibaseClient, Wikidata
Alsee removed a parent task for T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles: T187285: Magic word on English WP to replace Wikidata short descriptions.
Mar 25 2020, 11:14 AM · Wikidata, MediaWiki-extensions-WikibaseClient
Alsee added a subtask for T192838: Magic word on English WP: T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles.
Mar 25 2020, 11:14 AM · Product-Infrastructure-Team-Backlog, Wikimedia-General-or-Unknown, Epic
Alsee added a parent task for T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles: T192838: Magic word on English WP.
Mar 25 2020, 11:14 AM · Wikidata, MediaWiki-extensions-WikibaseClient
Alsee updated the task description for T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles.
Mar 25 2020, 11:05 AM · Wikidata, MediaWiki-extensions-WikibaseClient
Alsee updated the task description for T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles.
Mar 25 2020, 11:00 AM · Wikidata, MediaWiki-extensions-WikibaseClient
Alsee updated the task description for T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles.
Mar 25 2020, 10:59 AM · Wikidata, MediaWiki-extensions-WikibaseClient
Alsee added a subtask for T187285: Magic word on English WP to replace Wikidata short descriptions: T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles.
Mar 25 2020, 10:58 AM · MediaWiki-extensions-WikibaseClient, Wikidata
Alsee added a parent task for T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles: T187285: Magic word on English WP to replace Wikidata short descriptions.
Mar 25 2020, 10:58 AM · Wikidata, MediaWiki-extensions-WikibaseClient
Alsee created T248457: Fully terminate use of Wikidata item descriptions as short article descriptions for English Wikipedia articles.
Mar 25 2020, 10:58 AM · Wikidata, MediaWiki-extensions-WikibaseClient

Mar 15 2020

Alsee added a comment to T246960: Publish Technical RfC: new syntax for multi-line list items/talk page comments.

Why is the information not posted for public access? Maybe this is a silly suggestion, but doesn't the Foundation have a global scale wiki farm for public access content hosting?

Mar 15 2020, 9:56 AM · Editing-team (FY2020-21 Kanban Board), DiscussionTools

Mar 10 2020

Alsee added a comment to T245225: Implement editing specific comments.

@matmarex first note that I'm not actually taking any position here on how the product should work in this case. I'm talking about how we reason about the design. Discussion Tools is a parallel option for posting and editing comments. Any rationale for how Discussion Tools will work should be based on what makes sense for the product given that attempted constraints do not actually hold.

Mar 10 2020, 9:20 AM · Editing-team (Tracking), DiscussionTools
Alsee added a comment to T245890: Enable DiscussionTools on pages where `__NEWSECTIONLINK__` is present.

I don't know whether any projects use NEWSECTIONLINK on nontalk pages, although EnWiki gets a low but steady occurrence of them in article space due to VisualEditor and the potentially unclear purpose of it. I just removed NEWSECTIONLINK from 35 articles.

Mar 10 2020, 8:10 AM · Editing-team (FY2020-21 Kanban Board), Editing QA, MW-1.35-notes (1.35.0-wmf.27; 2020-04-07), OWC2020, DiscussionTools
Alsee added a comment to T128055: Obfuscate old IP addresses in database.

I think you need to run this by legal. This appears to violate the copyright attribution requirements. Logged-out users submitted their contribution under an attribution license, with a reasonable expectation that their IP would serve as their attribution identity.

Mar 10 2020, 5:32 AM · Privacy Engineering, MediaWiki-Page-History, WMF-Legal, MediaWiki-Page-Diffs, Privacy

Mar 8 2020

Alsee renamed T245890: Enable DiscussionTools on pages where `__NEWSECTIONLINK__` is present from Allow non talk pages to be treated as talk pages using a magic word to Allow non talk pages to be treated as talk pages using a magic word, and allow talk pages to be treated as non-talk pages using a magic word.
Mar 8 2020, 9:23 AM · Editing-team (FY2020-21 Kanban Board), Editing QA, MW-1.35-notes (1.35.0-wmf.27; 2020-04-07), OWC2020, DiscussionTools
Alsee added a comment to T245890: Enable DiscussionTools on pages where `__NEWSECTIONLINK__` is present.

There should be two magic words. One to enable Discussion Tool, and one to disable Discussion Tool. The magic words would each override the namespace.

Mar 8 2020, 9:21 AM · Editing-team (FY2020-21 Kanban Board), Editing QA, MW-1.35-notes (1.35.0-wmf.27; 2020-04-07), OWC2020, DiscussionTools

Mar 7 2020

Alsee closed T243044: Heading formats are not rendering when added as part of a comment using new reply workflow as Invalid.

I can't test the behavior due to the parsoid 404, so I'll reclose this for now. But there were definitely problems when I tested it some time ago.

Mar 7 2020, 4:21 AM · DiscussionTools, OWC2020
Alsee reopened T243044: Heading formats are not rendering when added as part of a comment using new reply workflow as "Open".
Mar 7 2020, 3:56 AM · DiscussionTools, OWC2020
Alsee added a comment to T243044: Heading formats are not rendering when added as part of a comment using new reply workflow.

The heading isn't intended to be part of the list.

Mar 7 2020, 3:56 AM · DiscussionTools, OWC2020
Alsee added a comment to T245225: Implement editing specific comments.

@matmarex I think you should reconsider how you're conceptualizing the product. We're not building a discussion system, we're building a convenience-tool for wikipages. Consider your points here:

  • We must ensure there is a signature (because reason)
  • Maybe investigate if we actually can prevent the user from removing the signature(s)
Mar 7 2020, 3:41 AM · Editing-team (Tracking), DiscussionTools

Feb 29 2020

Alsee added a comment to T240360: Determine our approach for displaying date and time a comment was made, in a user's local timezone and preferred date format.

@Demian I don't understand your objection about being "less dramatic". What I said was mild, accurate, and factual. For what it's worth I'll try to clarify. When I set a Mediawiki timezone preference I found it was absolutely disruptive to my ability to work. I had to turn it off as soon as I encountered the problem. We copy-paste or type timestamps on a semi-regular basis, and it's a problem when they don't match the entries in history or other logs. Anyone who sets a timezone is going to have to manually convert any timestamp posted by anyone else before they can compare it it in history or logs, and they need to preform a manual conversion before they posting any timestamp. If they don't, other editors will complain about them posting invalid timestamps.

Feb 29 2020, 3:27 PM · DiscussionTools, Editing-team (Tracking), Editing Design, OWC2020

Feb 27 2020

Alsee added a comment to T240360: Determine our approach for displaying date and time a comment was made, in a user's local timezone and preferred date format.

Could someone investigate what percentage of active editors have a custom value set for MediaWiki timezone preference? I could be mistaken, but I expect it would be very low. I found it painfully disruptive when I tried using it.

Feb 27 2020, 9:16 AM · DiscussionTools, Editing-team (Tracking), Editing Design, OWC2020
Alsee added a comment to T246245: Reply v2.0: Create annotated tickets for posting on-wiki.

@iamjessklein not a big deal, but I noticed the link in your example is broken. An http-type link is an external link. External links use single-brackets and a space instead of a pipe. Like this: [https://en.wikipedia.org/wiki/Template:Cite_sign Template:Cite_sign]

Feb 27 2020, 8:57 AM · Editing-team (Q3 2019-2020 Kanban Board), OWC2020 (OWC2020 Replying 2.0), Editing Design

Feb 20 2020

Alsee added a comment to T242260: Background color captures more than content area.

Expecting a balanced page, with a closing div or heredoc close is incompatible with what is probably the primary use case. If someone uses the new-section button, or casually adds a new content or a new section at the bottom, the closing div will no longer be at the bottom. Not only will that mess up the rendering of the page, but the closing-div may get automatically archived. Archiving would again result in a page with an unclosed div.

Feb 20 2020, 1:08 PM · MediaWiki-Parser
Alsee added a comment to T245220: Comment parser should report range of comment and signature separately.

This seems like a poor idea. If you cut the editable range short, they can't append after the signature. We don't usually do that for quick spelling/grammar/link fixes, but major or late changes will often get an appended second signature and possibly a note of what major change was made. Also any attempt to identify the start of the signature will be a guess, and guesses which are wrong will produce very odd behavior for the affected users.

Feb 20 2020, 12:12 PM · Editing-team (Q3 2019-2020 Kanban Board), MW-1.35-notes (1.35.0-wmf.23; 2020-03-10), OWC2020 (OWC2020 Replying 2.0), DiscussionTools

Feb 13 2020

Alsee added a comment to T235593: Replies v2.0: create mockups.

@iamjessklein someone who clicks the standard EDIT button should never enter any flowchart for the DiscussionTool.

Feb 13 2020, 8:45 PM · Editing-team (Q3 2019-2020 Kanban Board), OWC2020 (OWC2020 Replying 2.0), Editing Design
Alsee added a comment to T242184: Create a change tag for edits made using DiscussionTools.

The tags would likely be shorter if we had a name for the tool (and for the project). The lack of such a name is becoming increasingly inconvenient.

Feb 13 2020, 12:11 AM · MW-1.35-notes (1.35.0-wmf.21; 2020-02-25), Verified, OWC2020 (OWC2020 Replying 1.0), OWC2020 Replying 1.0, Editing-team (Q3 2019-2020 Kanban Board), Editing Design, DiscussionTools

Feb 5 2020

Alsee added a comment to T241391: Unable to respond to specific comments.

@matmarex what's the rationale for the current approach? I can see several reasons for start and end indent to differ, but I can't think of any case where a differing end indent would be giving the correct signal.

Feb 5 2020, 5:50 AM · Verified, Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools, OWC2020
Alsee added a comment to T239676: Mobile VE: Fall back to wikitext editor if the loading takes too long.

The task description says VE had a lower success rate than WTE, because it took longer to load, causing users to abandon their edit before even starting. While that is surely true in some cases, I expect it is a minority. Possibly a rather small minority. The overwhelming majority of edit-clicks are people with no intention of editing. They are either misclicks or curiosity clicks. The fact that VE is slow to load merely gives those users a chance to cancel the page load.

Feb 5 2020, 4:31 AM · VisualEditor, Editing-team, Editing Design, Patch-For-Review, VisualEditor-MediaWiki

Jan 30 2020

Alsee updated the task description for T243973: WikimediaSpace blocking editors without confirmed email address.
Jan 30 2020, 9:14 PM · Discourse
Alsee updated the task description for T243973: WikimediaSpace blocking editors without confirmed email address.
Jan 30 2020, 8:58 PM · Discourse
Alsee created T243973: WikimediaSpace blocking editors without confirmed email address.
Jan 30 2020, 8:57 PM · Discourse

Jan 27 2020

Alsee added a comment to T241391: Unable to respond to specific comments.

it will no longer be necessary to insert block content without indentation if multiline comments/list items are implemented.

Jan 27 2020, 10:43 PM · Verified, Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools, OWC2020

Jan 26 2020

Alsee added a comment to T241391: Unable to respond to specific comments.

@matmarex it looks like the code for where to place the reply is running into trouble because it's trying to follow HTML/parser structure instead of the comment structure. People don't view the structure the way a formal parser does. You need to step away from the usual parsing expectations and focus on what humans are keyed-into.

Jan 26 2020, 11:25 PM · Verified, Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools, OWC2020
Alsee added a comment to T240640: [Feedback] Not supporting adding multiple signatures in a comment.

When the page already contains a comment with multiple signatures (within a single paragraph or list item), there will be only one "Reply" button added, at the end of the line.

Agreed. Paragraphs should be treated as indivisible in every case I can think of, and if I really do want to split a paragraph I would expect to use the full edit button.

Jan 26 2020, 10:05 PM · User-Ryasmeen, Verified, OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools

Jan 24 2020

Alsee added a comment to T240640: [Feedback] Not supporting adding multiple signatures in a comment.

I agree with matmarex, a line/paragraph should be treated as an indivisible block.

Jan 24 2020, 6:19 PM · User-Ryasmeen, Verified, OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools
Alsee added a comment to T242223: Write an algorithm that can detect a resolution suggestion.

The current practice of preforming merges silently is a problem, and I would say this particular talk-case case increases the priority on T76997 Edit conflict automatic resolution can silently produce unexpected results. If I edit-conflict at same spot in a discussion I want to either approve the proposed merge, or at minimum be shown the other person's content after the auto-merge. It's possible for this sort of merge to badly distort the apparent context and meaning of a comment.

Jan 24 2020, 4:42 PM · MW-1.35-notes (1.35.0-wmf.25; 2020-03-24), WMDE-QWERTY-Sprint-2020-03-18, WMDE-QWERTY-Sprint-2020-03-04, WMDE-QWERTY-Sprint-2020-01-21, WMDE-QWERTY-Sprint-2020-01-08, Two-Column-Edit-Conflict-Merge, archived--TCB-Team

Jan 22 2020

Alsee added a project to T243435: TwoColumnConflict preview passes incorrect namespace to templates: Two-Column-Edit-Conflict-Merge.
Jan 22 2020, 6:07 PM · MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-02-04, WMDE-QWERTY-Sprint-2020-01-21, WMDE-Technical-Wishes-Team, archived--TCB-Team, Two-Column-Edit-Conflict-Merge
Alsee created T243435: TwoColumnConflict preview passes incorrect namespace to templates.
Jan 22 2020, 6:06 PM · MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-02-04, WMDE-QWERTY-Sprint-2020-01-21, WMDE-Technical-Wishes-Team, archived--TCB-Team, Two-Column-Edit-Conflict-Merge

Jan 9 2020

Alsee added a comment to T217825: Editing timing data incorrect for second load.

@Esanders it looks like this task is specific to mobile-VE. Did or does the same issue exist in desktop VE? And if so has it been fixed there too?

Jan 9 2020, 5:30 AM · Skipped QA, MW-1.34-notes (1.34.0-wmf.3; 2019-04-30), VisualEditor (Current work), VisualEditor-MediaWiki-Mobile
Alsee added a comment to T240548: References with no visible content are reported as empty now.

I don't think I have ever before seen the software dump a message like this into an article, outside of preview or the reflist-block. It is seriously horrid behavior. Remember, almost everyone looking at the page is a reader, and our primary job is to present the page for that reader.

Jan 9 2020, 3:48 AM · WMDE-Technical-Wishes-Team, Regression, Cite, Book-Referencing
Alsee added a comment to T240360: Determine our approach for displaying date and time a comment was made, in a user's local timezone and preferred date format.
  1. Localized times will confuse and disrupt communication. We routinely use the timestamp when referring to a comment or edit. If you localize times the time value becomes randomized garbage for everyone trying to read it.
  2. Displaying localized time would require deeply screwing around with how wikipages work.
Jan 9 2020, 3:21 AM · DiscussionTools, Editing-team (Tracking), Editing Design, OWC2020
Alsee updated subscribers of T235923: Replies v1.0: release replying to specific comments.

Updating the task description to include the ideas @MMiller_WMF + @Whatamidoing-WMF raised during today's staff meeting:

  • How might the replying text input more clearly communicate to experienced contributors how the workflow behaves (e.g. How and when does the reply workflow prepend indentation syntax to "your" comment?)
    • This relates to to a point @Alsee raised in T235923#5680589 in response to: "What – if anything – should be pre-populated in the reply box?"
Jan 9 2020, 2:34 AM · OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools

Jan 1 2020

Alsee added a comment to T2738: Ability to watch section levels of pages.

This was one of the top results of the Talk Page Consultation. I think(?) the team put section watchlisting on the to-do list.

Jan 1 2020, 7:03 AM · Growth-Team, Community-Wishlist-Survey-2016, Community-Wishlist-Survey-2015, German-Community-Wishlist, archived--TCB-Team, Epic, MediaWiki-Watchlist

Dec 30 2019

Alsee added a comment to T241388: When inserting {{welcome}} reply, preview is indented differently to saved content.

@ppelberg Eeeek! This Phab task is backwards.

Dec 30 2019, 3:42 AM · Editing-team (Tracking), DiscussionTools

Dec 20 2019

Alsee added a comment to T240548: References with no visible content are reported as empty now.

Yikes! What happened to this article is horrid. Don't throw error messages in the middle of an article.
Even worse, for German readers the article is spammed with foreign language garbage text.

Dec 20 2019, 2:32 PM · WMDE-Technical-Wishes-Team, Regression, Cite, Book-Referencing

Dec 15 2019

Alsee added a comment to T240640: [Feedback] Not supporting adding multiple signatures in a comment.

There are various use cases for multiple signatures, as well as for disabling the final auto-signature. One example:

Dec 15 2019, 4:39 AM · User-Ryasmeen, Verified, OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools

Dec 10 2019

Alsee added a comment to T119595: Provide a reply to Letter to Wikimedia Foundation: Superprotect and Media Viewer.

@Aklapper if I noticed that the Foundation had left its servers set with the default password, or even worse put gasoline in the fire extinguishers, it is constructive contribution to alert the Foundation of that failure and the very real and very grave consequences of failing to constructively address the issue. Even if my reports are not warmly received and even if they are not immediately successful.

Dec 10 2019, 1:09 AM · Technical-Collaboration-Guidance, Community-Relations-Support (Oct-Dec-2016), Liaisons-March-2016, Liaisons-February-2016, DevRel-January-2016, DevRel-December-2015

Dec 8 2019

Alsee added a comment to T119595: Provide a reply to Letter to Wikimedia Foundation: Superprotect and Media Viewer.

To the extent that [[Wikimedia Product Guidance]] constitutes a "reply", it is a profanity-laced one.

Dec 8 2019, 5:06 AM · Technical-Collaboration-Guidance, Community-Relations-Support (Oct-Dec-2016), Liaisons-March-2016, Liaisons-February-2016, DevRel-January-2016, DevRel-December-2015

Nov 27 2019

Alsee added a comment to T238971: Consider revising Junior Contributor definition.

@ppelberg please reopen this task. All we've resolved is that there is no concern about bad faith. We haven't resolved that the issue of non-contributors are being included in the Contributors metric. It's a very low bar to expect ONE edit demonstrating someone is here to work on the project. Heck, if we set the threshhold at a single reverted edit it would at least demonstrate an attempt to contribute.

Nov 27 2019, 12:32 PM · Product-Analytics, VisualEditor (Current work), OWC2020

Nov 26 2019

Alsee added a comment to T239231: Calculate guardrail metrics.

I don't have any objection per-se to watching the suggested guardrail metrics, however I don't think they will be particularly useful.

Nov 26 2019, 1:58 PM · DiscussionTools, Product-Analytics, OWC2020
Alsee added a comment to T238971: Consider revising Junior Contributor definition.

Neil is correct. Defining contributor to mean 'article space contribution' has nothing to do with bad faith. Vandals generally don't bother with talk pages. The primary source of disruption is good-faith people arguing. Non-editors are more likely to create, expand, and persist in disruptive arguing.

Nov 26 2019, 1:32 PM · Product-Analytics, VisualEditor (Current work), OWC2020

Nov 25 2019

Alsee added a comment to T223339: Re-run metrics from VE on mobile report .

There are a number of reasons why an edit init might not reach edit ready. However I cannot think of ANY scenario where it would be appropriate to penalize the quick-loading wikitext editor with an edit fail while discarding the data for a VE edit fail. Calculating edit completion rate using ready misleadingly inflates the success percentages for VE.

Nov 25 2019, 6:58 PM · Product-Analytics, VisualEditor

Nov 23 2019

Alsee added a comment to T142299: First edit guided tour should use VE tab as anchor when available.

I suggest closing this task. The community will likely react negatively if you try to point guided tour to the secondary editor.

Nov 23 2019, 4:55 PM · Growth-Team, MediaWiki-extensions-GuidedTour
Alsee awarded T142299: First edit guided tour should use VE tab as anchor when available a Burninate token.
Nov 23 2019, 4:47 PM · Growth-Team, MediaWiki-extensions-GuidedTour

Nov 22 2019

Alsee added a comment to T235761: Decide what to show when user is viewing an old version of a talk page.

I'd suggest converting reply-links into non-links, and add strikethrough to indicate they are inactive. (Even better, check the history date and don't show reply-links at all if it's before reply-links were deployed.)

Nov 22 2019, 9:12 AM · User-Ryasmeen, MW-1.35-notes (1.35.0-wmf.21; 2020-02-25), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools, OWC2020

Nov 21 2019

Alsee added a comment to T235923: Replies v1.0: release replying to specific comments.

I think many of these questions answer themselves when you keep in mind that we're not building a new discussion system, we just want to help the the user more quickly and more easily insert the exact same blob of wikitext they currently do.

Nov 21 2019, 3:08 AM · OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), DiscussionTools

Nov 17 2019

Alsee added a comment to T234046: Create OWC metric definitions.

I edited the wikipage item for "Junior Contributors" to add a criteria of "at least one article page edit". You may want to revise this to "at least one article page edit that has not been reverted".

Nov 17 2019, 8:23 PM · Product-Analytics, VisualEditor (Current work), OWC2020

Nov 8 2019

Alsee added a comment to T235592: Replies v1.0: Create mockups.

Depending on the design, the interface might make this information directly visible....

We've been thinking of making this visible by "indenting" the reply textbox on the page

I still like showing the indent string and sig string for several reasons:
(1) Indenting the box would consume X characters of whitespace at the beginning of every line, whereas showing the indent-characters only consumes X characters on the first line of the reply box. This is particularly significant for mobile. (2) Experienced users will be instantly comfortable seeing exactly how the new interface works. (2) The new interface becomes an actively helpful on-ramp. New users will passively absorb how the underlying page works, especially if the shown characters have a tip appear on mouseover. If the new user sticks around they will sometimes need to use the edit button to directly edit the page for various reasons. (3) Making indent characters visible and click-to-edit allows people to replace the indents with an {{od}} outdent or otherwise alter the indentation for various reasons, without having having to leave the new interface. The community likes the power, flexibility, and control they have on talk pages. We should't hardcode-lock the indentation string if we don't have to.

Having the signature characters moving with your cursor as your type sounds annoying.

Agreed. Instead I picture it attached to the bottom-right corner of the text entry box.
While I expect it would be rare to want to delete or change the sig portion, if the indent-characters are click-to-edit then this part should work the same.

[posting in places that aren't a reply]

Ideally we'd add some cue that you can reply to those places, and ideally it would also describe the expected way to indent (imagine a template like {{replywith|#}} that generates some invisible marker), and then the user won't have to know what to do beforehand. I don't think we've thought this through yet (I certainly haven't).

I'm picturing a reply link after each signature, plus a link at the bottom of every section. I think the section-link should say something like "Add comment" or "Add new comment" instead of "Reply". It would add a zero-indent post. The user can supply the * or # if appropriate. Note: For the zero indent case the software will need to prepend a blank line unless one of the following is true: (1) There's already a blank line or section heading directly above (2) the user starts their reply with one of :*# (3) any other known-safe case I missed.

Nov 8 2019, 10:51 AM · OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), OWC2020 Replying 1.0, Editing Design

Nov 5 2019

Alsee added a comment to T232780: Write a client-side parser for signatures (username & timestamp), comments and threads.

The community already has guidelines for custom signatures. (Or at least Enwiki does, and I expect any non-minimal wiki will too.) I believe our current rules already require at least one link to user/user_talk/user-contributions, and if we don't already have a rule about not screwing up the timestamp then that rule would certainly be added as soon as anything breaks.

Nov 5 2019, 10:29 PM · OWC2020, VisualEditor (Current work)
Alsee added a comment to T235592: Replies v1.0: Create mockups.

Another common case is that we use a single-bullet-indent comment for many of our workflows. (RFCs, AFDs, RFAs.) ...I think this pretty much confirms the answer to the last question - the user needs to be able to add or modify the indent-markup.

Are you able to share a link to a conversation where we can observe this convention?

Nov 5 2019, 10:05 PM · OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), OWC2020 Replying 1.0, Editing Design

Nov 1 2019

Alsee added a comment to T228862: One feed to pull all the announcements published by the Foundation.

Could we designate a page on EnWiki to receive these announcements? I suspect we'd want to fully protect the page, so it's reserved solely for this announcement stream.

Nov 1 2019, 6:31 AM · WMF-Communications

Oct 27 2019

Alsee added a comment to T234403: Create a VE-based text input for replying.

VE is not viable as a primary/default. Multiple communities have created hacks to the sitewide javascript to kill VE-defaults, the Talk Page Consultation finally killed Flow fundamentally due to it being entirely built around VE and attempted to force VE as the sole interface for Talk, and EnWiki (nearly half our global community) put a block on the 2017wikitext editor again fundamentally because it was built entirely around VE and it attempted to force VE as the sole interface for non-talk. Using VE for plaintext and/or wikitext is grossly dysfunctional design.

Oct 27 2019, 12:26 AM · User-Ryasmeen, DiscussionTools, MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), Patch-For-Review, Editing-team (Q3 2019-2020 Kanban Board), OWC2020 (OWC2020 Replying 2.0)

Oct 26 2019

Alsee added a comment to T235592: Replies v1.0: Create mockups.

@iamjessklein

I have two versions of the editor itself. One of these versions is VE first but will handle wikitext if written

Building Flow around VE was the core cause of failure. The community is adamant that wikitext is primary. It will not be possible to deploy the product unless the initial/default input box properly handles and previews wikitext. (Note: Running it through the VE's parser is not proper wikitext support.)

Oct 26 2019, 11:52 PM · OWC2020 (OWC2020 Replying 1.0), Editing-team (Q3 2019-2020 Kanban Board), OWC2020 Replying 1.0, Editing Design

Oct 10 2019

Alsee added a comment to T223793: On non-SET wikis (two edit tabs), links to new pages (red links) should open the user's preferred editor (last used).

@Theklan I don't want a long debate of VE-vs-Wikitext here, but in short the data and the general community both strongly disagree. File:2018-10_Wikimedia_editing_interface_retention.png data shows desktop& mobile interface-retention rates for VE are about half of the interface-retention rates for the wikitext editor. Foundation Research:VisualEditor's_effect_on_newly_registered_editors shows that VE utterly fails to provide the intended benefits for new users, and results in massively slower editing and lower rates of new users successfully making an edit. Global edit counts show the wikitext editor is overwhelmingly the primary editor, chosen as the best tool for the job by almost everyone. On wikis where VE is the default, new users rapidly abandon it and quickly shift to wikitext for a majority of edits. The Foundation attempted to roll out a VE-default for new users with SET deployment - two wikis (one being EnWiki) wrote hacks for the sitewide javascript to change the default and a third wiki unanimously demanded it be reversed. This effectively halted any further deployment of SET. It was clear that the community was not going to tolerate a Visual default, and management behind SET apparently lost interest in further SET deployment if it wasn't going to include a VE-default.

Oct 10 2019, 8:31 PM · VisualEditor, Editing-team (Q3 2019-2020 Kanban Board), MW-1.34-notes (1.34.0-wmf.8; 2019-06-04), User-notice, VisualEditor-MediaWiki

Oct 3 2019

Alsee added a comment to T230653: Use a parser function to encapsulate signatures.

For raw disruption, I believe someone could put image(s) in their signature. Aside from the obvious image-content issues, the image(s) may be up to 100 megabytes each and/or animated gifs.

Oct 3 2019, 6:52 PM · DiscussionTools, Patch-For-Review, OWC2020, MediaWiki-Parser

Sep 29 2019

Alsee added a comment to T230653: Use a parser function to encapsulate signatures.

oft-requested user feature: automatically updating signatures on old talk pages.

While there may have been requests for this, I think it unlikely that the community would actually want this. Changing signatures with no entry in the page history would be strange, confusing, and open to abuse.

  1. Make an apparently innocent edit.
  2. At any time, change signature preference. Purge the page to apply the change. These actions are unlogged and invisible to the community.
  3. The page may now be in a deceptive or malicious state.
  4. At any time, change signature preference. Purge the page to apply the change. These actions are unlogged and invisible to the community.
  5. The page is back in an apparently innocent state. There does not exist any log or other evidence that the user committed the abuse.

The most obvious issue would be to impersonate someone else, however it's more serious than may first be apparent. This exploit enables a clever user to inject arbitrary wikitext&content at several points in the page, with surprisingly powerful possibilities.

Sep 29 2019, 5:16 AM · DiscussionTools, Patch-For-Review, OWC2020, MediaWiki-Parser
Alsee updated the task description for T232780: Write a client-side parser for signatures (username & timestamp), comments and threads.
Sep 29 2019, 1:42 AM · OWC2020, VisualEditor (Current work)
Alsee added a comment to T232780: Write a client-side parser for signatures (username & timestamp), comments and threads.

According to Manual:Echo:

The signature must contain a plain wiki link ([[ ]]) to the user's page, user talk page, or contributions page, on the local wiki

I will update the task description here to match, adding 'contributions page' to the list.

Sep 29 2019, 1:41 AM · OWC2020, VisualEditor (Current work)

Aug 31 2019

Alsee added a comment to T76997: Edit conflict automatic resolution can silently produce unexpected results.

Another example was posted in T223433 and it's worth noting here. I'll detail the three edits involved:

Aug 31 2019, 9:31 PM · Patch-For-Review, MediaWiki-Page-editing

Aug 22 2019

Alsee added a comment to T230659: Automatically-assigned id attributes for list items.

If I understand this correctly, it appears to be a non-starter. One of the clear outcomes of the Talk Page Consultation was not to disrupt normal editing of talk pages, and that any new tools be optional. It appears either impossible or unreasonable for experienced editors to type these IDs, and surely you don't expect a new users to look at the wikipage and figure out how to comment like this.

Aug 22 2019, 2:48 PM · DiscussionTools, OWC2020, MediaWiki-Parser

Aug 8 2019

Alsee added a comment to T230010: Wiki text: <s> in front of : makes rest of the text on the page strike-through.

@Aklapper, this example involved the small tag instead of strikethough, so it was perhaps less obvious on a "quick look".

Aug 8 2019, 2:08 PM · MediaWiki-Parser
Alsee added a comment to T230010: Wiki text: <s> in front of : makes rest of the text on the page strike-through.

@Aklapper you can see in another revision from Admin noticeboard the bottom of the page is mangled even when the opening tag is placed after the colons.

Aug 8 2019, 11:40 AM · MediaWiki-Parser
Alsee added a comment to T230010: Wiki text: <s> in front of : makes rest of the text on the page strike-through.

@Aklapper I apologize if my bug-description was not sufficiently clear.

Aug 8 2019, 10:29 AM · MediaWiki-Parser

Aug 7 2019

Alsee updated the task description for T230010: Wiki text: <s> in front of : makes rest of the text on the page strike-through.
Aug 7 2019, 11:08 AM · MediaWiki-Parser
Alsee created T230010: Wiki text: <s> in front of : makes rest of the text on the page strike-through.
Aug 7 2019, 11:02 AM · MediaWiki-Parser

Aug 5 2019

Alsee added a comment to T227733: Draft: Masking IP addresses for increased privacy.

First a nitpick, problem behavior is a far larger category than "vandalism". For example if someone is a partisan political warrior and they persistently put inappropriate negative content into the biographies of politicians of a particular political party, they are not a vandal. However they do need to be blocked.

Aug 5 2019, 2:03 PM · Core Platform Team Workboards (Initiatives), Privacy Engineering, Privacy, MediaWiki-User-management, Anti-Harassment

Jul 30 2019

Alsee added a comment to T159678: [Bug] Special:Nearby isn't showing thumbnails on Wikidata.

The default behavior of PageImages is Free-only for good reason. The Board of Trustee's Resolution:Licensing_policy says that unauthorized use of copyrighted content (non-free content) must be "minimal" and subject to EDP (Exception Doctrine Policy), and that this may not be circumvented, eroded, or ignored by Wikimedia Foundation officers or staff nor local policies of any Wikimedia project.

Jul 30 2019, 11:30 PM · User-aude, Wikimedia-Site-requests, MediaWiki-extensions-WikibaseRepository, PageImages, Wikidata

Jul 6 2019

Alsee added a comment to T141901: MultimediaViewer processes all thumbnails on the page even when it's supposedly disabled.

I do not like that MV preprocesses all images on load (I think it's unnecessary, whether it's enabled or not) but that seems like a significant effort to change and I'm not sure it's worth it unless it is causing serious problems.

Jul 6 2019, 8:25 PM · MediaWiki-User-preferences, Multimedia, MediaViewer

Jul 1 2019

Alsee added a comment to T224797: Activate Structured Discussions/Flow as a Beta feature on ckbwiki.

I can't find the task number at the moment, but I believe a different request to activate Flow was recently declined due to the early stage outcome of the Talk_Page_Consultation, and the decision to shift direction to enhancements for existing talk pages instead of Flow. Assuming new deployments have indeed been suspended, I think an appropriate update should be made at MediaWiki:Request_Structured_Discussions_on_a_page.

Jul 1 2019, 10:35 PM · Wikimedia-Site-requests, Growth-Team, StructuredDiscussions

May 19 2019

Alsee added a comment to T10681: Group changes across days in enhanced rc.

(Edit: I'm not sure whether this task covers the watchlist. I'm referring mainly to watchlist below)

May 19 2019, 3:51 AM · Growth-Team, MediaWiki-Watchlist, MediaWiki-Recent-changes

May 7 2019

Alsee updated subscribers of T218820: Ensure CTRL-V paste works as expected in text editing mode.

@JTannerWMF or anyone, if you are interested in Discussion/Analysis input from the community then I'd be happy to help. I'm confident what the result will be, but I can easily organize feedback from EnWiki and, if needed, other English wikis.

May 7 2019, 3:36 PM · VisualEditor-CopyPaste, VisualEditor-MediaWiki-2017WikitextEditor, VisualEditor

Apr 27 2019

Alsee added a comment to T210281: Find a better way to highligth letters then bold.

Oh yeah, I forgot reflow. Most cases would be negligible, but hitting an uncommon big reflow might be unpleasant. I think it would probably be better to just apply the darkened background to the relevant backlink, without changing the size of anything. Is there anything holding back a styling change?

Apr 27 2019, 7:35 PM · WMDE-Design, Cite, archived--TCB-Team, Design

Apr 18 2019

Alsee added a comment to T210281: Find a better way to highligth letters then bold.

Don't add any extra padding on the letters, except perhaps on the single letter being highlighted.

Apr 18 2019, 12:40 AM · WMDE-Design, Cite, archived--TCB-Team, Design

Apr 9 2019

Alsee added a comment to T119365: Enable Flow for testing on Hungarian Wikipedia.

@Aklapper Thanks for confirming what I said. If the HuWiki discussion is revived it may be helpful. Extra thanks for reminding me about the link to configuration changes. That link should definitely be included if there are ever any more discussions activate Flow anywhere. Some people might find it hard to believe the Foundation would be so unwilling or unable to roll back deployment of the software if a trial-deployment ends badly.

Apr 9 2019, 7:38 AM · Growth-Team, User-Tgr, MW-1.27-release (WMF-deploy-2016-03-08_(1.27.0-wmf.16)), Patch-For-Review, Wikimedia-Site-requests, Collaboration-Team-Triage, StructuredDiscussions

Apr 8 2019

Alsee added a comment to T119365: Enable Flow for testing on Hungarian Wikipedia.

@Tgr your goal is good, however during the Uninstall-Flow-from-Commons incident (T186463), the Foundation determined that creating even a single Flow topic on a wiki leaves the wiki in a state where Flow can no longer be easily or safely uninstalled. The Flow extension is dangerously defective or incomplete, lacking procedures to safely clean up the logs or other content left behind if even one post is created (T188806). Due to this issue the software has been uninstalled from all wikis do not have any existing Flow content (T188812).

Apr 8 2019, 1:59 AM · Growth-Team, User-Tgr, MW-1.27-release (WMF-deploy-2016-03-08_(1.27.0-wmf.16)), Patch-For-Review, Wikimedia-Site-requests, Collaboration-Team-Triage, StructuredDiscussions

Mar 20 2019

Alsee created T218821: Ensure CTRL-V paste works as expected in text editing mode.
Mar 20 2019, 8:31 PM

Feb 27 2019

Alsee added a comment to T216837: Edit conflict preview not working on big pages.

I believe I just ran into this problem as well. I'd just like to note surprise at 2000 bytes being described as a big. At EnWiki that would be considered an extremely short page.

Feb 27 2019, 7:09 PM · MW-1.34-notes (1.34.0-wmf.3; 2019-04-30), Patch-For-Review, WMDE-QWERTY-Sprint-2019-04-17, archived--TCB-Team, Two-Column-Edit-Conflict-Merge

Nov 21 2018

Alsee added a comment to T194945: Infobox overlaps with text, prevents editing the latter..

(just imagine that instead of <nowiki />, the template had foo there: it would become a part of the first paragraph of the page).

Excellent example, I was going to raise that case myself. It's a pretty simple and obvious thing we might do at any time. We expect (and need) to be able to edit the plaintext after the template. Any editor that can't edit plaintext is clearly broken, regardless of explanations for why it is broken.

Nov 21 2018, 10:08 AM · Parsoid, VisualEditor

Oct 25 2018

Alsee added a comment to T193665: Don't show the loading bar on the 2017 Wikitext editor for the first 750ms.

Previous tests I ran on VE timings with online website test sites, over a year ago, were under reporting by upwards of 20 or 30 seconds. Improvements may have improved the times, but it's not merely an issue of not counting some fixed initial page load time. The time being reported was close to half of actual time.

Oct 25 2018, 1:48 PM · VisualEditor, Patch-For-Review, VisualEditor-MediaWiki-2017WikitextEditor
Alsee added a comment to T91683: Allow editors control of the page image.

Randomization wouldn't be much of an improvement. At minimum it still hurts us when some people think we aligned with one candidate and other people think we aligned with another candidate. I'll also note that the infobox may contain five or more candidates, some of whom are extremely fringe candidate with no chance of winning. We could literally select a Nazi.

Oct 25 2018, 12:43 PM · Readers-Web-Backlog (Needs Product Owner Decisions), Readers-Community-Engagement, PageImages
Alsee added a comment to T91683: Allow editors control of the page image.

Serious problem case: Articles on upcoming elections may contain an image of each candidate. Page image grabs one political-candidate photo and uses it as the image for the election itself. Yikes!

Oct 25 2018, 12:41 AM · Readers-Web-Backlog (Needs Product Owner Decisions), Readers-Community-Engagement, PageImages
Alsee added a comment to T193665: Don't show the loading bar on the 2017 Wikitext editor for the first 750ms.

@Deskana I promise that I did not deliberately omit information. I recall being concerned that my post was already too long, and my main focus was whether the graph was accurate.

Oct 25 2018, 12:05 AM · VisualEditor, Patch-For-Review, VisualEditor-MediaWiki-2017WikitextEditor

Oct 18 2018

Alsee added a comment to T169441: Spike: Page Curation should create a new AfD discussion page if one already exists [8 hours].

Note: For assorted reasons, there occasionally gaps in the (Nth nomination) sequence. If you look at Gay Nigger Association of America (22nd nomination), no pages exist at 3rd 4th 10th 11th 19th 20th or 21st. I'm not sure if Twinkle would create a new nomination at the first open slot (3rd), or if it's smart enough to create the new page at 23rd. Creating the new page at 23rd would definitely be preferable. It's probably worth checking the Twinkle code to see if it contains a solution for this, as well as checking whether it reveals any other corner cases or implementation details we've overlooked.

Oct 18 2018, 2:46 AM · Community-Tech (Kanban (Q1 2019-20)), Growth-Team, PageCuration, Collaboration-Team-Triage