Migration issue: RBP moved from email to access code to proxy, so only four users have active authorizations but many more have an active account on the RBP side.

Confirmed, appears to be working as expected

When I try to access MIT via proxy, the error message I receive is "You don't have an email on file. We can't finalize your access to partner resources, and you won't be able to contact us without an email. Please update your email." I do in fact have an email on file. Test was on production, have verified that I have an active authorization for the partner, the partner is set to proxy access, the target URL is correct (although the Proxy/Bundle page in My Collections links to the unproxied target URL).

Per more recent conversations, okay to replace this with simply requiring people to re-agree whenever a change deemed significant happens.

Affected partner is active

Surveys need a revamp anyways, this would be a good part of that.

Yes, but in that case could we prioritize that?

I don't seem to have been notified about https://wikipedialibrary.wmflabs.org/applications/evaluate/8798/

Yes, that sounds reasonable

However, coordinators need not be notified of their own comments on such applications.

Ours

...Yeeess. My issue is not that you actually have to scroll to the user you're interested in, I get that you can just type it. But in this particular case I don't think you'd ever really want to scroll, so should just have typing.

Also got the same error in trying to update a contact person.

Hm. I've added myself as coordinator, but I don't need emails, so I'm quite fine with undoing that if it's possible to just skip those partners without a coordinator listed.

From same reporter: "out of 100 articles that perhaps 85 of them the LINK goes to a dead end/no longer available/missing page... of the 100 that I've done I've linked 4"

I can think of a couple of ways although neither would be perfect: flag by format, or flag by database (we have a few databases we can easily mark as containing mostly primary sources - eg Fold3, many of the Adam Matthew, etc).

Waitlisting was the only action yes, but at the moment out of a few I tested the problem only occurs on Newspaperarchive (which conveniently is the only one I actually want to change right now...).

@DarTar @Charles_Matthews Added those sample templates and proposed organizational definitions to https://www.wikidata.org/wiki/Wikidata:Publication_types#Models - feel free to edit

Drafted at https://www.wikidata.org/wiki/Wikidata:Publication_types#Properties

Drafted at https://www.wikidata.org/wiki/Wikidata:Publication_types

Broadly speaking, "the document should not infringe copyright law, whatever that means in an international context" is correct; however, the problem is operationalizing that for the average user. The reason I suggested including SHERPA/RoMEO is because it does track what the publisher allows to be archived.

One remaining issue with the tags: attempting to add "newspapers" as a tag results in 500 error on save.

No, I sent the email to the editor through the onwiki interface.

1. Go to the list of Pending Review applications (https://twl-test.wmflabs.org/applications/list/)
2. Click through to an application (eg. https://twl-test.wmflabs.org/applications/evaluate/54/)
3. Change status dropdown to "Not Approved" and click "Set application status" button
4. Server Error 500

One of the coordinators is also reporting server errors, I've asked him to comment here.

Not quite, still getting server errors in some reviewing tasks, such as marking an application as "not approved".

The answer is "sometimes" - we have pushed back on some details in the past, and sometimes that has been no problem and other times they've specifically requested the data. We've also used workarounds on the partner side, such as using the WMF address for everyone when the partner's system requires that an address be entered.

https://docs.google.com/document/d/1XYE3DA236Awqs8Rl9s2U543-C7O7_ahqjc40pDtWkM8/edit

Right, because the intended result is that the instructions ARE basically the same no matter which partner. Now, is it worthwhile implementing something else in the interim? Not sure.

I think the eventual implementation will be the second case - basically the same email for everyone - but I'm not sure we're at the point that that can happen yet.

If we could have an option to effectively limit by namespace, that would be great. Even then, you'd need a much higher limit in order to not have an issue. The example I gave should return over 30,000 results, and that's not uncommon. For example, when I'm doing patrols for unreliable/inappropriate external links, I frequently do searches in the 30,000-40,000-results-range because the list is so full of non-mainspace links. But even limiting to mainspace, doing multi-domain searches often exceeds 10,000.

I can translate to French - we also already have some of the same materials in French courtesy of the fr-wiki branch. However, it might also be helpful to have a rtl or non-Roman-script language.

Done - it's Template:Ptag on Meta