On Fri, Jan 22, 2016 at 6:25 PM, Dan Garry <dgarry(a)wikimedia.org> wrote: Quick minor process point here (which I know Dan knows, but just didn't spell out in this case): Experimental work done during your "10% time" does not need to be prioritized by any product owner. For that work, it might make sense to track it in phab, but it might not, so use your judgment there, or chat with your product owner about it. Within the few months that Discovery has been officially supporting "10% time" projects, they have already produced some really good work, and have been turned into production features on multiple occasions. Experimental work that isn't part of the 10% absolutely needs to be phabbed, and then prioritized by the PO. Kevin

On Fri, Jan 22, 2016 at 6:16 PM, Stas Malyshev <smalyshev(a)wikimedia.org> wrote: Agree. Note that these are *early* prototypes, they haven't gone through any product/design/community/engineer reviews. They're here mainly to illustrate the idea. Nonetheless, I love seeing feedback already. Good points Stas. The Reading team is also interested in trending articles. There will be a meeting soon to discuss all together about the issues around this feature and the possible implementation(s). Thanks for bringing this up. ^ Deborah: you can start a list :) Good catch. There are bugs indeed (as well as many minor improvements to do), and they'll have to be fixed (as much as we can) before we deploy to our users. Again, these are early prototypes :) On Fri, Jan 22, 2016 at 6:52 PM, billinghurst <billinghurstwiki(a)gmail.com> wrote: I'd like to point to https://phabricator.wikimedia.org/T110070#1653320 where Dan explains better than me that we are not responsible for the sister portals. Not that we don't care, but we just don't have the resources to improve all sites at the same time, so we decided to focus our efforts on the portal that gets huge traffic. Jan and I have met mxn (the maintainer of sister portals) in person, and he was convinced that the new typeahead would be a great improvement for, at least, www.wiktionary.org . Jan coded the typeahead feature in a way that's exportable. If the community wants to follow our path and implement what they like from what we do, they sure can. The code is open source, and we may even find some time to help if needed. Agree. This is something we definitely want to explore. We have an incredible amount of knowledge, why should we only expose a part of it to our users? But this kind of test is hard to do right now without changing the page too much. This is exactly why I feel having a faster, more revolutionary train - that does not impact our users negatively - will drive discovery up. *Thank you for your comments. * Please keep telling us what you think about this.

On 22 January 2016 at 20:43, Julien Girault <jgirault(a)wikimedia.org> wrote: Yeah, these things can be pulled down and replaced with something else with just a few console commands, so I don't think there's any problems here either. :-) Dan -- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation

On Billinghurst's point I would really love to see the changes that have been successful tested on (particularly) Wikisource, where I imagine that the dropdown metadata could be tremendously valuable. On 25 January 2016 at 07:42, Oliver Keyes <okeyes(a)wikimedia.org> wrote: -- Oliver Keyes Count Logula Wikimedia Foundation

...that is, if it is prioritized for a link from the portal homepage, anyway. On Monday, January 25, 2016, Adam Baso <abaso(a)wikimedia.org> wrote:

Yeah, had a similar concern. I was wondering if a non-indexed subdir would do the trick. Naturally any code deployed for potentially so many users would need scrutiny for simple stuff like XSS, and I imagine analytics scripts would have to factor in the sub site. On Monday, January 25, 2016, Oliver Keyes <okeyes(a)wikimedia.org> wrote: