Sj added a comment.
Are these questions answered elsewhere? Seems to not quite fit the phab-task
format
TASK DETAIL
https://phabricator.wikimedia.org/T238362
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Sj
Cc: Sj, Tarrow, dcausse, Igorkim78
Sj added a comment.
@Multichill the opening says "so that I can decide whether to move ahead with
this plan and how to communicate it." -- it would help if that linked to a
separate task, whose implementation depended on the outcome of this one. In
the absence of that, this
Sj added a comment.
@Multichill the opening says "so that I can decide whether to move ahead with
this plan and how to communicate it." -- it would help if that linked to a
separate task, whose implementation depended on the outcome of this one. In
the absence of that, this
Sj added a comment.
@Jerven: these are two great updates, thank you. Is there any more recent
presentation you could share?
Perhaps you could give a brown bag talk and record it as one :)
Working with Kingsley + others @ OpenLink on evaluating this makes a lot of
sense.
TASK DETAIL
Sj added a comment.
Looks promising and important -- usage and quality of constraints will
certainly increase once this is resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T201147
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Sj
Cc: Sj
Sj added a comment.
I get a 500 error now... will this be back up before the general release on
Feb 1?
TASK DETAIL
https://phabricator.wikimedia.org/T297454
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: dcaro, Sj
Cc: Theklan, Marsupium
Sj added a comment.
Agreed w/ Lucas, Husky, Multichill.
And with Lego: "I would prefer a reduced SLO + no auth required over better
uptime + auth"
The existence of separate "higher SLO + higher red-tape service channel"
makes sense -- we already hav
Sj added subscribers: JeanFred, Sj.
Sj added a comment.
Thanks for evaluating this. Can you suggest a path forward? Just making
Aude.js work again? @JeanFred
TASK DETAIL
https://phabricator.wikimedia.org/T285498
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Sj added a comment.
Is this monitored by any of the status tools? Does it just need to be
restarted?
(and is it normal for projectadmin's to not have the ability to restart, or a
feature of this being complex service?)
TASK DETAIL
https://phabricator.wikimedia.org/T297454
EMAIL
Sj added a comment.
In T290839#7360739 <https://phabricator.wikimedia.org/T290839#7360739>,
@Justin0x2004 wrote:
>> can give us the short update delays that users expect
>
> I am a user that rarely needs short update delays.
> Didn't we just take a poll about
Sj added a comment.
Looks like it is still 2-3 reqs/s. Is that the target usage rate? A fine
metric for a query service is that it is used to its desired load. If
underused, it could be made open-auth until this is reached, and then somehow
have a conversation with those users re
Sj added a comment.
Definitely useful to communities I'm close to! Came across this recently in
a wikicite / shared source metadata conversation.
Instant WD, Instant Commons, and Q/P reuse in federation together will make
strong reasons for people to choose MediaWiki when deciding
Sj added a comment.
@Lydia_Pintscher hurrah!
TASK DETAIL
https://phabricator.wikimedia.org/T324235
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Sj
Cc: Sj, Lydia_Pintscher, Michael, Bugreporter, So9q, Aklapper, RPI2026F1,
Astuthiodit_1
Sj added a subscriber: MPhamWMF.
Sj added a comment.
Thanks @Gehel for catching the duplicate.
Suggested edits for this (merged) issue:
- The merged issue should be for **making public the data WDQS uses for live
updates**. A specific implementation such as "**...using EventSt
Sj updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T330525
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Sj
Cc: Sj, Gehel, Aklapper, Astuthiodit_1, AWesterinen, karapayneWMDE, Invadibot,
MPhamWMF, maantietaja, CBogen
Sj updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T330521
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Sj
Cc: Aklapper, Sj, AWesterinen, MPhamWMF, CBogen, Namenlos314, Gq86,
Lucas_Werkmeister_WMDE, GoranSMilovanovic
Sj added subscribers: KingsleyIdehen, Gehel, Jheald.
Sj added a comment.
cc @Gehel @KingsleyIdehen @Jheald
TASK DETAIL
https://phabricator.wikimedia.org/T330521
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Sj
Cc: Jheald, Gehel, KingsleyIdehen
Sj created this task.
Sj added projects: Wikidata-Query-Service, Wikidata Analytics, Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
Currently there are a lot of issues for evaluation and analysis, such as:
T206560 <https://phabricator.wikimedia.org/T206
Sj renamed this task from "Migrate off of Blazegraph" to "Migrate Wikidata off
of Blazegraph".
Sj updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T330525
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
Sj created this task.
Sj added projects: Wikidata-Query-Service, Wikidata Analytics.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
**Feature summary** (what you would like to be able to do and where):
Currently, the WDQS update process is mostly decoupled from
Sj updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T330521
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Sj
Cc: Jheald, Gehel, KingsleyIdehen, Aklapper, Sj, AWesterinen, MPhamWMF, CBogen,
Namenlos314, Gq86
Sj added a comment.
@Pintoch The ontotext instance is interesting. Might they be interested in
also providing something closer to a WQDS interface?
TASK DETAIL
https://phabricator.wikimedia.org/T244847
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Sj added a comment.
Hopefully this is already covered somewhere else and can be closed and
merged! I'd hope for the equivalent to include:
- A rough timeline for migration
- Current status of the decisions made / pending re: where and how to migrate
- A map of other components
Sj added a comment.
@Addshore thank you for writing that and resurfacing your old post. Agreed
that recon should be core to Wikibase, both for it to reach new users and to
make setting up new small projects easier.
TASK DETAIL
https://phabricator.wikimedia.org/T244847
EMAIL PREFERENCES
Sj added a comment.
@michael forgive my confusion, isn't part of this being able to use one
Repository with multiple Clients, or to enable WikibaseClient to draw from both
a local Repository and the global Wikidata repository?
TASK DETAIL
https://phabricator.wikimedia.org/T48556
EMAIL
Sj added a comment.
One reason is that citations are a large corpus with a fairly narrow range of
schemas and uses, so it could conceivably be implemented with optimizations
that can't be applied across the board.
TASK DETAIL
https://phabricator.wikimedia.org/T356773
EMAIL PREFERENCES
Sj added a comment.
Has there been any recent progress on this? T348269
<https://phabricator.wikimedia.org/T348269> by one of the preeminent reusers of
SDC, in both scale and impact, seems relevant; but that remains untriaged and
this one is High but unassigned.
Usage
27 matches
Mail list logo
