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:
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 <[email protected]
<mailto:[email protected]>> 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 [email protected]
<mailto:[email protected]>
To unsubscribe send an email [email protected]
<mailto:[email protected]>
_______________________________________________
Wikisource-l mailing list [email protected]
<mailto:[email protected]>
To unsubscribe send an email [email protected]
<mailto:[email protected]>
_______________________________________________
Wikisource-l mailing list -- [email protected]
<mailto:[email protected]>
To unsubscribe send an email to
[email protected]
<mailto:[email protected]>
_______________________________________________
Wikisource-l mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Wikisource-l mailing list -- [email protected]
To unsubscribe send an email to [email protected]
