Page MenuHomePhabricator

Jytdog (Jytdog)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Monday

  • Clear sailing ahead.

User Details

User Since
Jan 28 2017, 7:11 PM (259 w, 6 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Jytdog [ Global Accounts ]

Recent Activity

Jul 21 2017

Jytdog added a comment to T169982: OOjs UI fields with dynamic labels get the user cursor out of position when content it too long (e.g. edit summary field).

Very grateful that this was disabled at least for now. It is a relief to be able to write edit notes without fighting the software. We take simple things that work for granted, and I would be remiss if I didn't say thanks for making the software functional, simply, again.

Jul 21 2017, 9:47 PM · MW-1.30-release-notes, Editing-team, MediaWiki-Page-editing, OOUI

Jul 20 2017

Jytdog added a comment to T169982: OOjs UI fields with dynamic labels get the user cursor out of position when content it too long (e.g. edit summary field).

Again would you please just remove the counter. You can fix it offline. Thanks.

Jul 20 2017, 1:50 PM · MW-1.30-release-notes, Editing-team, MediaWiki-Page-editing, OOUI
Jytdog added a comment to T36984: Edit summaries length should have a countdown for remaining characters.

Yes I posted here since this appears to be where this was agreed to. Aklapper the problems with this counter are obvious and explained at depth at the phab thread just linked and at VPT.

Jul 20 2017, 1:47 PM · MediaWiki-Comment-store, MediaWiki-Page-editing
Jytdog added a comment to T36984: Edit summaries length should have a countdown for remaining characters.

Please roll this back. It breaks a basic function. I was unaware this was being considered and this is a perhaps-nice-to-have-gadget but not necessary. If re-implemented it should be an opt-in and not default. In my view this counter is clutter: I would never turn it on.

Jul 20 2017, 11:53 AM · MediaWiki-Comment-store, MediaWiki-Page-editing
Jytdog added a comment to T169982: OOjs UI fields with dynamic labels get the user cursor out of position when content it too long (e.g. edit summary field).

Am using chrome Version 59.0.3071.115 (Official Build) (64-bit) on a Mac. In addition to what is described above, when the content does starts disappearing behind the counter , if I try to delete and start typing again, the text is oddly repeated.

Jul 20 2017, 10:37 AM · MW-1.30-release-notes, Editing-team, MediaWiki-Page-editing, OOUI

Jul 13 2017

Jytdog added a comment to T101087: [GTWL] Epic: Advanced search in Wikipedia.

I just want to say that I fully support this. Related discussions that are kind of more about how search results are presented... here and links to phabs therein, namely T156493 and T23139 T40403 . Having the advanced search parameters contemplated here might be helpful towards wasting less time!

Jul 13 2017, 9:15 PM · Advanced-Search, Epic, CirrusSearch, Discovery, TCB-Team (now WMDE-TechWish), German-Community-Wishlist

Jan 30 2017

Jytdog added a comment to T40403: Sortable search results.

@Jytdog i want to clarify a few things here if you don't mind.

Polarised starting points to simplify the next discussion:
1: Developers don't understand the editing process
2: Editors don't understand the intricacies of our technology stack

What you see in the discussion above (and what you describe) is an assortment of desires and wishes (usecases) mixed with technology solutions chosen by editors and developers. This caused a logical response by developers, of evaluating these two, and developers telling editors: 'the solution you picked is not actually solving your problem'. Consequently, developers either have ignored the original usecases, or come up with alternative solutions, which have proven to be prohibitive as well for a multitude of reasons (at this point in time).

A short summary:
1: Yes, having sort filters on the results would be very nice
2: Implementing sort filters (both backend and in UI) is going to be costly.
3: As such, priorities will have to be set. By asking to show usecases that can be met, developers (and managers in this case) try to ascertain if these costs will be offset by potential gain/benefits.
4: Editors present several usecases, but the usecases don't match the technical solution detailed in this ticket. (at least not in an effective way)
5: Inertia sets in, and frustration builds.

Your own use case is a perfect example: Talk archives.
1: We only index the contents of the current version of a page (to index everything would be an increase of 21x of the current infrastructure, which would likely also add some logarithmic increase in complexity of the overall process and technology). This is expensive and still several years out (We are NOT a search company, anything we have will be some 10-15 years behind in what Google is able to do).
2: As such any notion of date and 'recent' is only as recent as the last edit to a page
3: Talk archives are edited all the time (and thus their recent indicator that we currently have isn't useful to determine their age).
4: So while your use case is valid, the chosen technical solution detailed in this ticket probably won't help you solve this particular problem in any foreseeable timeframe.

Volunteer time is the lifeblood of Wikipedia and the search engine wastes it.

I think we all agree on that volunteer time is valuable. But that doesn't negate the cost of a potential solution.

I have always thought it would be amazing if there is was a way to get the diff underlying a comment in an archive by right clicking or something. I imagine that is impossible, but wanted to note that.

That would be amazing, but also non-trivial since a comment can be made up of multiple diffs, pages can be copy pasted and moved etc etc.. There are some tools like wikiblame, which do this to some degree, but to roll those out more widely is probably not realistic at this time. But it has nothing to do with this ticket.

I think the general answer to this is still: You need structured discussions if you want to do that (aka, something based on similar principals as LQT/Flow).

But I can't imagine how daunting and off-putting the process of finding and linking to, or getting diffs for, archived comments is, for new editors who are interested in joining the community. I reckon this is one reason why new editors so often fail to successfully raise issues on behaviour noticeboards, where diffs are essential, and complain that community noticeboards are byzantine.

I think developers and editors alike agree that our discussion system is not targeted at including newcomers. But again, that has little to do with this particular ticket.

One of the problems that I often see in discussion tickets like these, are the mixing of usecases (desires) and technical solutions (abilities/possibilities) within the same ticket. I personally think it would be much better to have usecases and technical solutions in separate tickets with these larger problems, for the sole reason that otherwise you get this back-and-forth between the two that is not constructive to solving problems (especially because the audiences are so different as well).

Regardless, I think that @MZMcBride's summary is really clear and correct (because he understands enough about both sides of the problems, to know what to exclude from his statement). We have 'recentism/last edited' information, we have the technology to order by that parameter, we have an advanced tab in the UI, so it should be possible to expose this information. And that is actually exactly what the german team is considering to be working on: T143310: Implement a way to access keywords such as "incategory", "intitle" via the Search special page and T154911: Redesign the special:search page (Session). But in the strictest sense, that is a just a subset of the request that this ticket started with and the usecases mentioned within it, which likely would require indexing the entire history of each and every page.

In order to solve YOUR problem, with the current technology, we should probably look into the direction of: "Is there some way, that we can special case a subset of Talk pages in the searchengine, to become more discoverable and useful to editors trying to find older discussion, without blowing up our current search solution". I'm thinking like a way to put a special parser key or something on an archive page/template (as we do for disambiguation pages), like for instance {{#TALKARCHIVE|index|date-range}}. But that would be a totally different ticket, because it's not directly related to this particular technical solution that this ticket deals with. I welcome anyone to create more tickets :)

Jan 30 2017, 4:40 PM · Discovery-Search, Discovery, CirrusSearch

Jan 28 2017

Jytdog added a comment to T40403: Sortable search results.

I recently opened at thread on this at Village Pump technical. I have over 100K edits in en-wiki since 2008.

Jan 28 2017, 7:30 PM · Discovery-Search, Discovery, CirrusSearch