Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see https://phabricator.wikimedia.org/T288141), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033) and several gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects.
Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features?
Alex *Ruthven* on Wikipedia
Well, I was notified by techncally skilled users that the ned OpenSeadragon library is much heavier and more memory consuming than curreently used tools. So I can only hope that its load into memory can be disabled if one needs so.
(may be critical while working on multiple pages at once)
However, I doubt if any technical comments from communities expressed here will reach developers. And which wiki pages would be more appropriate for such comments.
Ankry
W dniu 20.11.2021 o 14:33, Ruthven pisze:
Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see https://phabricator.wikimedia.org/T288141), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033) and several gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects.
Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features?
Alex *Ruthven*on Wikipedia
Wikisource-l mailing list --wikisource-l@lists.wikimedia.org To unsubscribe send an email towikisource-l-leave@lists.wikimedia.org
Hi Ankry, on Italian Wikisource and on Neapolitan Wikisource there are "Technical" village pumps. I suppose that would be the correct place to post it if there is such a page in other languages. It would be interesting to see what happens if a whole community writes on Phabricator in order to delay a major deployment... It happened in the past that we used global CSS to nullify (display=None) a newly deployed feature that wasn't mature enough. Here it would require more work I suppose, but I am sure that it can be done.
What I am trying to say is that it's ridiculous to be passive when a different community (the so called developers) modify a project without any contact with the users. Alex *Ruthven* on Wikipedia
On Sat, 20 Nov 2021 at 18:36, Ankry ankry.wiki@onet.pl wrote:
Well, I was notified by techncally skilled users that the ned OpenSeadragon library is much heavier and more memory consuming than curreently used tools. So I can only hope that its load into memory can be disabled if one needs so.
(may be critical while working on multiple pages at once)
However, I doubt if any technical comments from communities expressed here will reach developers. And which wiki pages would be more appropriate for such comments.
Ankry W dniu 20.11.2021 o 14:33, Ruthven pisze:
Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see https://phabricator.wikimedia.org/T288141), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033) and several gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects.
Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features?
Alex *Ruthven* on Wikipedia
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
This is information only, so please don't @me, there is no opinion nor deeds by me
There was a post to English Wikisource Scriptorium that mentioned this and a subsequent update https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium&diff=...
The phabricator channel for Wikisources is worth watching https://phabricator.wikimedia.org/project/profile/1117/
The phabricator channel for ProofreadPage similarly https://phabricator.wikimedia.org/project/profile/276/
Where there is any release coming that is impactful for Wikisources, one is able to add the changes so they are marked to appear in Tech News eg. https://meta.wikimedia.org/wiki/Tech/News/2021/45
Similarly there is a mailing list for Tech Ambassadors where impactful news can be sent https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
There is the message delivery list for Wikisource Scriptoriums https://meta.wikimedia.org/wiki/Global_message_delivery/Targets/Wikisource_S... anyone can create messages for use, though it needs "massmessage" right at metawiki so we need someone from https://meta.wikimedia.org/w/index.php?title=Special:ListUsers&group=mas... https://meta.wikimedia.org/w/index.php?title=Special:ListUsers&group=sys... to send. There are numbers of members of WS communities who can do that, and it is not an issue to get more members of community added.
-- billinghurst
------ Original Message ------ From: "Ruthven" ruthven.wiki@gmail.com To: "discussion list for Wikisource, the free library" wikisource-l@lists.wikimedia.org Sent: 21/11/2021 6:46:32 PM Subject: [Wikisource-l] Re: MediaWiki, Wikisource extensions, and new implementations deployment
Hi Ankry, on Italian Wikisource and on Neapolitan Wikisource there are "Technical" village pumps. I suppose that would be the correct place to post it if there is such a page in other languages. It would be interesting to see what happens if a whole community writes on Phabricator in order to delay a major deployment... It happened in the past that we used global CSS to nullify (display=None) a newly deployed feature that wasn't mature enough. Here it would require more work I suppose, but I am sure that it can be done.
What I am trying to say is that it's ridiculous to be passive when a different community (the so called developers) modify a project without any contact with the users. Alex Ruthven on Wikipedia
On Sat, 20 Nov 2021 at 18:36, Ankry ankry.wiki@onet.pl wrote:
Well, I was notified by techncally skilled users that the ned OpenSeadragon library is much heavier and more memory consuming than curreently used tools. So I can only hope that its load into memory can be disabled if one needs so.
(may be critical while working on multiple pages at once)
However, I doubt if any technical comments from communities expressed here will reach developers. And which wiki pages would be more appropriate for such comments.
Ankry
W dniu 20.11.2021 o 14:33, Ruthven pisze:
Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see https://phabricator.wikimedia.org/T288141), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033) and several gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects.
Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features?
Alex Ruthven on Wikipedia
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
I think most Wikisource developers are likely to be on this list. Of course, it's best to make sure there are Phabricator tickets for every separate bug or feature request.
On 21/11/21 1:36 am, Ankry wrote:
Well, I was notified by techncally skilled users that the ned OpenSeadragon library is much heavier and more memory consuming than curreently used tools. So I can only hope that its load into memory can be disabled if one needs so.
(may be critical while working on multiple pages at once)
However, I doubt if any technical comments from communities expressed here will reach developers. And which wiki pages would be more appropriate for such comments.
Ankry
W dniu 20.11.2021 o 14:33, Ruthven pisze:
Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see https://phabricator.wikimedia.org/T288141), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033) and several gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects.
Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features?
Alex *Ruthven*on Wikipedia
Wikisource-l mailing list --wikisource-l@lists.wikimedia.org To unsubscribe send an email towikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Hi all, and thanks for the info.
I get from your messages that there are two major points to be solved: 1. A clear lack of communication (mass messages are often unread or quickly read, because there is some abuse of the tool, and what is important gets lost in the flood of messages). Probably it's not the role of developers to communicate, but someone has to do it. 2. A clear lack of management. There is a global lack of trust in Mediawiki developers for the reason above, but also because certain changes introduced more issues than they solved. I agree with Sam: there is a need for product managers, who can also communicate about important changes, but also check the development and be sure that new changes can be safely deployed. I mean: it's the basics of software development!
I don't think it's a matter of time if we focus on one feature at a time, test it, test it again, do beta test, and then merge it. We're not a software house: we do have time. I understand that volunteers might not be happy in being constrained by a strict workflow, but I also understand that work has to be done well or not done at all.
Btw, I understand that there is beta.wikisource somewhere. Maybe an invitation to the different projects to test the new features there before the merge, would be a good occasion to involve more people in quality control. (sorry if this has been done, and I've missed it)
Cheers, A. *Ruthven* on Wikipedia
On Mon, 22 Nov 2021 at 04:45, Sam Wilson sam@samwilson.id.au wrote:
I think most Wikisource developers are likely to be on this list. Of course, it's best to make sure there are Phabricator tickets for every separate bug or feature request. On 21/11/21 1:36 am, Ankry wrote:
Well, I was notified by techncally skilled users that the ned OpenSeadragon library is much heavier and more memory consuming than curreently used tools. So I can only hope that its load into memory can be disabled if one needs so.
(may be critical while working on multiple pages at once)
However, I doubt if any technical comments from communities expressed here will reach developers. And which wiki pages would be more appropriate for such comments.
Ankry W dniu 20.11.2021 o 14:33, Ruthven pisze:
Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see https://phabricator.wikimedia.org/T288141), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033) and several gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects.
Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features?
Alex *Ruthven* on Wikipedia
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Hey everybody, I stumbled upon this message by chance, but now I'm curious: are you implementing IIIF on Wikisource? That's very interesting!
Aubrey
On Mon, Nov 22, 2021 at 1:13 PM Ruthven ruthven.wiki@gmail.com wrote:
Hi all, and thanks for the info.
I get from your messages that there are two major points to be solved:
- A clear lack of communication (mass messages are often unread or
quickly read, because there is some abuse of the tool, and what is important gets lost in the flood of messages). Probably it's not the role of developers to communicate, but someone has to do it. 2. A clear lack of management. There is a global lack of trust in Mediawiki developers for the reason above, but also because certain changes introduced more issues than they solved. I agree with Sam: there is a need for product managers, who can also communicate about important changes, but also check the development and be sure that new changes can be safely deployed. I mean: it's the basics of software development!
I don't think it's a matter of time if we focus on one feature at a time, test it, test it again, do beta test, and then merge it. We're not a software house: we do have time. I understand that volunteers might not be happy in being constrained by a strict workflow, but I also understand that work has to be done well or not done at all.
Btw, I understand that there is beta.wikisource somewhere. Maybe an invitation to the different projects to test the new features there before the merge, would be a good occasion to involve more people in quality control. (sorry if this has been done, and I've missed it)
Cheers, A. *Ruthven* on Wikipedia
On Mon, 22 Nov 2021 at 04:45, Sam Wilson sam@samwilson.id.au wrote:
I think most Wikisource developers are likely to be on this list. Of course, it's best to make sure there are Phabricator tickets for every separate bug or feature request. On 21/11/21 1:36 am, Ankry wrote:
Well, I was notified by techncally skilled users that the ned OpenSeadragon library is much heavier and more memory consuming than curreently used tools. So I can only hope that its load into memory can be disabled if one needs so.
(may be critical while working on multiple pages at once)
However, I doubt if any technical comments from communities expressed here will reach developers. And which wiki pages would be more appropriate for such comments.
Ankry W dniu 20.11.2021 o 14:33, Ruthven pisze:
Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see https://phabricator.wikimedia.org/T288141), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033) and several gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects.
Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features?
Alex *Ruthven* on Wikipedia
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Not quite, but OpenSeadragon supports it so as soon as we have IIIF for Commons files it'll be possible.
And it's also possible to use the Internet Archive's IIIF API. @inductiveload, you have a prototype for this don't you?
On 23/11/21 4:31 am, Andrea Zanni wrote:
Hey everybody, I stumbled upon this message by chance, but now I'm curious: are you implementing IIIF on Wikisource? That's very interesting!
Aubrey
On Mon, Nov 22, 2021 at 1:13 PM Ruthven <ruthven.wiki@gmail.com mailto:ruthven.wiki@gmail.com> wrote:
Hi all, and thanks for the info. I get from your messages that there are two major points to be solved: 1. A clear lack of communication (mass messages are often unread or quickly read, because there is some abuse of the tool, and what is important gets lost in the flood of messages). Probably it's not the role of developers to communicate, but someone has to do it. 2. A clear lack of management. There is a global lack of trust in Mediawiki developers for the reason above, but also because certain changes introduced more issues than they solved. I agree with Sam: there is a need for product managers, who can also communicate about important changes, but also check the development and be sure that new changes can be safely deployed. I mean: it's the basics of software development! I don't think it's a matter of time if we focus on one feature at a time, test it, test it again, do beta test, and then merge it. We're not a software house: we do have time. I understand that volunteers might not be happy in being constrained by a strict workflow, but I also understand that work has to be done well or not done at all. Btw, I understand that there is beta.wikisource somewhere. Maybe an invitation to the different projects to test the new features there before the merge, would be a good occasion to involve more people in quality control. (sorry if this has been done, and I've missed it) Cheers, A. *Ruthven*on Wikipedia On Mon, 22 Nov 2021 at 04:45, Sam Wilson <sam@samwilson.id.au <mailto:sam@samwilson.id.au>> wrote: I think most Wikisource developers are likely to be on this list. Of course, it's best to make sure there are Phabricator tickets for every separate bug or feature request. On 21/11/21 1:36 am, Ankry wrote:Well, I was notified by techncally skilled users that the ned OpenSeadragon library is much heavier and more memory consuming than curreently used tools. So I can only hope that its load into memory can be disabled if one needs so. (may be critical while working on multiple pages at once) However, I doubt if any technical comments from communities expressed here will reach developers. And which wiki pages would be more appropriate for such comments. Ankry W dniu 20.11.2021 o 14:33, Ruthven pisze:Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS. This time it was T288141 (see https://phabricator.wikimedia.org/T288141 <https://phabricator.wikimedia.org/T288141>), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033 <https://phabricator.wikimedia.org/T296033>) and several gadgets around all the Wikisources. I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects. Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features? Alex *Ruthven*on Wikipedia _______________________________________________ Wikisource-l mailing list --wikisource-l@lists.wikimedia.org <mailto:wikisource-l@lists.wikimedia.org> To unsubscribe send an email towikisource-l-leave@lists.wikimedia.org <mailto:wikisource-l-leave@lists.wikimedia.org>_______________________________________________ Wikisource-l mailing list --wikisource-l@lists.wikimedia.org <mailto:wikisource-l@lists.wikimedia.org> To unsubscribe send an email towikisource-l-leave@lists.wikimedia.org <mailto:wikisource-l-leave@lists.wikimedia.org>_______________________________________________ Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org <mailto:wikisource-l@lists.wikimedia.org> To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org <mailto:wikisource-l-leave@lists.wikimedia.org> _______________________________________________ Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org <mailto:wikisource-l@lists.wikimedia.org> To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org <mailto:wikisource-l-leave@lists.wikimedia.org>
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
I think tackling one thing at a time makes lots of sense, especially if there's a process around it. I don't know who would run such a process, especially considering that developers will generally work on whatever they feel like! Perhaps we need to sketch out (on Meta?) a simple workflow for anyone working on Wikisource code (extensions only; gadgets are informal and should stay that way).
For me, I have a small amount of time to work on Wikisource stuff, and I generally work on whatever's most important. I don't have any actual way to gauge that though (I have wondered if we should encourage people to award tokens to Phabricator tasks, but it seems that there's no way to actually sort by number awarded).
And yep, https://en.wikisource.beta.wmflabs.org/ https://en.wikisource.beta.wmflabs.org/ is there and can be used for testing. Merged changes are live there within ten minutes. However, unless a feature is disabled by a feature flag it'll also be live in production within a week, so it's often not great to merge something that needs end-user testing. Adding a feature flag is possible (e.g. a config var or a preference), but for some things it can be a fair bit of added complexity. Not that it's not worth it for some things, but it should be a decision and not the default way of doing things.
—Sam
On 22/11/21 8:08 pm, Ruthven wrote:
Hi all, and thanks for the info.
I get from your messages that there are two major points to be solved:
- A clear lack of communication (mass messages are often unread or
quickly read, because there is some abuse of the tool, and what is important gets lost in the flood of messages). Probably it's not the role of developers to communicate, but someone has to do it. 2. A clear lack of management. There is a global lack of trust in Mediawiki developers for the reason above, but also because certain changes introduced more issues than they solved. I agree with Sam: there is a need for product managers, who can also communicate about important changes, but also check the development and be sure that new changes can be safely deployed. I mean: it's the basics of software development!
I don't think it's a matter of time if we focus on one feature at a time, test it, test it again, do beta test, and then merge it. We're not a software house: we do have time. I understand that volunteers might not be happy in being constrained by a strict workflow, but I also understand that work has to be done well or not done at all.
Btw, I understand that there is beta.wikisource somewhere. Maybe an invitation to the different projects to test the new features there before the merge, would be a good occasion to involve more people in quality control. (sorry if this has been done, and I've missed it)
Cheers, A. *Ruthven*on Wikipedia
On Mon, 22 Nov 2021 at 04:45, Sam Wilson <sam@samwilson.id.au mailto:sam@samwilson.id.au> wrote:
I think most Wikisource developers are likely to be on this list. Of course, it's best to make sure there are Phabricator tickets for every separate bug or feature request. On 21/11/21 1:36 am, Ankry wrote:Well, I was notified by techncally skilled users that the ned OpenSeadragon library is much heavier and more memory consuming than curreently used tools. So I can only hope that its load into memory can be disabled if one needs so. (may be critical while working on multiple pages at once) However, I doubt if any technical comments from communities expressed here will reach developers. And which wiki pages would be more appropriate for such comments. Ankry W dniu 20.11.2021 o 14:33, Ruthven pisze:Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS. This time it was T288141 (see https://phabricator.wikimedia.org/T288141 <https://phabricator.wikimedia.org/T288141>), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033 <https://phabricator.wikimedia.org/T296033>) and several gadgets around all the Wikisources. I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects. Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features? Alex *Ruthven*on Wikipedia _______________________________________________ Wikisource-l mailing list --wikisource-l@lists.wikimedia.org <mailto:wikisource-l@lists.wikimedia.org> To unsubscribe send an email towikisource-l-leave@lists.wikimedia.org <mailto:wikisource-l-leave@lists.wikimedia.org>_______________________________________________ Wikisource-l mailing list --wikisource-l@lists.wikimedia.org <mailto:wikisource-l@lists.wikimedia.org> To unsubscribe send an email towikisource-l-leave@lists.wikimedia.org <mailto:wikisource-l-leave@lists.wikimedia.org>_______________________________________________ Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org <mailto:wikisource-l@lists.wikimedia.org> To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org <mailto:wikisource-l-leave@lists.wikimedia.org>
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
It seems that current Wikisource scan image handling implementation is terribly resource consumeng (network, memory):
While earlier scan image loaded were max 1k px width, now there are two images downloaded for each scan: max-width + 2*max-width (scalled up for some reason). This means, eg. assuming 2k-width scan (which is quite standard, now) that you will need to download and handle about 4^2 + 2^2 = 20 times larger network trafic (100% max-width + 200% max-width images).
This might SIGNIFICANTLY affect users who pay for network transfer.
And I wonder how was this accepted without wide discussion while earlier implementing prev/next image preload/prefetch discussion met an oposition from some developers who suggested that 10-100% (1.1-2x) larger network trafic could be a problem for some users.
Unfortunately, I am out of time resources today, so I would welcome if anybody fills a bug (or bugs) concerning this.
Ankry
PS. Setting scan width in index pages (likely to half of the required width) would probably be a temporary workaround for affected users.
W dniu 22.11.2021 o 04:44, Sam Wilson pisze:
I think most Wikisource developers are likely to be on this list. Of course, it's best to make sure there are Phabricator tickets for every separate bug or feature request.
On 21/11/21 1:36 am, Ankry wrote:
Well, I was notified by techncally skilled users that the ned OpenSeadragon library is much heavier and more memory consuming than curreently used tools. So I can only hope that its load into memory can be disabled if one needs so.
(may be critical while working on multiple pages at once)
However, I doubt if any technical comments from communities expressed here will reach developers. And which wiki pages would be more appropriate for such comments.
Ankry
W dniu 20.11.2021 o 14:33, Ruthven pisze:
Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see https://phabricator.wikimedia.org/T288141), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033) and several gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects.
Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features?
Alex *Ruthven*on Wikipedia
Wikisource-l mailing list --wikisource-l@lists.wikimedia.org To unsubscribe send an email towikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list --wikisource-l@lists.wikimedia.org To unsubscribe send an email towikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list --wikisource-l@lists.wikimedia.org To unsubscribe send an email towikisource-l-leave@lists.wikimedia.org
While earlier scan image loaded were max 1k px width, now there are two images downloaded for each scan: max-width + 2*max-width (scalled up for some reason). This means, eg. assuming 2k-width scan (which is quite standard, now) that you will need to download and handle about 4^2 + 2^2 = 20 times larger network trafic (100% max-width + 200% max-width images).
That's definitely a bug/not the intended implementation. While the Openseadragon configuration does contain two layers that load the higher resolution versions of the image (specifically 1.5x and 2x), the way it was configured, it should be loading the higher-res images progressively only if the user zooms in. If the user does not zoom in, then Openseadragon should not be loading higher-res images.
I'll file a bug and try to investigate what's causing the issue.
Regards, Sohom Datta
On Tue, Nov 23, 2021 at 2:02 PM Ankry ankry.wiki@onet.pl wrote:
It seems that current Wikisource scan image handling implementation is terribly resource consumeng (network, memory):
While earlier scan image loaded were max 1k px width, now there are two images downloaded for each scan: max-width + 2*max-width (scalled up for some reason). This means, eg. assuming 2k-width scan (which is quite standard, now) that you will need to download and handle about 4^2 + 2^2 = 20 times larger network trafic (100% max-width + 200% max-width images).
This might SIGNIFICANTLY affect users who pay for network transfer.
And I wonder how was this accepted without wide discussion while earlier implementing prev/next image preload/prefetch discussion met an oposition from some developers who suggested that 10-100% (1.1-2x) larger network trafic could be a problem for some users.
Unfortunately, I am out of time resources today, so I would welcome if anybody fills a bug (or bugs) concerning this.
Ankry
PS. Setting scan width in index pages (likely to half of the required width) would probably be a temporary workaround for affected users.
W dniu 22.11.2021 o 04:44, Sam Wilson pisze:
I think most Wikisource developers are likely to be on this list. Of course, it's best to make sure there are Phabricator tickets for every separate bug or feature request. On 21/11/21 1:36 am, Ankry wrote:
Well, I was notified by techncally skilled users that the ned OpenSeadragon library is much heavier and more memory consuming than curreently used tools. So I can only hope that its load into memory can be disabled if one needs so.
(may be critical while working on multiple pages at once)
However, I doubt if any technical comments from communities expressed here will reach developers. And which wiki pages would be more appropriate for such comments.
Ankry W dniu 20.11.2021 o 14:33, Ruthven pisze:
Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see https://phabricator.wikimedia.org/T288141), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033) and several gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects.
Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features?
Alex *Ruthven* on Wikipedia
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
There's a lot of activity recently on the ProofreadPage extension. It seems a good thing to me: thanks to all involved!
I didn't see which commit exactly is at fault, but the first step is usually to note breaking changes on the commit message and add a user-info tag on the task so that it goes into Tech News. Developers don't always have time to handle communication as well, but we can at least try to use what there is.
Of course the definition of breaking changes is sometimes fuzzy, as by necessity gadgets etc. often have to be based on unstable interfaces. But we're all on the same boat.
Federico
I totally understand this frustration, and I'm not really sure what the solution is. There's no WMF team responsible for Wikisource (other than the small amounts of work that my team, CommTech, gets to do; although I'm writing this email as my volunteer self). So it's up to whoever wants to do the work, and generally getting the work done comes first and any announcements or outreach are an after-thought and can sometimes get forgotten.
There's lots of development happening with Wikisource-related things at the moment, because there are more developers interested. Which is really great! I feel like it's exciting, and there's lots of enthusiasm. Some bits of the Wikisource stack have been unchanged for years and years, because they're quite complicated, and responsibility has fallen on the same few users to fix any problems. Now we seem to be in an era of new features, which comes with different challenges.
So I'm sorry if it feels like Wikisource is used as a guinea pig — I think it's more that the software stack here is unique among Wikimedia projects. Changes do get tested, nothing is ever merged that hasn't been checked by multiple developers. But we don't have a good system of rolling out big changes like the recent update to the zoom/pan library (from a homegrown system to OpenSeadragon).
We need more volunteer product managers! As in, people to have a good overview of what development is happening or needs to happen, and help it go smoothly. It's no harder than herding cats, surely!
Sorry, I don't think I'm writing any of this very clearly... all I really wanted to reply was "we're doing our best, and no one's got enough time!". But there's lots more to it.
—Sam
On 20/11/21 9:33 pm, Ruthven wrote:
Hi all, as usual, I get surprised every time there are major changes on the MediaWiki software that are deployed without providing advance warning to the community. Every time it's the same story: something stops working on the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see https://phabricator.wikimedia.org/T288141 https://phabricator.wikimedia.org/T288141), that was deployed in all the Wikisources (then rolled back because WikiMedia computer scientists are the best) completely disrupting redesigning the image side of the Page namespace. This affected the toolbars (see https://phabricator.wikimedia.org/T296033 https://phabricator.wikimedia.org/T296033) and several gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be improved: it's normal that we're trying to get all we can from this outdated software. I am just asking that major changes that affect all the Wikisources should be announced in every single Village Pump waaay before deploying them on the projects.
Is it possible, as a Usergroup, to do a little pressure to be considered as a community and not as guinea pigs on which to deploy new, partially-tested features?
Alex *Ruthven*on Wikipedia
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org To unsubscribe send an email to wikisource-l-leave@lists.wikimedia.org
wikisource-l@lists.wikimedia.org