"foundation wikis" is undefined.

Nemo, "Project wikis?" basically the first 3 rows at http://www.wikimedia.org/ if there is a better term please let me know so I can write more clearly in the future.

Those are the content projects, but ok, basically all wikis (for the sake of this component).

(the dependency is reversed, the items from the other bug need to be address first, notably perf and security reviews)

Greg, it depends on the perf and security review, not the deployment of the extension right?

(In reply to Jared Zimmerman (WMF) from comment #2)

Nemo, "Project wikis?" basically the first 3 rows at
http://www.wikimedia.org/ if there is a better term please let me know so I
can write more clearly in the future.

See these 3 pages, for various group-names, and why "foundation wikis" was confusing. :)
[[m:Complete list of Wikimedia projects]]
[[m:Wikimedia projects]]
[[m:Table of Wikimedia projects#Projects without language subdomains]]

(In reply to Jared Zimmerman (WMF) from comment #5)

Greg, it depends on the perf and security review, not the deployment of the
extension right?

To test it requires deploying it, even if just for one month :)

The details of what the 1 month test entails should be outlined including the goals and rubric that will be used to judge the test. Otherwise it's not a test :)

So, for the avoidance of doubt:

1. Get all of the checklist items done in bug 62811#c42
2. The last one is slightly different in this case because a 1 month test run is being suggested
3. Communicate the goal of the test and the rubric (I suggest getting explicit CL support on this, it's potentially not a slam dunk/easy thing)
4. Run the test
5. Assess via the rubric for removal/keeping

(sidenote: is this going to be a new model of deploying extensions? We have the "standard way", the BetaFeatures way, and now an explicit 1 month test phase method? Let's sit down and talk about that.)

@greg I proposed the 1 month test period for a few reasons, Beta Features doesn't really make sense because it has no user facing effect on the site itself. The second reason is the questions about "does the community want this" is always a long conversation, if we know it makes a difference in traffic that will be a data point to weigh with everything else, if it doesn't then we'll know that we don't necessarily need to prioritize and spend as much time on community consultation for a feature that doesn't really gain us much.

To your general point about standards, they sure are great, if people actually use them.

There's one problem with this plan: page HTML is cached for 1 month, so TC will come into full power only when you're proposing to disable it, and then it will take another month for the cards to disapear. This also means that whatever effect it will give will kick in slowly, making the analysis harder.

good point Max, lets just roll it out then ;)

Adding an extra blocker. It's from me, so you know what it is about :)

@luis, I can think of 2 options, I don't know how possible either are…

1. modify the image, add a footer which contains the basic licensing req. as a watermark

2. modify the request for the description text only when pulled from twitter and include the licensing info in the description sent to twitter.

What is the current status of this?

Its blocked by 4 tasks that are all in backlogs (e.g. non-prioritized) I'd love to see some movement on it though.

In T66930#848573, @JeanFred wrote:

What is the current status of this?

The extension mainly needs to be re-written (or fixed) to not be extremely slow. Looking at the profiling data of http://test.uncyclopedia.co/wiki/MediaWiki?forceprofile=true adding the TwitterCards output takes about half the page request. Ideally it would not make an internal API request.

The extension is currently only a prototype without any intelligence to fetch metadata.

Text content

A reasonable feature request could be to use the first paragraph of the introduction as description.

Images content

Since it has been written, a code to extract metadata, tested in production exists: it's the code used by the multimedia viewer.

So a rewrite is most than very welcome and will help to to get a solid common API for multimedia viewer, TwitterCards, also ready for other extension which needs to access image metadata.

About the test

As long as the minimal features describes, the purpose of the test puzzles me: why test cards not offering a reasonably correct representation of our content?

I hereby question the Greg and Jared intent to test a so very rough protype and to have opened every bugs like if the extension would be ready for deployment, when virtually no development has been started.

I don't know that we'd want to just use the basic extract from lead text, we might want to do what we're doing with Hover cards ( Page-Previews ) where we start with the text extract then clean it up a bit, to remove templates, and other things that make sense in articles but less in snippets and shares.

(Pretty sure @Jaredzimmerman-WMF didn't mean to actually add the popups project to this task, correct me if I'm wrong.)

In T66930#848573, @JeanFred wrote:

What is the current status of this?

If this idea (adding Twitter support to MediaWiki) is going to move forward, I think a request for comments on mediawiki.org would help: https://www.mediawiki.org/wiki/Requests_for_comment.

I'm not sure a trial is needed here. We (Wikimedia) need to decide whether we want this functionality. If we do, we need to fix up the extension to be usable on our sites.

This specific task can probably be closed. I think it was filed with the idea that a quick trial could bypass security and performance issues, but that's clearly not the case. :-)

In T66930#849720, @Jaredzimmerman-WMF wrote:

I don't know that we'd want to just use the basic extract from lead text, we might want to do what we're doing with Hover cards where we start with the text extract then clean it up a bit, to remove templates, and other things that make sense in articles but less in snippets and shares.

That's pretty much what the extension does.

In T66930#849770, @greg wrote:

(Pretty sure @Jaredzimmerman-WMF didn't mean to actually add the popups project to this task, correct me if I'm wrong.)

Ugh, Phabricator, adds anything you mention, can be helpful sometimes, and annoying other times.