^ That's what it looks like with a white background. I can push a patch for it, but is it a problem that this component is then inconsistent in appearance from the other Drawer component implementations?
I'd like to see a test which opens the homepage, enables the Suggested Edits module, clicks on a task, and verifies that the browser is on the URL associated with that task. I realize that's a lot to ask for though :)
@Tgr @Catrope @marcella please feel free to update the task description or add comments here if you think I've missed something or you prefer a different focus for the performance review of Special:Homepage + Suggested Edits.
@jeena @brennen @hashar @awight @Krinkle something I'm interested in pursuing as an alternative approach to T225218 is to reduce the scope of what Quibble does. Currently it has a Dockerfile that contains all the languages (php, python, nodeJS) and tools (mysql server, selenium, chromedriver, php etc) needed for running all kinds of tests.
Fri, Dec 6
@MMiller_WMF this task is in ready for development but after reading through the comment thread and the task description I'm not sure what the next step is here. Could you please clarify?
Good catch @Etonkovidova !
Wed, Dec 4
@Etonkovidova we need to update one of the beta labs environments to use the local configuration + search. Maybe CS wiki? And we should probably switch Testwiki to use a local configuration and search as well.
Tue, Dec 3
@Mstyles I think that could work (see also these docs) and it seems like less work than the Docker image approach. It's unclear to me how you'd take the result and tell Gerrit about it, though. But maybe try going the maven approach and experiment with it locally, then see if it would make sense to also do in CI.
I'll work on it this week while @Tgr is OoO.
I agree that the answers should probably be yes, but would want us to be able to show source as via the homepage/SE module vs organically.
Alright, having looked through the code in integration/config again here's a summary of what is going on.
Help page for 2020 is now created, so it should be safe for next 12 months.
@Mstyles ^ sorry forgot to mention you on that last comment.
There's a little bit of outdated documentation here https://www.mediawiki.org/wiki/Continuous_integration/SonarQube_Scanner I'll try to update it soon.
Mon, Dec 2
Fri, Nov 29
For a somewhat different take on this, I hacked together https://github.com/kostajh/mediawiki-dev-env earlier today; the README has some more details there. While there are limitations to PHP's built-in server, its ease of use and performance on macOS / Windows compared to a container approach seems worth exploring.
Wed, Nov 27
M. Pageviews icon and text should…
D. Placeholder image should not have dark borders on the edges
C. Image should be…
@RHo how does this look?
If we end up implementing this then the 60 minute threshold is fine, it's the commonly identified between-edit session threshold on Wikipedia anyway.
Another is a user opening up a number of suggestions to by going back and forth on their homepage, then deciding to edit one of the suggestions by navigating there via the global search.
Unrelated(?): Is there a horizontal scroll happening inside that drawer, and if so can we remove it?
@Etonkovidova Locally I've verified that this patch does what it says. In order for you to QA on beta, we would have to override $wgPageViewInfoWikimediaDomain. This might end up confusing others. Maybe we could just override it for cs beta. Do you have a preference on this?
@nettrom_WMF the way this is implemented in the patch means that you'll have some subset of users (40% of the total) who have the homepage and initiation preferences set at account creation time, and 40% of users who have homepage preference set initially but then manually activate the suggested edit preference. I assume that you'll be able to distinguish these experiment groups in analysis by looking at the timestamps of account creation and preference setting, but maybe you'd prefer to have a new preference that contains a comma-separated list of which experiment group(s) the user is in?
Tue, Nov 26
Tangentially, wondering if https://www.eclipse.org/che/ could be used with the images that have been built for local-charts.
Ah, right, I can override the AQS Config service:
The domain is taken from $wgPageViewInfoWikimediaDomain (if set). That's less discoverable, but more relevant, and you might want to use a local RESTBase instance (for testing with local articles; "local" might also mean beta) but non-local AQS (as setting that up is even more of a PITA than RESTBase).
@RHo the Drawer component uses a down arrow rather than an X, is that OK to use?
Mon, Nov 25
Another nice-to-have with this for local development and QA would be to parse GERestbaseUrl, if set, and extract the domain (e.g. cs.wikipedia.org) to use there, rather than relying on wgServer.
@Tgr one downside to this approach is that if the call to the Pageviews service errors out, the entire card fails to render. It would be nice if the pageview data was treated as an extra component, rather than a blocker to rendering the card.
If we do that, I suppose we should rewrite the existing logging code to use it as well?
Fri, Nov 22
Wouldn't the "just one thing" be the repo that has the docker-or-whatever configuration? Then when you run docker-or-whatever, that pulls in MediaWiki along with the extensions, services, LAMP stack, and so on.
Hopefully you will also see tasks whose template name ends in a question mark (e.g. Kdy?); if not, we may have broken the search for those templates.
Could we make use of cache to check on the server-side when we think a user has made an edit via newcomer tasks? Something like:
@kostajh -- I was just testing this out in beta. While I can confirm that this does disable the Done button, the user is still able to uncheck all the boxes and click the "x", leaving them with no suggestions (i.e. their "no boxes" setting was saved even though they cancelled the dialogue). If they uncheck all the boxes (or do anything else with the boxes), clicking "x" should ignore what they did and put them back the way they were before they opened the dialogue.
Since screen readers don't know how to open it, the presence of the X does not really matter to them
Tue, Nov 19
sounds good, thanks @eprodromou
The widget should be dismissed just by the user moving their mouse away from the "i", with no "x" needed. Shown in this mockup and screenshot from mockup below:
Mon, Nov 18
Thanks for the ping, +2'ed.
Gergő has a work in progress patch, assigning to him. (@Tgr please unassign / move to Ready for Development if you'd like someone else to finish it)
Sat, Nov 16
If we do this, we should probably also do the “animate searching icon” at the same time because otherwise the user will have no indication that any search is happening — the count is always going to be 200.