[Wikisource-l] Re: MediaWiki, Wikisource extensions, and new implementations deployment

[Sam Wilson]

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-le...@lists.wikimedia.org


___
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org
To unsubscribe send an email to wikisource-l-le...@lists.wikimedia.org
___
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org
To unsubscribe send an email to wikisource-l-le...@lists.wikimedia.org

[Wikisource-l] Re: MediaWiki, Wikisource extensions, and new implementations deployment

[Sam Wilson]

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 
), 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-le...@lists.wikimedia.org
___
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org
To unsubscribe send an email to wikisource-l-le...@lists.wikimedia.org

[Wikisource-l] Re: 2021 report

[J Hayes]

+1
The report as written is fine with me.
Jim hayes

On Sat, Nov 20, 2021 at 5:57 AM Ankry  wrote:

> I think that information like "WCUG member X presented a session on Y at
> event Z" would be hard to manage in this form as (1) we have no formally
> managed membership at the moment (maybe we should change this and ask
> interested people for formal declarations at regular intervals? - the list
> on meta is unmaintained and contains initial declarations only) and (2)
> most of us are also members of other formal affiliates and while our
> activity in specific fields can be separated internally, this separation
> would be not verifiable without clear declarations of these members (should
> we ask them for such declarations concerning any Wikisource related
> activity?)
>
> For example, while I am a member of WMPL and participated in the
> organization committee of Źródłosłów 2021, I clearly declared to WMPL that
> I represent the community, not WMPL during the organizational process. But
> neither information about roles of the conference organizing committee
> members, nor this declaration is anywhere in public. Only the results of
> this activity are public.
>
> And I am active in WMPL in non-Wikisource related fields and also in some
> Wikisource-related fields.
>
> Ankry
> W dniu 13.11.2021 o 20:12, Asaf Bartov pisze:
>
> Thank you for starting the report, Ankry!
>
> I think it should be clear what the user group is claiming as an
> activity.  For instance, was the usergroup involved in the creation of the
> Balinese and Javanese Wikisource projects, mentioned under "Milestones"?
> If so, the report should explain how the group was involved; if it is just
> a mention of a milestone for Wikisource (as distinct from a milestone for
> the Wikisource Community User Group), it should be clearly separated from
> the main section of the report, which should be devoted to activities and
> communications of the WCUG.
>
> Likewise, was the user group involved in planning or organizing the events
> mentioned? If so, it should be stated explicitly.  (And if the involvement
> was only that a member of the user group presented at the event, then
> *that* should be stated explicitly (e.g. "WCUG member X presented a session
> on Y at event Z"), avoiding the impression the event itself is
> [co-]organized by the user group.)
>
> Cheers,
>
> A.
>
> Asaf Bartov (he/him/his)
>
> Senior Program Officer, Emerging Wikimedia Communities
>
> Wikimedia Foundation 
>
> Imagine a world in which every single human being can freely share in the
> sum of all knowledge. Help us make it a reality!
> https://donate.wikimedia.org
>
>
> On Sat, Nov 13, 2021 at 7:11 PM Satdeep Gill 
> wrote:
>
>> Here is the link to the report:
>>
>>
>> https://meta.wikimedia.org/wiki/Wikisource_Community_User_Group/2021_Report
>>
>>
>> Best
>> Satdeep
>>
>> On Sat, Nov 13, 2021, 7:57 PM Ankry  wrote:
>>
>>> Hi everyone,
>>>
>>> As we are close to the end of this year, I started preparing the 2021
>>> WCUG annual report. Formally, it is due end of November.
>>>
>>> If anyone participated or organized some Wikisource events, please add
>>> appropriate sections.
>>>
>>> Cheers,
>>>Ankry
>>> ___
>>> Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org
>>> To unsubscribe send an email to wikisource-l-le...@lists.wikimedia.org
>>>
>> ___
>> Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org
>> To unsubscribe send an email to wikisource-l-le...@lists.wikimedia.org
>>
>
> ___
> Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org
> To unsubscribe send an email to wikisource-l-le...@lists.wikimedia.org
>
> ___
> Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org
> To unsubscribe send an email to wikisource-l-le...@lists.wikimedia.org
>
___
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org
To unsubscribe send an email to wikisource-l-le...@lists.wikimedia.org

[Wikisource-l] Re: MediaWiki, Wikisource extensions, and new implementations deployment

[Federico Leva (Nemo)]

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
___
Wikisource-l mailing list -- wikisource-l@lists.wikimedia.org
To unsubscribe send an email to wikisource-l-le...@lists.wikimedia.org