During Wikimedia-Hackathon-2019 @Charlie_WMDE, @Jakob_WMDE and I conducted some user testing on some visual query building interfaces, and took some notes available below:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 19 2019
May 18 2019
May 17 2019
Apr 1 2019
Feb 20 2019
Dec 28 2018
Oct 27 2018
Aug 18 2018
Aug 16 2018
In T199816#4444683, @fgiunchedi wrote:I've setup a very bare deprecation page for status.wikimedia.org, we can sunset the DNS name in some weeks time.
Jul 23 2018
Jun 16 2018
In T195756#4239426, @Ladsgroup wrote:Indeed, we were thinking of having a special page called ""Special:DsiabledSpecialPage" in such cases but building that is outside of our scope for now.
Just for completeness, I'm copying the comment I added in T195754:
We don’t want any of those
May 29 2018
FWIW, I use this quite often (manually), when the search results are too numerous and I'm looking for items with a specific name, since the intitle: operator doesn't work for Wikidata items.
Is there any way an error message could be shown to users to explain why Special:ItemDisambiguation is being redirected to Special:BlankPage? It's quite puzzling for someone who isn't aware of the current issues.
Apr 9 2018
Nov 13 2017
Oct 31 2017
Oct 27 2017
In T166272#3437125, @Jdlrobson wrote:For those who want well formed HTML we will be providing a new service on RESTBase which will guarantee that (please follow along with T113094)
Aug 26 2017
Aug 23 2017
Aug 9 2017
Can anyone comment on why the patch hasn't been merged? I can't see any outstanding review issues, but I may be missing something.
I've also been seeing this problem on Wikidata. Here's a screenshot of the issue, as an additional data point:
Aug 2 2017
Aug 1 2017
Jul 28 2017
Note that the Abuse filter was just a stop-gap measure while we finished the setup (which has been taking longer than we'd like), it wasn't meant to be permanent. I personally would prefer not making well-meaning editors with established accounts on other Wikimedia wikis (like MarcoAurelio :)) jump through hoops to make edits. But that's something we can look at later down the road. For now the fishbowl approach is probably the quickest solution.
Jun 18 2017
Jun 8 2017
May 26 2017
May 19 2017
May 15 2017
May 10 2017
May 2 2017
On a slight tangent: during the import, we're taking care to avoid importing all pages indiscriminately, to reduce some of the cruft (templates, redirects, images from commons, etc.) that accumulated over the years. It would be very helpful to this effect if we could run maintenance scripts on the wiki during the import process. Would it be possible to install Extension:Maintenance? If so, let us know if you'd prefer a separate issue to track that.
May 1 2017
I need to be able to get the formatted extracts either via the old api.php or the new REST service. If a new endpoint is created providing such extracts with well-formed HTML, yes, that would work for me.
Those weren't really sensitive (in e.g. the legal sense) documents, just internal organizational stuff that didn't make sense to be published, so there's no significant risk for us (in fact, most of those documents aren't event current anymore). We already have plans to deal with that content, and were just making sure there weren't new recommendations for that use case. Thanks all for confirming.
In T126832#3224558, @jcrespo wrote:waldyrious- no data existe live anymore of the old wiki (only temporarily on backups), not even on labs.
Apr 30 2017
In T67169#3221431, @Jdlrobson wrote:I think this task is exactly the same as what we are talking about in T113094 and its subtasks ?
In T126832#3221503, @jcrespo wrote:We do it normally as long as it is not private (the text written there is open to the internet).
Apr 28 2017
IIUC, that is not exactly what this request is about: currently I'm using a request like https://en.wikipedia.org/w/api.php?action=query&prop=extracts&exintro&indexpageids=true&format=json&generator=random&grnnamespace=0&format=json, which returns a html-formatted extract. The problem is that the html is not guaranteed to be valid, hence it fails if embedded in a xhtml page (or any other context where well-formed xml is required).
Apr 27 2017
Thanks everyone, much appreciated!
Apr 9 2017
Just pinging to make sure this hasn't fallen off the radar :) is there anything blocking the scheduling?
Apr 7 2017
Apr 5 2017
Can someone clarify when/why this was closed as declined/wontfix? I can't see that in the activity logs of this task -- perhaps it's a detail that wasn't preserved in the bugzilla import.
Mar 28 2017
I'm a bit confused by this issue. Judging by its title and description, isn't it the same as T62437? And if so, isn't it resolved already? If not, it probably needs clarification.
Feb 28 2017
Sorry all for the spam caused by adding & removing this task from Wikimedia-site-requests. I was trying to get a list of wikis where this extension has been/is planned to be enabled, and I came up with this query, which suggested that the combination of Wikimedia-site-requests and ArticlePlaceholder was the right way to get this information. Please let me know if such a list is being maintained elsewhere.
Feb 19 2017
In T3790#3015475, @Jdforrester-WMF wrote:In T3790#3015429, @srishakatux wrote:Any updates on this task? Would this be suitable for GSoC or Outreachy? We are currently recruiting projects and mentors for May-Aug 2017.
T132058: 3d extension supporting STL (3d printing files) is mostly complete, and will mean the main request here is Resolved, so no, I don't think it'd be a good fit.
OBJ would be a good format for open 3D models because it has an exclusively text-based representation, contrary to STL (T143201, T132058), and PLY (T145499), which can be either ASCII or binary. What's more, STL files are often saved in the binary format by default, while providing no no surface distinction --e.g. in the filename extension-- which would allow distinguishing them from the ASCII ones.
Jan 19 2017
I've created Category:WebP file format and Category:WebP files to track WebP (and WebP-related) files. I think I've collected all of them at the time of writing.
Jan 8 2017
Indeed, the WMF logo is in the bottom row of the logos grid, but still part of that grid, so the main issue remains. Considering that the page contains 16 logos in a neat 4x4 grid, we could still have a perfect 5x3 grid if we removed one logo from there, so not even aesthetics would be sacrificed with such a change.
Dec 18 2016
In case this helps, I am also using Firefox (50.1.0) and have the uBlock extension installed.
Nov 28 2016
Nov 22 2016
I don't think we should be the ones to choose where to put the emphasis. It could well be that newcomers to Wikimedia development would be interested in working on high-impact issues (the same reason why editing articles on Wikipedia and having the result immediately published for all to see is attractive), which may include submitting changes to core MediaWiki. Are there any processes through which we could collect what documentation resources people are lacking the most? Maybe the Analytics team has collected / can collect some data in that regard?
Oct 31 2016
In T149372#2755614, @Tgr wrote:Coming up with some sort of checklist/guideline/best practices for writing effective documentation would be cool.
Oct 28 2016
Since two hours is way too little time to make a considerable dent in the actual documentation needs, I would suggest using that time to work out higher-level issues, particularly figuring out what's needed and defining immediate next steps for:
Oct 27 2016
@Qgil I'd be very interested in a proposal around this, but honestly the nature and scope of the expected activities for the summit aren't clear from the CFP page. Maybe one or two generic examples, or ballpark estimates in terms of expected duration, level of structure, type (hands-on, discussion, presentation?...) would be useful. Or even some highlights among current proposals which could serve as inspiration.
Oct 1 2016
Mar 18 2016
Thanks @demon! Let us know if there's anything you need from our side.
Feb 22 2016
Thanks @Nikki, I'll mark this as a dependency.
Feb 19 2016
Feb 17 2016
Thanks for the clarifications, @Krenair. SpecialInterwiki isn't critical, just a nice-to-have. Configure, OTOH, would be really handy, but I understand there are concerns about its usage -- it was a long shot, but I thought I should at least ask.
Feb 16 2016
Oh, also, if that's still a possibility, it would be nice to use "WMPT" and "WMPT Discussão" as project / project talk namespaces.
Sorry for not commenting sooner, but if possible, we'd also like to have at least the CategoryTree, EasyTimeline, PdfHandler, ParserFunctions and SpecialInterwiki extensions installed. I'm not sure those are installed by default on all such wikis. Something like this: https://nyc.wikimedia.org/wiki/Special:Version would probably cover most of our potential needs. I would also ask for the Configure extension, if that would be ok.