text:
School Board President Runs 'All Ages' Sex Toy Shop
Conservative Parenting Culture Education
The trend of so-called "transgender children" continues to escalate, and public schools—and public-school teachers—are at the forefront of the indoctrination and propaganda war.
For example, Young America's Foundation (YAF) recently reported that an anonymous tip to their Campus Bias Tip Line revealed that a first-grade teacher in the Bellingham School District of Washington read her 6-year-old students a transgender children's book (yes, there are dozens of them now) titled I Am Jazz, the story of a "trans child" who eventually pursues transition.
The book is replete with lines such as: "I have a girl brain but a boy body. This is called transgender. I was born this way!" Children too young to read are being introduced to the idea that their bodies can—and even should—be modified based on the way they feel. This is being done without the permission of mothers and fathers.
Outraged parents emailed Jennifer Miller, the teacher; she responded by saying that the book is "available in our school library as part of our Equity, Diversity, and Inclusion collection." Complaints to the school board were also ignored – and a bit of digging by YAF revealed that the president of the board, Jennifer Mason, owns and runs an "all-ages" sex toy shop called the "Wink Wink Boutique" and describes herself in her Instagram profile (which helpfully includes her preferred pronouns) as "Head Dildo."
Mason's store has previously hosted workshops titled "Strap-on Sex," "Fat-Positive Sex," "Anal Play 101," and some that are too vulgar to be published here.
The Wink Wink Boutique's profile describes the shop as "inclusive, all-ages" and "not creepy," serving anyone over the age of 16 – but allows people of any age in the store. Mason, who has served on the board since 2017, appears unsympathetic to parental concerns. Local elections – for school board trustees and other positions – have become increasingly important as schools are colonized by the LGBT movement and concepts parents have never heard of are introduced to small children. Read more…
Half of Transsexuals in Prison Are Already Sex Offenders
"Reproductive Rights" Includes Vaccines, Right? Nope.
brettafarley January 14, 2022
brettafarley November 23, 2021 November 23, 2021
Watch: Hero Mayor Exposes Schoolboard Disseminating Child Pornography
brettafarley September 16, 2021 September 16, 2021


Eight new Art Trams are making tracks in Melbourne this year as part of the Melbourne International Arts Festival's visual arts program.
This year's Art Trams feature new designs from Victorian artists Oslo Davis, Nick Howson, Stephen Baker, Oli Ruskidd, Troy Innocent, Hayley Millar-Baker and Valerie Tang, plus a recreation of work by the late David Larwill.
The mobile public art will be moving through Melbourne's streets until early 2019. Track down your favourites using the TramTracker app – tap myTRAM and enter the tram ID to find it on the network.
Commissioned for a W-Class tram in 1986, this bold work by David Larwill (1956—2011)'s work was photographed and recreated for this year's festival.
Drawing on intergenerational narratives of Aboriginal experiences, Millar-Baker's design explores connection to Country, land, flora and fauna.
Painter and printmaker Howson's design depicts the tram as a container of people, full of characters from all walks of life, who travel the city landscape together.
Street artist and muralist Ruskidd uses bright colour with organic swirling patterns to create abstract creatures and hidden entities within his playful, psychedelic work.
Innocent's geometric imagery is interactive and reveals another layer of animation and sound when the passing tram is viewed using an augmented reality app.
Davis's design celebrates swimming and connects the idea of a sea of people moving through the city with the image of swimmers moving through water.
Year 9 student Tang's design reflects Melbourne's rich multiculturalism and the faces, colours and life we all bring as individuals to the community.
Artist and muralist Baker's design is a geometric portrait of Melbourne with figurative elements representing people contributing their unique shape to the city's mosaic.


The ever-popular non-diamond version of the Tissot Generosi-T. Features a white mother of pearl dial, except this model does not have diamonds. A great value alternative.
This watch is absolutely great! It looks fantastic-the right mixture of simple elegance and perfect design! You can wear it during the day but it also looks wonderful with an evening dress.
Order arrived in a timely fashion. Partner very happy with product and the watch isn't too big as i was scared of. Very happy and would order from Watch Shop again.
My wife absolutely loves the watch and has had plenty of compliments - so a great result. Plus if you add in the price, speed of delivery and the range i had to choose from - an excellent customer service experience.
great watch, can be worn anytime, does.nt look big and bulky like some watches, would recomend to any one.
I liked the watch and was glad I bought it from the Watch Shop.
The price was very competitive and was quickly delivered.


Well, today I actually did something! I helped out my aunt and uncle by mowing their yard, something they apparently needed done for some time. But, the grass is now short, and ready to... grow... againg, then be cut... again... Why oh why do people have grass?
Tomorrow will be some picture taking, and clearing of my soon to be half way to almost half complete room. Wednesday it'll be vacuumed, and a bed placed in it. After that, sometime I'll need to get the oil out, and oil the floor, and also plaster the walls... lots to do, lots (ish) time to do it. At least, not so little time it needs to be rushed.


text:
100$ million dollars and still obsolete
Wikimedia Foundation Board of...
Wikimedia Foundation Board...
Galder Gonzalez Larrañaga
Dear all, Today I learned that, despite having $100 million in the Endowment fund, we can't have a design team big enough to make our websites not look like they're stuck in 2001. I don't know if anyone is behind the wheel, but the car is expensive. Sincerely, Galder
attachment.htm (text/html — 925 bytes)
14 Oct 14 Oct
Hi Galder, Have you ever seen Vector skin version 2? See: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements, You can adopt new versions from your preferences. Some wikis like French Wikipedia, Bangala Wikipedia, etc., already aptoted this new version for their default interface. Regards, Jay Prakash, Volunteer Developer, Wikimedia Community On Fri, Oct 15, 2021 at 12:04 AM Galder Gonzalez Larrañaga < galder158(a)hotmail.com> wrote:
Dear all, Today I learned that, despite having $100 million in the Endowment fund, we can't have a design team big enough to make our websites not look like they're stuck in 2001. I don't know if anyone is behind the wheel, but the car is expensive. Sincerely, Galder _______________________________________________ Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
Yes. That's why. ________________________________ From: Jay prakash <0freerunning(a)gmail.com> Sent: Thursday, October 14, 2021 8:42 PM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete Hi Galder, Have you ever seen Vector skin version 2? See: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements, You can adopt new versions from your preferences. Some wikis like French Wikipedia, Bangala Wikipedia, etc., already aptoted this new version for their default interface. Regards, Jay Prakash, Volunteer Developer, Wikimedia Community On Fri, Oct 15, 2021 at 12:04 AM Galder Gonzalez Larrañaga <galder158@hotmail.com<mailto:galder158@hotmail.com>> wrote: Dear all, Today I learned that, despite having $100 million in the Endowment fund, we can't have a design team big enough to make our websites not look like they're stuck in 2001. I don't know if anyone is behind the wheel, but the car is expensive. Sincerely, Galder _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org<mailto:wikimedia-l-leave@lists.wikimedia.org>
Tito Dutta
Indeed, the lack or modernisation of the web interface, and lack of an improved Android/iPhone (or simply "smartphone") editing app[1] are possibly some of the major areas to focus. If the "next billion internet users", a term we often used to use are not getting involved as much as we expected, possibly "interface" is one reason behind it. [1] I am aware of the currently available apps. শুক্র, 15 অক্টো., 2021 12:03 AM তারিখে Galder Gonzalez Larrañaga < galder158(a)hotmail.com> লিখেছেন:
Hi, I think design is a subjective term. It depends on person-to-person preferences. So there will always be a big room for improvement. WMF's Readers web team is already working to improve the design. They did research and implemented new designs. We should always cooperate with them by giving feedback so that more improvement can take place. Currently, this team has 14 team members and consists of 3 UX Designer/Engineers. So saying that they are not big enough is not good. Please keep in mind that a big team is not always a good idea. [1][2] [1] https://www.forbes.com/sites/jacobmorgan/2015/04/15/why-smaller-teams-are-b… [2] https://blog.prototypr.io/small-team-vs-large-staff-1f921b69d0cf Jay Prakash On Fri, Oct 15, 2021 at 12:27 AM Tito Dutta <trulytito(a)gmail.com> wrote:
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
Thanks Jay for your insights. I just had a meeting with some of the team members. If they can't develop a modern and useful design in a reasonable time lapse, then the team is underfunded. Having a big team is not always better, having a team big enough to work on something it should be solved a decade ago should. If design is subjective, then we don't need any design. Design is not subjective, as aesthetics aren't. There are tons of things published about good designs and bad designs. There are tons of things we could do but we aren't doing because we don't hire people to do it. But we have 100 million dollars, that would be great saved in a vault, instead of making our project better, so we can raise 300 million dollars because more people is coming to share more knowledge in more ways for more people. ________________________________ From: Jay prakash <0freerunning(a)gmail.com> Sent: Thursday, October 14, 2021 9:18 PM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete Hi, I think design is a subjective term. It depends on person-to-person preferences. So there will always be a big room for improvement. WMF's Readers web team is already working to improve the design. They did research and implemented new designs. We should always cooperate with them by giving feedback so that more improvement can take place. Currently, this team has 14 team members and consists of 3 UX Designer/Engineers. So saying that they are not big enough is not good. Please keep in mind that a big team is not always a good idea. [1][2] [1] https://www.forbes.com/sites/jacobmorgan/2015/04/15/why-smaller-teams-are-b… [2] https://blog.prototypr.io/small-team-vs-large-staff-1f921b69d0cf Jay Prakash On Fri, Oct 15, 2021 at 12:27 AM Tito Dutta <trulytito@gmail.com<mailto:trulytito@gmail.com>> wrote: Indeed, the lack or modernisation of the web interface, and lack of an improved Android/iPhone (or simply "smartphone") editing app[1] are possibly some of the major areas to focus. If the "next billion internet users", a term we often used to use are not getting involved as much as we expected, possibly "interface" is one reason behind it. [1] I am aware of the currently available apps. শুক্র, 15 অক্টো., 2021 12:03 AM তারিখে Galder Gonzalez Larrañaga <galder158@hotmail.com<mailto:galder158@hotmail.com>> লিখেছেন: Dear all, Today I learned that, despite having $100 million in the Endowment fund, we can't have a design team big enough to make our websites not look like they're stuck in 2001. I don't know if anyone is behind the wheel, but the car is expensive. Sincerely, Galder _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org<mailto:wikimedia-l-leave@lists.wikimedia.org> _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org<mailto:wikimedia-l-leave@lists.wikimedia.org>
Yes, that's it. Vector was obsolete when it was deployed. New Vector would be obsolete even when Vector was created. It is 2021 and we still can't edit by mobile phone. It is 2021 and most of the tools outside the biggest Wikipedias are broken. It is 2021 and the Vector redesign doesn't take into account that coordinates are a thing. But yes, we do have 100.000.000$ so we can see how Internet was back in the 1990s also in the future. ________________________________ From: Tito Dutta <trulytito(a)gmail.com> Sent: Thursday, October 14, 2021 8:56 PM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete Indeed, the lack or modernisation of the web interface, and lack of an improved Android/iPhone (or simply "smartphone") editing app[1] are possibly some of the major areas to focus. If the "next billion internet users", a term we often used to use are not getting involved as much as we expected, possibly "interface" is one reason behind it. [1] I am aware of the currently available apps. শুক্র, 15 অক্টো., 2021 12:03 AM তারিখে Galder Gonzalez Larrañaga <galder158@hotmail.com<mailto:galder158@hotmail.com>> লিখেছেন: Dear all, Today I learned that, despite having $100 million in the Endowment fund, we can't have a design team big enough to make our websites not look like they're stuck in 2001. I don't know if anyone is behind the wheel, but the car is expensive. Sincerely, Galder _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org<mailto:wikimedia-l-leave@lists.wikimedia.org>
Mike Peel
Could be worse. We could still be using static, hand-written content, to create our webpages, rather than drawing information from a structured database, highlighting related/nearby content, etc. Thanks, Mike On 14/10/21 19:56:56, Tito Dutta wrote: > Indeed, the lack or modernisation of the web interface, and lack of an > improved Android/iPhone (or simply "smartphone") editing app[1] are > possibly some of the major areas to focus. > If the "next billion internet users", a term we often used to use are > not getting involved as much as we expected, possibly "interface" is one > reason behind it. > > [1] I am aware of the currently available apps. > > শুক্র, 15 অক্টো., 2021 12:03 AM তারিখে Galder Gonzalez Larrañaga > <galder158(a)hotmail.com <mailto:galder158@hotmail.com>> লিখেছেন: > > Dear all, > Today I learned that, despite having $100 million in the Endowment > fund, we can't have a design team big enough to make our websites > not look like they're stuck in 2001. I don't know if anyone is > behind the wheel, but the car is expensive. > > Sincerely, > Galder > > _______________________________________________ > Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org > <mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > <https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines> and > https://meta.wikimedia.org/wiki/Wikimedia-l > <https://meta.wikimedia.org/wiki/Wikimedia-l> > Public archives at > https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… > <https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/NJUPLU2TDWLM5N5JFKQSODNCIIUW6ON7/> > To unsubscribe send an email to > wikimedia-l-leave(a)lists.wikimedia.org > <mailto:wikimedia-l-leave@lists.wikimedia.org> > > > _______________________________________________ > Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l > Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… > To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org >
On Thu, 14 Oct 2021 at 19:57, Tito Dutta <trulytito(a)gmail.com> wrote:
Indeed, the lack or modernisation of the web interface, and lack of an improved Android/iPhone (or simply "smartphone") editing app[1] are possibly some of the major areas to focus. If the "next billion internet users", a term we often used to use are not getting involved as much as we expected, possibly "interface" is one reason behind it. [1] I am aware of the currently available apps.
2021 design trends are about lraving large amounts of space for ads while using dark patturns to get the user to give up as much privacy as possible. They are almost entirely aimed at phone and tablet users (too many of the desktop scum have ad blockers these days) who interact through a touch screen. A website designed around letting users get things done using a mouse and keyboard is going to look very different yes. -- geni
It's not an issue of "WMF can't hire enough designers" or "WMF can't hire good designers". I worked for WMF in a design-adjacent role for the better part of a decade. WMF has *excellent *designers, and in sufficient numbers to build a modern user interface on desktop--one that *looks* modern and also prioritizes the needs of Wikipedia's readers (editors can always load up an old skin if they don't like the new one). The mobile site and Wikipedia apps have a much more modern look-and-feel and are clearly focused on making Wikipedia "work" for its largest set of users: readers. If the desktop site lags on the design side, that may be because when WMF has tried to make UI changes to the desktop site in the past, or even just proposed them, they've received loud and angry push back from members of a second (smaller, but equally important) set of users: editors. WMF, understandably, tries to avoid angering editors (believe it or not). At the software company I work for now, if we make a change that annoys our users--pretty much all of whom are "power users" with needs every bit as complex and idiosyncratic as your average Admin--we hear about it. But no one threatens to disable that change across the platform. And it's relatively rare for a user to accuse us of being stupid or lazy or malicious--at least, its rare on for that to happen on public mailing lists or in our own forums. That doesn't mean the stakes are any lower: if we make the software worse, we probably lose customers. But we have the autonomy to make the changes in the first place, see what happens, and then build from there or fix our mistakes or even roll things back if we need to. WMF product teams work in an environment where their competence and good faith are frequently, and publicly, called into question. An environment where one set of end users (editors) has a great deal of both *soft* and *hard* power to block changes, even when those changes are intended for--and indeed, primarily affect--a different set of end users (readers). Speaking as someone who worked inside of that environment, I can say that it can feel like even targeted, clearly motivated and well-justified changes aimed at improving the reader experience aren't worth the cost. There are plenty of other factors at play, but I'm sure I've already said enough to anger plenty of you, so I'll leave it there. I no longer work for WMF and my opinions are my own. Cheers, Jonathan Morgan User:Jtmorgan formerly, User:Jmorgan_(WMF) On Thu, Oct 14, 2021 at 11:34 AM Galder Gonzalez Larrañaga < galder158(a)hotmail.com> wrote:
Jonathan's comment made me smile. To be honest, it's something that crossed my mind too. I mean...the Wikipedia community can have endless arguments about the use of the Oxford comma. We are masters at arguing over what colour the bikeshed should be. There are definitely times where developer actions have caused sufficient harm that the Wikimedia community is up in arms; this is not an organization where "move fast and break things" works very well. Unfortunately, those relatively rare occurrences are what people remember all the time. We don't remember that these same teams have worked out systems so that we no longer have a situation where every time an upgrade is loaded, it breaks the big projects. We don't remember that multiple-hour-long downtimes were commonplace. We don't remember that, in fact, a very significant amount of editing is done on the mobile site. (There used to be a report about that but I've no idea where to find it now.) It's the human condition to remember situations that have made us unhappy or even angry, while situations that have little obvious impact are completely forgotten. Bottom line, the developers have made tens of thousands of improvements to the site that rarely, if ever, get noted or even recognized. We only remember the times when they've done something that really caused problems. A lot of the challenges that are faced by designers and developers have to do with inconsistent or narrow feedback from the editorial community, not to mention diametrically opposed requests to change the same thing in different ways. It's one thing to say that X is really awful. It's another thing to work with a cross-section of the community (i.e. hundreds of people, if not thousands across several projects) to figure out what improvements to X should look like, and gain consensus on those desired improvements. For every person who complains about X being awful, there are often an equal or greater number of people saying "don't touch X! I rely on it being exactly as it is!" It's important and valuable to start these discussions, but let's not start off with "this group isn't doing its job the way I think they should". Let's start with "how can I influence the community to identify what needs to be improved, and get agreements that the developers can count on in order to proceed." And yes, I know full well how very hard this is, for everyone involved. It's not a criticism of anyone participating in this thread. Risker/Anne On Thu, 14 Oct 2021 at 17:35, Jonathan Morgan <jonnymorgan.esq(a)gmail.com> wrote:
Heather Walls
I was going to write something similar to Jonathan, but now I can just support what he said. If there are folks in the communities who desire changes to the sites, building a group of supporters and/or becoming invested in what it is really like to make those changes *socially* not technically, is likely to be more effective than pointing at WMF and saying they are not interested, not capable, or not resourced enough. Thanks, Jmo! On Thu, Oct 14, 2021 at 2:35 PM Jonathan Morgan <jonnymorgan.esq(a)gmail.com> wrote:
Dear all, I don't know if this already has a name, but I'm going to invent one: The Great Circle of Excuse. It works like this: we have all realized that something needs to be improved, let's say the design of our website. Then, WMF gets a group of workers to think about it, and they come up with some changes that neither respond to the needs nor are really a change beyond certain aesthetic resources. It is always mentioned (excuse 1) that these changes have been measured externally (and, coincidentally, reinforce the design made) and (excuse 2) that there are people who do not want any change, so it is better not to be radical and make a patch that, in reality, we all know that it does not solve anything. Then a previous design is presented to the community and a lot of comments are collected. As the design is only partial (look, this is what the Moon article is going to look like https://people.wikimedia.org/~jdrewniak/dip/#/en/wiki/Moon), and does not respond to all the other sections we have (home page, search pages, categories, menus...), you receive feedback that can be categorized into two main groups: the small group A tells you not to change anything. The big group B tells you that it doesn't even scratch the surface of the necessary changes (https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Prototype_t…). You have a few outsiders who tell you: "well, this is better than nothing". At that point you decide that you have to weigh group A with group B, so your design is right in the middle of the will of the community, and you go ahead without making the slightest change. Excuse 3 is set up: I heard the community and I'm weighing everyone's wishes. In reality, you only listen to your design and those outsiders who have told you it's better than nothing. The majority will continue to see that this is going nowhere and a minority will continue to be angry that you have made changes when they don't think you should have. After excuse 3, it's time to implement. You decide that this has to be done in a very long process, where you measure the impact of every little change, without taking into account that every little change break something that was already working. So, you have trivial changes that break things, covered by excuse 4: we are measuring the impact. Even if the impact contradicts your assumption, the change will still be there (https://phabricator.wikimedia.org/T285755). Because, hey, who cares (excuse 4.1). At this point, some members of the community decide to open issues in Phabricator. We reach the peak of excuse making. If something was working and now it can't be: we broke it on purpose by design (excuse 5.1 https://phabricator.wikimedia.org/T290480), nobody was using that functionality (excuse 5.2 https://phabricator.wikimedia.org/T287609), that problem you mention is invalid, so your proposal is not even considered (excuse 5.3: https://phabricator.wikimedia.org/T289212) or that thing you ask for is out of our scope of work (excuse 5.4 https://phabricator.wikimedia.org/T292617 or https://phabricator.wikimedia.org/T293405...). There is a more complex version, let's call it excuse 5.1-4) where you ask for something in Phabricator, you are told to mention it on the MediaWiki discussion page, you get no answer there, you go back to Phabricator, and then one of the above four excuses is triggered. At this point in the circle, there is some volunteer who wants to fix this and raises the tone of the request. Then we find the mother of all excuses, the wild card: you are being rude and do not assume good faith. Excuse 6. At this point a new figure appears: the direct meeting with the team that is developing this. The team wants to listen to you. Actually, it's the opposite: they want you to listen to the new excuses that exist in the circle. You go through excuses 3, 4 and 5 with them. As excuse 6 can no longer be used, because you are there volunteering your time to try to improve something, excuse 7 appears: we can't take on these changes because our team is small and we can't make the logical changes you are suggesting for another 2 or 3 years. Maybe. If there are funds. So the user who has gone through excuses 1, 2, 3, 4, 5x, 6 and 7 decides to write an email to the mailing list where the community will see that the problem is 7: there is not a big enough team to undertake something that we have decided in our strategic discussion. In fact, we are going in the opposite direction of the strategic goals. But we have money. A lot of it. A lot of money. We are sitting on mountains of money. We could simply hire people so that we can improve our system so much that it works perfectly for another decade and then, with minimal investment in staff, get a lot more money from people who like our service a lot more than they did before. But no, instead we get excuse 8: there are actually enough staff, but those poor staff can't do what they should do, poor staff, because the community doesn't want change (excuse 2) and the environment is toxic (excuse 6). Or, as a variant: a bigger team may not be better (despite the team says that they can't do it because their team is small). So, once the circle is closed, you go back to opening issues in Phabricator to try to improve these problems. Because it only takes one manager, someone who knows how to manage a team, to realize that there is a problem here. And what do you find in Phabricator if you reopen issues? Surprise, you get back to box 5, in its variants a, b, c or d. The circle is closed. No one is responsible for anything. No one can solve it. In the meantime, we have 100 million dollars, a flawed website, a make-up process that leads nowhere, whole communities with basic things broken for months and no prospect of improvement for the people who, in good faith, try to help along the way. We lose readers. We lose volunteers. We lose time. We lose money. We lose everyone. Thanks Galder ________________________________ From: Heather Walls <heather.ariana.walls(a)gmail.com> Sent: Friday, October 15, 2021 12:01 AM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete I was going to write something similar to Jonathan, but now I can just support what he said. If there are folks in the communities who desire changes to the sites, building a group of supporters and/or becoming invested in what it is really like to make those changes *socially* not technically, is likely to be more effective than pointing at WMF and saying they are not interested, not capable, or not resourced enough. Thanks, Jmo! On Thu, Oct 14, 2021 at 2:35 PM Jonathan Morgan <jonnymorgan.esq@gmail.com<mailto:jonnymorgan.esq@gmail.com>> wrote: It's not an issue of "WMF can't hire enough designers" or "WMF can't hire good designers". I worked for WMF in a design-adjacent role for the better part of a decade. WMF has excellent designers, and in sufficient numbers to build a modern user interface on desktop--one that looks modern and also prioritizes the needs of Wikipedia's readers (editors can always load up an old skin if they don't like the new one). The mobile site and Wikipedia apps have a much more modern look-and-feel and are clearly focused on making Wikipedia "work" for its largest set of users: readers. If the desktop site lags on the design side, that may be because when WMF has tried to make UI changes to the desktop site in the past, or even just proposed them, they've received loud and angry push back from members of a second (smaller, but equally important) set of users: editors. WMF, understandably, tries to avoid angering editors (believe it or not). At the software company I work for now, if we make a change that annoys our users--pretty much all of whom are "power users" with needs every bit as complex and idiosyncratic as your average Admin--we hear about it. But no one threatens to disable that change across the platform. And it's relatively rare for a user to accuse us of being stupid or lazy or malicious--at least, its rare on for that to happen on public mailing lists or in our own forums. That doesn't mean the stakes are any lower: if we make the software worse, we probably lose customers. But we have the autonomy to make the changes in the first place, see what happens, and then build from there or fix our mistakes or even roll things back if we need to. WMF product teams work in an environment where their competence and good faith are frequently, and publicly, called into question. An environment where one set of end users (editors) has a great deal of both soft and hard power to block changes, even when those changes are intended for--and indeed, primarily affect--a different set of end users (readers). Speaking as someone who worked inside of that environment, I can say that it can feel like even targeted, clearly motivated and well-justified changes aimed at improving the reader experience aren't worth the cost. There are plenty of other factors at play, but I'm sure I've already said enough to anger plenty of you, so I'll leave it there. I no longer work for WMF and my opinions are my own. Cheers, Jonathan Morgan User:Jtmorgan formerly, User:Jmorgan_(WMF) On Thu, Oct 14, 2021 at 11:34 AM Galder Gonzalez Larrañaga <galder158@hotmail.com<mailto:galder158@hotmail.com>> wrote: Dear all, Today I learned that, despite having $100 million in the Endowment fund, we can't have a design team big enough to make our websites not look like they're stuck in 2001. I don't know if anyone is behind the wheel, but the car is expensive. Sincerely, Galder _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org<mailto:wikimedia-l-leave@lists.wikimedia.org> _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org<mailto:wikimedia-l-leave@lists.wikimedia.org>
Dan Garry (Deskana)
On Fri, 15 Oct 2021 at 08:47, Galder Gonzalez Larrañaga < galder158(a)hotmail.com> wrote:
Dear all, I don't know if this already has a name, but I'm going to invent one: The Great Circle of Excuse. It works like this: we have all realized that something needs to be improved, let's say the design of our website. Then, WMF gets a group of workers to think about it, and they come up with some changes that neither respond to the needs nor are really a change beyond certain aesthetic resources.
I stopped reading at this point. What you've written here is pretty insulting. There's a valid point buried under your rhetoric, but you're exacerbating the problem by being so rude and dismissive. Dan
Thanks Dan for using the Excuse 6: At this point in the circle, there is some volunteer who wants to fix this and raises the tone of the request. Then we find the mother of all excuses, the wild card: you are being rude and do not assume good faith. Excuse 6. ________________________________ From: Dan Garry (Deskana) <djgwiki(a)gmail.com> Sent: Friday, October 15, 2021 11:58 AM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete On Fri, 15 Oct 2021 at 08:47, Galder Gonzalez Larrañaga <galder158@hotmail.com<mailto:galder158@hotmail.com>> wrote: Dear all, I don't know if this already has a name, but I'm going to invent one: The Great Circle of Excuse. It works like this: we have all realized that something needs to be improved, let's say the design of our website. Then, WMF gets a group of workers to think about it, and they come up with some changes that neither respond to the needs nor are really a change beyond certain aesthetic resources. I stopped reading at this point. What you've written here is pretty insulting. There's a valid point buried under your rhetoric, but you're exacerbating the problem by being so rude and dismissive. Dan
Thanks Dan for using the Excuse 6: *At this point in the circle, there is some volunteer who wants to fix this and raises the tone of the request. Then we find the mother of all excuses, the wild card: you are being rude and do not assume good faith. Excuse 6.*
I guess you've got all the answers then, eh? I think we're done here. Dan
No, I don't have all the answers. Is just that every time someone says: "hey! this is broken!" and receives an excuse and then says again "HEY! THIS IS BROKEN!" the answer is not: "ok, we'll try to figure out how to solve it" but: "don't use caps". I'm a volunteer. I have spent lots of time trying to solve issues. Most of this time wasn't about the issue, was about someone trying to convince me that the bug was a feature. And now, when I tell here where "I THINK" that the problem is, I get a "you are being rude" excuse. Great. I'm being rude. Now, can we fix the problem? Thanks Galder ________________________________ From: Dan Garry (Deskana) <djgwiki(a)gmail.com> Sent: Friday, October 15, 2021 12:08 PM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete On Fri, 15 Oct 2021 at 11:03, Galder Gonzalez Larrañaga <galder158@hotmail.com<mailto:galder158@hotmail.com>> wrote: Thanks Dan for using the Excuse 6: At this point in the circle, there is some volunteer who wants to fix this and raises the tone of the request. Then we find the mother of all excuses, the wild card: you are being rude and do not assume good faith. Excuse 6. I guess you've got all the answers then, eh? I think we're done here. Dan
Eduardo Testart
Hi all, A good example around this subject was the Visual Editor tool implementation, strongly opposed by the community in the beginning, and developed by the WMF, as it was probably necessary to turn Wikipedia into a more modern website. A lot about the latter can be found and read as a real example of this debate The cultural behavior of the group is a big factor on any technological implementation on the Wikimedia world, and to change culture, you need much more than money. Sorry if this was mentioned before. Cheers, El vie., 15 de oct. de 2021 07:13, Galder Gonzalez Larrañaga < galder158(a)hotmail.com> escribió:
No, I don't have all the answers. Is just that every time someone says: "hey! this is broken!" and receives an excuse and then says again "HEY! THIS IS BROKEN!" the answer is not: "ok, we'll try to figure out how to solve it" but: "don't use caps". I'm a volunteer. I have spent lots of time trying to solve issues. Most of this time wasn't about the issue, was about someone trying to convince me that the bug was a feature. And now, when I tell here where "I THINK" that the problem is, I get a "you are being rude" excuse. Great. I'm being rude. Now, can we fix the problem? Thanks Galder ------------------------------ *From:* Dan Garry (Deskana) <djgwiki(a)gmail.com> *Sent:* Friday, October 15, 2021 12:08 PM *To:* Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> *Subject:* [Wikimedia-l] Re: 100$ million dollars and still obsolete On Fri, 15 Oct 2021 at 11:03, Galder Gonzalez Larrañaga < galder158(a)hotmail.com> wrote: Thanks Dan for using the Excuse 6: *At this point in the circle, there is some volunteer who wants to fix this and raises the tone of the request. Then we find the mother of all excuses, the wild card: you are being rude and do not assume good faith. Excuse 6.* I guess you've got all the answers then, eh? I think we're done here. Dan _______________________________________________ Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
Vi to
Regular contributors experience is quite different from less frequent contributors and (above all) readers. People into user interfaces design surely have a proper word for this, but we're used to a variety of small tricks/habits which are somehow expensive to change. For example, since OOUI's developed I've been upset because it seems to need some more keystrokes for blocks and deletions. I, for one, am still using monobook, and I won't change it unless forced. Introducing visual editor implied a cost for the communities to fix garbage wikicode introduced by VE during its first weeks/months, some years later, linterrors became the best game for our bots. So I can confirm the inertia of regular editors about user interface is, usually, humongous, but also the project themselves have an enormous inertia since they are collections of terabytes of wikicode created during almost two decades. I feel like this problem has never been addressed in a wide, strategic, way, leaving developers being torn apart by conflicting needs. Vito Il giorno ven 15 ott 2021 alle ore 19:11 Eduardo Testart <etestart(a)gmail.com> ha scritto:
Thanks Vito and Samuel for your words, As a leader of an Education Program, I talk every day to students, people who was born after Wikipedia and have assumed during all their life that Wikipedia exists. They are digital natives, but, for the good or for the bad, they are used to having everything deployed, working and simple. They are used to Google Drive and its collaboration platforms; they are used to just buying some new device and having the operative system there. They haven't dealt with installing their own OS, making separate drives for data and OS or just having folders in their desktop to save things. I have been with more than 6.000 students in the last 4 years (https://outreachdashboard.wmflabs.org/campaigns/hezkuntza_programa/programs 4.147 accounts created) and they are shocked with the obsolescence of our platform. They don't understand why they can't write simultaneously, why they can't upload videos, or why there's not autosave. I'm with them every day, so I hear what they think about the design, the usability. They make the same mistakes once and again, so I'm starting to think that those are not mistakes, but software/UX errors. Our system was obsolete 10 years ago. Whenever we fix something, we are a decade late. The new vector will be, too, a decade late. And every change we aren't doing is losing new contributors. Old wikimedians will eventually leave the project, because they can't contribute, because they have lost their enthusiasm or just because they die. If we want to have a whole new generation of wikimedians editing, then things must be thought for them, making everything easier, appealing and aligned with the way they have to contribute. Desktop computers are disappearing. We still can't edit in a good way with our mobile phones. We have a whole strategy thought for the 2030, but we aren't making any real usability step in that direction. We have still some time left. And we have the most important thing: a mountain of money. Let's invest in the best way we can: attracting a new generation of Wikimedians who will push our projects to new heights and will make that little investment of money multiply for the future. Galder PD: Samuel, yes, of course, I use tropes, stylistic recourses and metaphors. I'm trying to tell something! 😉 ________________________________ From: Vi to <vituzzu.wiki(a)gmail.com> Sent: Friday, October 15, 2021 9:07 PM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete Regular contributors experience is quite different from less frequent contributors and (above all) readers. People into user interfaces design surely have a proper word for this, but we're used to a variety of small tricks/habits which are somehow expensive to change. For example, since OOUI's developed I've been upset because it seems to need some more keystrokes for blocks and deletions. I, for one, am still using monobook, and I won't change it unless forced. Introducing visual editor implied a cost for the communities to fix garbage wikicode introduced by VE during its first weeks/months, some years later, linterrors became the best game for our bots. So I can confirm the inertia of regular editors about user interface is, usually, humongous, but also the project themselves have an enormous inertia since they are collections of terabytes of wikicode created during almost two decades. I feel like this problem has never been addressed in a wide, strategic, way, leaving developers being torn apart by conflicting needs. Vito Il giorno ven 15 ott 2021 alle ore 19:11 Eduardo Testart <etestart@gmail.com<mailto:etestart@gmail.com>> ha scritto: Hi all, A good example around this subject was the Visual Editor tool implementation, strongly opposed by the community in the beginning, and developed by the WMF, as it was probably necessary to turn Wikipedia into a more modern website. A lot about the latter can be found and read as a real example of this debate The cultural behavior of the group is a big factor on any technological implementation on the Wikimedia world, and to change culture, you need much more than money. Sorry if this was mentioned before. Cheers, El vie., 15 de oct. de 2021 07:13, Galder Gonzalez Larrañaga <galder158@hotmail.com<mailto:galder158@hotmail.com>> escribió: No, I don't have all the answers. Is just that every time someone says: "hey! this is broken!" and receives an excuse and then says again "HEY! THIS IS BROKEN!" the answer is not: "ok, we'll try to figure out how to solve it" but: "don't use caps". I'm a volunteer. I have spent lots of time trying to solve issues. Most of this time wasn't about the issue, was about someone trying to convince me that the bug was a feature. And now, when I tell here where "I THINK" that the problem is, I get a "you are being rude" excuse. Great. I'm being rude. Now, can we fix the problem? Thanks Galder ________________________________ From: Dan Garry (Deskana) <djgwiki@gmail.com<mailto:djgwiki@gmail.com>> Sent: Friday, October 15, 2021 12:08 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete On Fri, 15 Oct 2021 at 11:03, Galder Gonzalez Larrañaga <galder158@hotmail.com<mailto:galder158@hotmail.com>> wrote: Thanks Dan for using the Excuse 6: At this point in the circle, there is some volunteer who wants to fix this and raises the tone of the request. Then we find the mother of all excuses, the wild card: you are being rude and do not assume good faith. Excuse 6. I guess you've got all the answers then, eh? I think we're done here. Dan _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org<mailto:wikimedia-l-leave@lists.wikimedia.org> _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org<mailto:wikimedia-l-leave@lists.wikimedia.org>
I can say that this thread inspired me to turn off the "legacy" button for Vector and see what's new. I thought that was bad, but Vito uses monobook! Two things to acknowledge: * We've heard many times over the years that the technical teams see their primary customer as the readers. Good or bad, we recognize that pleasing the readers does not require maintaining a highly modern editing interface. At the same time, editors remain fairly "sticky" - they don't leave in big numbers because of the interface, and they broadly prefer a slow pace of change. Together the result is a very slow and incremental pace of development progress for editor UX. * Most of us recognize that persuasion is the most effective way to create change. Being right is inadequate on its own. But sometimes persuasion fails and we remain convinced we are right. This creates frustration, even anger; it may look like someone fails to understand the value of making friends and influencing people, but it can simply be that other strategies have been exhausted and lighting a big fire is what remains. Nathan
Luis Villa
On Fri, Oct 15, 2021 at 3:34 AM Dan Garry (Deskana) <djgwiki(a)gmail.com> wrote:
I stopped reading at this point. What you've written here is pretty insulting. There's a valid point buried under your rhetoric, but you're exacerbating the problem by being so rude and dismissive.
You misspelled "exemplifying the problem", Dan! :) It's exactly this sort of "no, no, everything you've done is wrong" that is what Jonathan Morgan was talking about. And then a followup *within a minute* to blame someone, again. It is worth noting that it's a bunch of *ex-*employees who are piping up here; current employees know they can't weigh in without their competence, ethics, integrity, motives, etc. being questioned, which makes it even harder to do the rest of their already hard jobs, so they have good reason to mostly stay quiet. Jonathan, Heather, Dan and I are speaking up in part because we've walked a mile in these shoes and... it sucks. Big hugs to both the current team and to the diaspora. Miss you all. (For what it is worth, I think the current mobile app is pretty good and I regularly finding pleasant surprises, like the iOS picture-of-the-day widget, which brightens my every day with free content/knowledge. I do have many nitpicks and wishlist items, and of course always wish things moved faster, but I think it's pretty unfair to say (*especially* on mobile) that nothing has improved.) Luis
Samuel Klein
Luis writes:
For what it is worth, I think the current mobile app is pretty good and I
regularly finding pleasant surprises Yea, the mobile app is sweet, editing and all. Responding to two specific earlier comments: 1. *Galder* - "It is 2021 and we still can't edit by mobile phone." --> Safe to say this is not true :) But you could say that about your later comment on the ability to "*write simultaneously ... upload videos ...** autosave*", each of which are common in online collaborative spaces, and which we do need to make standard for our wikis. But the bottlenecks aren't primarily design, but rather coordinated vision and focus -- or at least unblocking and supporting one another as we design and implement prototypes. We need new social norms and clear community use cases for simultaneous editing <https://bluespice.com/mediawiki-visualeditor/> (resolving attribution and revision history for multiparty edits), video uploading <https://www.mediawiki.org/wiki/Extension:TimedMediaHandler> (how to note the original upload if we only save a transcode), and drafts <https://phabricator.wikimedia.org/T39992> (rallying support behind a specific client-side use case to realize). 2.* Jonathan* - "[In my new sw company] we have the autonomy to make the changes in the first place, see what happens, and then build from there..." "WMF product teams work in an environment where [...] one set of end users (editors) has a great deal of both *soft* and *hard* power to block changes, even when those changes are intended for--and indeed, primarily affect--a different set of end users (readers)." --> These comments highlight a common misframing, about autonomy and curation of the reading experience, worth addressing. (Likely deserves its own thread!) Much of the friction and tension in our movement stems from different understandings of autonomy; and the impedance mismatch <https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch> of a step function between the norms (of communication, delegation, and planning) of a) broad community wikiocracies and b) narrow staff hierarchies. Our community has thousands of designers; the staff has scores, who may feel constrained to work on only their particular projects. There is abundant talent. Most active editors and curators are not "end users" of the site, any more than developers are -- they are involved before the end, up and down the design and implementation stack, building bridges, interfaces, translations. They are project stewards, schedulers, templaters, designers, and maintainers. So when interface designers deploying a new language-selector design are talking with layout designers maintaining article flair like geo-coordinates <https://en.wikipedia.org/wiki/Wikipedia:How_to_add_geocodes_to_articles> and article status indicators <https://www.mediawiki.org/wiki/Help:Page_status_indicators>, they should feel they are on the same team: improving the site skin together. This is a solved problem in some corners, but the solutions are not evenly distributed. Within Wikimedia, and within the WMF, there are groups and projects of all sizes that have developed without this sort of contention. But we spend most of our time and energy talking about the ones that fail to do so. [*The article always ends on the wrong version <https://meta.wikimedia.org/wiki/The_Wrong_Version>; confusion is always due to the other person* :-] Let's learn from the successes, and not fall into stereotyping any parts of our nexus. Wishing all a beautiful week's end, SJ
True Samuel. We can actually edit [Wikipedia] from our mobile phones. We can't use the visual editor. I tried to say it later with the sentence "Desktop computers are disappearing. We still can't edit in a good way with our mobile phones." but it's true the first time I mentionen this it was not factual. About the other projects, it doesn't matter where the bottleneck is: we are obsolete and we have 100 million dollars. We try to make some improvements using a wishlist system that only creates culture of scarcity, instead of culture of abundance. There is a reason to create scarcity, but this is a topic for another essay. Have a good weekend Galder ________________________________ From: Samuel Klein <meta.sj(a)gmail.com> Sent: Saturday, October 16, 2021 3:07 AM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete Luis writes:
For what it is worth, I think the current mobile app is pretty good and I regularly finding pleasant surprises
Yea, the mobile app is sweet, editing and all. Responding to two specific earlier comments: 1. Galder - "It is 2021 and we still can't edit by mobile phone." --> Safe to say this is not true :) But you could say that about your later comment on the ability to "write simultaneously ... upload videos ... autosave", each of which are common in online collaborative spaces, and which we do need to make standard for our wikis. But the bottlenecks aren't primarily design, but rather coordinated vision and focus -- or at least unblocking and supporting one another as we design and implement prototypes. We need new social norms and clear community use cases for simultaneous editing<https://bluespice.com/mediawiki-visualeditor/> (resolving attribution and revision history for multiparty edits), video uploading<https://www.mediawiki.org/wiki/Extension:TimedMediaHandler> (how to note the original upload if we only save a transcode), and drafts<https://phabricator.wikimedia.org/T39992> (rallying support behind a specific client-side use case to realize). 2. Jonathan - "[In my new sw company] we have the autonomy to make the changes in the first place, see what happens, and then build from there..." "WMF product teams work in an environment where [...] one set of end users (editors) has a great deal of both soft and hard power to block changes, even when those changes are intended for--and indeed, primarily affect--a different set of end users (readers)." --> These comments highlight a common misframing, about autonomy and curation of the reading experience, worth addressing. (Likely deserves its own thread!) Much of the friction and tension in our movement stems from different understandings of autonomy; and the impedance mismatch<https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedan… of a step function between the norms (of communication, delegation, and planning) of a) broad community wikiocracies and b) narrow staff hierarchies. Our community has thousands of designers; the staff has scores, who may feel constrained to work on only their particular projects. There is abundant talent. Most active editors and curators are not "end users" of the site, any more than developers are -- they are involved before the end, up and down the design and implementation stack, building bridges, interfaces, translations. They are project stewards, schedulers, templaters, designers, and maintainers. So when interface designers deploying a new language-selector design are talking with layout designers maintaining article flair like geo-coordinates<https://en.wikipedia.org/wiki/Wikipedia:How_to_add_geoco… and article status indicators<https://www.mediawiki.org/wiki/Help:Page_status_indicators>rs>, they should feel they are on the same team: improving the site skin together. This is a solved problem in some corners, but the solutions are not evenly distributed. Within Wikimedia, and within the WMF, there are groups and projects of all sizes that have developed without this sort of contention. But we spend most of our time and energy talking about the ones that fail to do so. [The article always ends on the wrong version<https://meta.wikimedia.org/wiki/The_Wrong_Version>on>; confusion is always due to the other person :-] Let's learn from the successes, and not fall into stereotyping any parts of our nexus. Wishing all a beautiful week's end, SJ
Christophe Henner
Hi, I will the whole first part of the discussion :) As for the product discussion. We should very mindful of what we consider our ProductS. We tend to talk a lot about the wikis. They are products that can be improved, and have been and still should evolve yes. And I agree it would be great if they improved more, be updated for both readers and editors. But the context, with so many communities to satisfy makes it very hard. Be damned if you do, be damned if you don't sort of things. But, they are not obsolete. What however is, to me, obsolete is our shared very occidental web vision of our products. What can makes us obsolete, is our inability to adapt our products or create new products adapted to new mean of content consumption. From a content consumption perspective, video and audio have a lot of tractions. Short and fast burst of information is taking more and more place on how we consume content. The disintermediation of content is more than here and even if we have Wikidata, we are not, yet!, exploiting it's full potential to spread content. VR and AR are 5 to 10 years away as mass market products. But it will requires years to do something good for us around it. Yes editing can be improved, but to me it is not where we will see obsolescence first. Content consumption is clearly to me the topic. I know it can be easy to say "hey look at simultaneous editing on gdoc or 365". Yes that's a nice thing, but would it be a game changer for us? But having all around the world PoP to decrease loading time also is a great product improvement. Etc. All that to say, yes there is a lot of work from a product perspective, but it can be easy to have our own biases give us a twisted view of what needs to be improved. And if you read the whole thread it is not really about money but more about product vision/strategy/roadmap :) Which we might be missing or isn't known enough. Le sam. 16 oct. 2021 à 8:41 AM, Galder Gonzalez Larrañaga < galder158(a)hotmail.com> a écrit :
True Samuel. We can actually edit [Wikipedia] from our mobile phones. We can't use the visual editor. I tried to say it later with the sentence "Desktop computers are disappearing. We still can't edit in a good way with our mobile phones." but it's true the first time I mentionen this it was not factual. About the other projects, it doesn't matter where the bottleneck is: we are obsolete and we have 100 million dollars. We try to make some improvements using a wishlist system that only creates culture of scarcity, instead of culture of abundance. There is a reason to create scarcity, but this is a topic for another essay. Have a good weekend Galder ------------------------------ *From:* Samuel Klein <meta.sj(a)gmail.com> *Sent:* Saturday, October 16, 2021 3:07 AM *To:* Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> *Subject:* [Wikimedia-l] Re: 100$ million dollars and still obsolete Luis writes:
For what it is worth, I think the current mobile app is pretty good and
I regularly finding pleasant surprises Yea, the mobile app is sweet, editing and all. Responding to two specific earlier comments: 1. *Galder* - "It is 2021 and we still can't edit by mobile phone." --> Safe to say this is not true :) But you could say that about your later comment on the ability to "*write simultaneously ... upload videos ...** autosave*", each of which are common in online collaborative spaces, and which we do need to make standard for our wikis. But the bottlenecks aren't primarily design, but rather coordinated vision and focus -- or at least unblocking and supporting one another as we design and implement prototypes. We need new social norms and clear community use cases for simultaneous editing <https://bluespice.com/mediawiki-visualeditor/> (resolving attribution and revision history for multiparty edits), video uploading <https://www.mediawiki.org/wiki/Extension:TimedMediaHandler> (how to note the original upload if we only save a transcode), and drafts <https://phabricator.wikimedia.org/T39992> (rallying support behind a specific client-side use case to realize). 2.* Jonathan* - "[In my new sw company] we have the autonomy to make the changes in the first place, see what happens, and then build from there..." "WMF product teams work in an environment where [...] one set of end users (editors) has a great deal of both *soft* and *hard* power to block changes, even when those changes are intended for--and indeed, primarily affect--a different set of end users (readers)." --> These comments highlight a common misframing, about autonomy and curation of the reading experience, worth addressing. (Likely deserves its own thread!) Much of the friction and tension in our movement stems from different understandings of autonomy; and the impedance mismatch <https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch> of a step function between the norms (of communication, delegation, and planning) of a) broad community wikiocracies and b) narrow staff hierarchies. Our community has thousands of designers; the staff has scores, who may feel constrained to work on only their particular projects. There is abundant talent. Most active editors and curators are not "end users" of the site, any more than developers are -- they are involved before the end, up and down the design and implementation stack, building bridges, interfaces, translations. They are project stewards, schedulers, templaters, designers, and maintainers. So when interface designers deploying a new language-selector design are talking with layout designers maintaining article flair like geo-coordinates <https://en.wikipedia.org/wiki/Wikipedia:How_to_add_geocodes_to_articles> and article status indicators <https://www.mediawiki.org/wiki/Help:Page_status_indicators>, they should feel they are on the same team: improving the site skin together. This is a solved problem in some corners, but the solutions are not evenly distributed. Within Wikimedia, and within the WMF, there are groups and projects of all sizes that have developed without this sort of contention. But we spend most of our time and energy talking about the ones that fail to do so. [*The article always ends on the wrong version <https://meta.wikimedia.org/wiki/The_Wrong_Version>; confusion is always due to the other person* :-] Let's learn from the successes, and not fall into stereotyping any parts of our nexus. Wishing all a beautiful week's end, SJ _______________________________________________ Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
Thanks Christophe, And whose responsibility is to answer to "And if you read the whole thread it is not really about money but more about product vision/strategy/roadmap :)"? Who should have this strategy, vision and roadmap? That's the x in this equation. Galder ________________________________ From: Christophe Henner <christophe.henner(a)gmail.com> Sent: Saturday, October 16, 2021 9:33 AM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete Hi, I will the whole first part of the discussion :) As for the product discussion. We should very mindful of what we consider our ProductS. We tend to talk a lot about the wikis. They are products that can be improved, and have been and still should evolve yes. And I agree it would be great if they improved more, be updated for both readers and editors. But the context, with so many communities to satisfy makes it very hard. Be damned if you do, be damned if you don't sort of things. But, they are not obsolete. What however is, to me, obsolete is our shared very occidental web vision of our products. What can makes us obsolete, is our inability to adapt our products or create new products adapted to new mean of content consumption. From a content consumption perspective, video and audio have a lot of tractions. Short and fast burst of information is taking more and more place on how we consume content. The disintermediation of content is more than here and even if we have Wikidata, we are not, yet!, exploiting it's full potential to spread content. VR and AR are 5 to 10 years away as mass market products. But it will requires years to do something good for us around it. Yes editing can be improved, but to me it is not where we will see obsolescence first. Content consumption is clearly to me the topic. I know it can be easy to say "hey look at simultaneous editing on gdoc or 365". Yes that's a nice thing, but would it be a game changer for us? But having all around the world PoP to decrease loading time also is a great product improvement. Etc. All that to say, yes there is a lot of work from a product perspective, but it can be easy to have our own biases give us a twisted view of what needs to be improved. And if you read the whole thread it is not really about money but more about product vision/strategy/roadmap :) Which we might be missing or isn't known enough. Le sam. 16 oct. 2021 à 8:41 AM, Galder Gonzalez Larrañaga <galder158@hotmail.com<mailto:galder158@hotmail.com>> a écrit : True Samuel. We can actually edit [Wikipedia] from our mobile phones. We can't use the visual editor. I tried to say it later with the sentence "Desktop computers are disappearing. We still can't edit in a good way with our mobile phones." but it's true the first time I mentionen this it was not factual. About the other projects, it doesn't matter where the bottleneck is: we are obsolete and we have 100 million dollars. We try to make some improvements using a wishlist system that only creates culture of scarcity, instead of culture of abundance. There is a reason to create scarcity, but this is a topic for another essay. Have a good weekend Galder ________________________________ From: Samuel Klein <meta.sj@gmail.com<mailto:meta.sj@gmail.com>> Sent: Saturday, October 16, 2021 3:07 AM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete Luis writes:
Yea, the mobile app is sweet, editing and all. Responding to two specific earlier comments: 1. Galder - "It is 2021 and we still can't edit by mobile phone." --> Safe to say this is not true :) But you could say that about your later comment on the ability to "write simultaneously ... upload videos ... autosave", each of which are common in online collaborative spaces, and which we do need to make standard for our wikis. But the bottlenecks aren't primarily design, but rather coordinated vision and focus -- or at least unblocking and supporting one another as we design and implement prototypes. We need new social norms and clear community use cases for simultaneous editing<https://bluespice.com/mediawiki-visualeditor/> (resolving attribution and revision history for multiparty edits), video uploading<https://www.mediawiki.org/wiki/Extension:TimedMediaHandler> (how to note the original upload if we only save a transcode), and drafts<https://phabricator.wikimedia.org/T39992> (rallying support behind a specific client-side use case to realize). 2. Jonathan - "[In my new sw company] we have the autonomy to make the changes in the first place, see what happens, and then build from there..." "WMF product teams work in an environment where [...] one set of end users (editors) has a great deal of both soft and hard power to block changes, even when those changes are intended for--and indeed, primarily affect--a different set of end users (readers)." --> These comments highlight a common misframing, about autonomy and curation of the reading experience, worth addressing. (Likely deserves its own thread!) Much of the friction and tension in our movement stems from different understandings of autonomy; and the impedance mismatch<https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedan… of a step function between the norms (of communication, delegation, and planning) of a) broad community wikiocracies and b) narrow staff hierarchies. Our community has thousands of designers; the staff has scores, who may feel constrained to work on only their particular projects. There is abundant talent. Most active editors and curators are not "end users" of the site, any more than developers are -- they are involved before the end, up and down the design and implementation stack, building bridges, interfaces, translations. They are project stewards, schedulers, templaters, designers, and maintainers. So when interface designers deploying a new language-selector design are talking with layout designers maintaining article flair like geo-coordinates<https://en.wikipedia.org/wiki/Wikipedia:How_to_add_geoco… and article status indicators<https://www.mediawiki.org/wiki/Help:Page_status_indicators>rs>, they should feel they are on the same team: improving the site skin together. This is a solved problem in some corners, but the solutions are not evenly distributed. Within Wikimedia, and within the WMF, there are groups and projects of all sizes that have developed without this sort of contention. But we spend most of our time and energy talking about the ones that fail to do so. [The article always ends on the wrong version<https://meta.wikimedia.org/wiki/The_Wrong_Version>on>; confusion is always due to the other person :-] Let's learn from the successes, and not fall into stereotyping any parts of our nexus. Wishing all a beautiful week's end, SJ _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org<mailto:wikimedia-l@lists.wikimedia.org>, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org<mailto:wikimedia-l-leave@lists.wikimedia.org>
Strainu
Galder, I want to start by saying that I totally understand your frustration. I have encountered the Great circle of excuses many times and especially no 6 was used to break many good discussions when they became difficult for the staff. There was a time when I honestly felt the engineers at the WMF were grossly overpaid for what they delivered. But things have changed. Communication about new projects has never been this good and there are a lot of projects going around from both wmf and wmde. Yes, things are not 100% smooth and I believe no one agrees with all the different changes happening, but we have to keep a cool head and understand that we (community+staff) need to work at planet scale and try to keep a balance between all users, regardless of background or age. Christophe has nailed the high-level problems IMHO, and to answer your question, we are all responsible for the strategy. I'm not just throwing buzz words around: each community knows its readership and has at least some intuition into what makes it happy. This can be evolved by asking for support from the research team and then trying to implement them or bring them to the WMF road map. This last step is the most difficult, but things like the community wishlist or project grants are some of the tools at our disposal to make our wishes happen. Of course, engaging and/or challenging the WMF also might work. I would personally like to see an office hour with the C-level person in charge of product (I don't even know who that is anymore) where such high-level issues could be brought to the table. Specifically, for the looks issue, not all the wikis need to look the same. Some stuck with monobook for a number of years, other are using the Timeless skin. If the current team is not implementing your wishes, why not look for other ways to improve at least your home wiki? Have a great weekend, Strainu Pe sâmbătă, 16 octombrie 2021, Galder Gonzalez Larrañaga < galder158(a)hotmail.com> a scris:
Thanks Christophe, And whose responsibility is to answer to "And if you read the whole
thread it is not really about money but more about product vision/strategy/roadmap :)"? Who should have this strategy, vision and roadmap?
That's the x in this equation. Galder ________________________________ From: Christophe Henner <christophe.henner(a)gmail.com> Sent: Saturday, October 16, 2021 9:33 AM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete Hi, I will the whole first part of the discussion :) As for the product discussion. We should very mindful of what we consider
We tend to talk a lot about the wikis. They are products that can be
improved, and have been and still should evolve yes. And I agree it would be great if they improved more, be updated for both readers and editors. But the context, with so many communities to satisfy makes it very hard.
Be damned if you do, be damned if you don't sort of things. But, they are not obsolete. What however is, to me, obsolete is our shared very occidental web vision
of our products.
What can makes us obsolete, is our inability to adapt our products or
create new products adapted to new mean of content consumption.
From a content consumption perspective, video and audio have a lot of
tractions.
Short and fast burst of information is taking more and more place on how
we consume content.
The disintermediation of content is more than here and even if we have
Wikidata, we are not, yet!, exploiting it's full potential to spread content.
VR and AR are 5 to 10 years away as mass market products. But it will
requires years to do something good for us around it.
Yes editing can be improved, but to me it is not where we will see
obsolescence first. Content consumption is clearly to me the topic.
I know it can be easy to say "hey look at simultaneous editing on gdoc or
365". Yes that's a nice thing, but would it be a game changer for us? But having all around the world PoP to decrease loading time also is a great product improvement. Etc.
All that to say, yes there is a lot of work from a product perspective,
but it can be easy to have our own biases give us a twisted view of what needs to be improved.
And if you read the whole thread it is not really about money but more
about product vision/strategy/roadmap :)
Which we might be missing or isn't known enough. Le sam. 16 oct. 2021 à 8:41 AM, Galder Gonzalez Larrañaga <
galder158(a)hotmail.com> a écrit :
True Samuel. We can actually edit [Wikipedia] from our mobile phones. We
can't use the visual editor. I tried to say it later with the sentence "Desktop computers are disappearing. We still can't edit in a good way with our mobile phones." but it's true the first time I mentionen this it was not factual.
About the other projects, it doesn't matter where the bottleneck is: we
are obsolete and we have 100 million dollars. We try to make some improvements using a wishlist system that only creates culture of scarcity, instead of culture of abundance. There is a reason to create scarcity, but this is a topic for another essay.
Have a good weekend Galder ________________________________ From: Samuel Klein <meta.sj(a)gmail.com> Sent: Saturday, October 16, 2021 3:07 AM To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete Luis writes: > For what it is worth, I think the current mobile app is pretty good and
I regularly finding pleasant surprises
Yea, the mobile app is sweet, editing and all. Responding to two specific earlier comments: 1. Galder - "It is 2021 and we still can't edit by mobile phone." --> Safe to say this is not true :) But you could say that about your
later comment on the ability to "write simultaneously ... upload videos ... autosave", each of which are common in online collaborative spaces, and which we do need to make standard for our wikis. But the bottlenecks aren't primarily design, but rather coordinated vision and focus -- or at least unblocking and supporting one another as we design and implement prototypes. We need new social norms and clear community use cases for simultaneous editing (resolving attribution and revision history for multiparty edits), video uploading (how to note the original upload if we only save a transcode), and drafts (rallying support behind a specific client-side use case to realize).
2. Jonathan - "[In my new sw company] we have the autonomy to make the changes in
the first place, see what happens, and then build from there..."
"WMF product teams work in an environment where [...] one set of end
users (editors) has a great deal of both soft and hard power to block changes, even when those changes are intended for--and indeed, primarily affect--a different set of end users (readers)."
--> These comments highlight a common misframing, about autonomy and
curation of the reading experience, worth addressing. (Likely deserves its own thread!)
Much of the friction and tension in our movement stems from different
understandings of autonomy; and the impedance mismatch of a step function between the norms (of communication, delegation, and planning) of a) broad community wikiocracies and b) narrow staff hierarchies. Our community has thousands of designers; the staff has scores, who may feel constrained to work on only their particular projects. There is abundant talent.
Most active editors and curators are not "end users" of the site, any
more than developers are -- they are involved before the end, up and down the design and implementation stack, building bridges, interfaces, translations. They are project stewards, schedulers, templaters, designers, and maintainers. So when interface designers deploying a new language-selector design are talking with layout designers maintaining article flair like geo-coordinates and article status indicators, they should feel they are on the same team: improving the site skin together.
This is a solved problem in some corners, but the solutions are not
evenly distributed. Within Wikimedia, and within the WMF, there are groups and projects of all sizes that have developed without this sort of contention. But we spend most of our time and energy talking about the ones that fail to do so. [The article always ends on the wrong version; confusion is always due to the other person :-] Let's learn from the successes, and not fall into stereotyping any parts of our nexus.
Wishing all a beautiful week's end, SJ _______________________________________________ Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines
at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
Yaroslav Blanter
Yes, absolutely. In a few years, there will be tools for editing video. If by that time we are not ready to incorporate video at full scale to Wikimedia projects, we will be where AOL is now. Best Yaroslav On Sat, Oct 16, 2021 at 9:34 AM Christophe Henner < christophe.henner(a)gmail.com> wrote:
For what it is worth, I think the current mobile app is pretty good
and I regularly finding pleasant surprises Yea, the mobile app is sweet, editing and all. Responding to two specific earlier comments: 1. *Galder* - "It is 2021 and we still can't edit by mobile phone." --> Safe to say this is not true :) But you could say that about your later comment on the ability to "*write simultaneously ... upload videos ...** autosave*", each of which are common in online collaborative spaces, and which we do need to make standard for our wikis. But the bottlenecks aren't primarily design, but rather coordinated vision and focus -- or at least unblocking and supporting one another as we design and implement prototypes. We need new social norms and clear community use cases for simultaneous editing <https://bluespice.com/mediawiki-visualeditor/> (resolving attribution and revision history for multiparty edits), video uploading <https://www.mediawiki.org/wiki/Extension:TimedMediaHandler> (how to note the original upload if we only save a transcode), and drafts <https://phabricator.wikimedia.org/T39992> (rallying support behind a specific client-side use case to realize). 2.* Jonathan* - "[In my new sw company] we have the autonomy to make the changes in the first place, see what happens, and then build from there..." "WMF product teams work in an environment where [...] one set of end users (editors) has a great deal of both *soft* and *hard* power to block changes, even when those changes are intended for--and indeed, primarily affect--a different set of end users (readers)." --> These comments highlight a common misframing, about autonomy and curation of the reading experience, worth addressing. (Likely deserves its own thread!) Much of the friction and tension in our movement stems from different understandings of autonomy; and the impedance mismatch <https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch> of a step function between the norms (of communication, delegation, and planning) of a) broad community wikiocracies and b) narrow staff hierarchies. Our community has thousands of designers; the staff has scores, who may feel constrained to work on only their particular projects. There is abundant talent. Most active editors and curators are not "end users" of the site, any more than developers are -- they are involved before the end, up and down the design and implementation stack, building bridges, interfaces, translations. They are project stewards, schedulers, templaters, designers, and maintainers. So when interface designers deploying a new language-selector design are talking with layout designers maintaining article flair like geo-coordinates <https://en.wikipedia.org/wiki/Wikipedia:How_to_add_geocodes_to_articles> and article status indicators <https://www.mediawiki.org/wiki/Help:Page_status_indicators>, they should feel they are on the same team: improving the site skin together. This is a solved problem in some corners, but the solutions are not evenly distributed. Within Wikimedia, and within the WMF, there are groups and projects of all sizes that have developed without this sort of contention. But we spend most of our time and energy talking about the ones that fail to do so. [*The article always ends on the wrong version <https://meta.wikimedia.org/wiki/The_Wrong_Version>; confusion is always due to the other person* :-] Let's learn from the successes, and not fall into stereotyping any parts of our nexus. Wishing all a beautiful week's end, SJ _______________________________________________ Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
Juergen Fenn
Am 16.10.21 um 16:25 Uhr schrieb Yaroslav Blanter:
In a few years, there will be tools for editing video. If by that time we are not ready to incorporate video at full scale to Wikimedia projects, we will be where AOL is now.
We already _are_ there. When we tried to relaunch German Wikiversity almost ten years ago we sadly had to shrug and decline offers to bring converted classroom scenarios to Wikiversity because Commons did not accept mp4 videos and we could not include frames from YouTube where it all happens. Period. That was the end of online learning with Wikimedia. (Fair enough, there were more reasons why we did not succeed.) BUT: When we incorporate multimedia content at full scale it should be clear that Wikimedia is NOT YouTube. We won't accept everything. We need high qualitity educational content. Only. Regards, Jürgen.
Amir Sarabadani
Well, if we need to have better support for multimedia, first we need to give some attention to the existing system that is basically falling apart. Let me give you some examples. Thumbor, the software that builds small sizes of the images is on deprecated infrastructure, on EOL python version (python2), uses an extremely old fork of the upstream and does not have an owner. And this is a pretty critical software, if it goes down, virtually no image can be shown in all of Wikipedia (including all SVG files). Because of that, we can't move it to a newer infrastructure (kubernetes), make it use a more modern python version or upstream code, to make it use a more modern version of svg converter to fix countless svg bugs the current system has [1]. It in itself is blocking adding more features on all of Wikipedia. For example, as a certified science nerd, I want to add support for chemical markup files (.bxr, etc.) that would enrich our chemistry articles [2] but well, it's blocked on thumbor being unmaintained. The old video player, kultura, is still in production and used quite heavily. The replacement media player exists but has some bugs that are rather easy to fix and unblock further rolling out. But because no one is on this task, it's basically a group of volunteers (including yours truly) struggling to find the time to work on it. [3]. It would give a slightly more modern look to our media player. This is mostly fixed but worth mentioning, the image table in commons was bigger than 300GB compressed (and 600GB uncompressed), it would take 15 hours to take a simple backup and basically a ticking bomb given how heavily it is used. Commons went readonly and caused a big outage so technically it was a bomb that exploded already once. The problem was metadata of pdf files and djvu files were massive, the pdf files got fixed by Tim Starling and I (I did it in my volunteer capacity) which in turn reduced 200GB from it. And now we are working on fixing djvu. [4] Again in volunteer capacity. This work is actually blocking redesign of the image table to make it more useful [5] or practically any change that would impact size of tables in commons. The problems have passed the point of blocking improvements and adding more features, they are reaching the point of actually bringing down our systems and bleeding to the rest of our systems. And it all boils down to not having a dedicated team on multimedia but in all fairness, it's not something you can fix overnight. You need to grow, hire, plan, etc. etc. Best [1] https://phabricator.wikimedia.org/T193352#5984544 [2] https://phabricator.wikimedia.org/T18491 [3] https://phabricator.wikimedia.org/T248418 [4] https://phabricator.wikimedia.org/T275268 [5] https://phabricator.wikimedia.org/T28741 On Sun, Oct 17, 2021 at 1:08 PM Juergen Fenn <jfenn(a)gmx.net> wrote:
We already _are_ there. When we tried to relaunch German Wikiversity almost ten years ago we sadly had to shrug and decline offers to bring converted classroom scenarios to Wikiversity because Commons did not accept mp4 videos and we could not include frames from YouTube where it all happens. Period. That was the end of online learning with Wikimedia. (Fair enough, there were more reasons why we did not succeed.) BUT: When we incorporate multimedia content at full scale it should be clear that Wikimedia is NOT YouTube. We won't accept everything. We need high qualitity educational content. Only. Regards, Jürgen. _______________________________________________ Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
-- Amir (he/him)
Hi Amir, thanks for this detailed analysis. What do you think should be done? Is there any role for volunteers who are not developers and do not write code? Best Yaroslav On Sun, Oct 17, 2021 at 2:11 PM Amir Sarabadani <ladsgroup(a)gmail.com> wrote:
-- Amir (he/him) _______________________________________________ Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
Thanks Galder for the provocative thread and Jonathan for your reflections (in this thread and in issues elsewhere, past and present). Galder -- I'm thinking about how to refactor your observations to make them less personal, more general, easier to work with. This issue and these patterns are not specific to {design | the foundation | a developer/user feedback loop}, but the example you raise makes it tangible. Design is often an area that amplifies them - there's a reason that *barn-raising* and *shed-painting* are analogies for very different human tendencies... You might call this class of interactions *feedback tropes* – like fiction tropes <https://allthetropes.org/wiki/Main_Page>, there are thousands of common ones, not just a handful. They are mostly not "excuses" [other than what you numbered 5.x]. Many tropes which you mention but did not number ("don't change anything", "better than nothing [don't take forever]", "this doesn't even scratch the surface [so why bother]", "what have you done for us lately", "you are bad at this") are part of their own cycle. Naming more of these tropes might help defuse tension and avoid spiralling – most tropes have known and relatively straightforward resolutions. I can also see how these two cycles can amplify one another, though it doesn't need to be that way. For instance, in the thoughtfully detailed Phab tickets you linked, where both you and others participating feel fed up for different reasons. SJ
wikimedia-l@lists.wikimedia.org
participants (19)

redpajama_set_name: RedPajamaCommonCrawl


text:
Diese Liste beinhaltet alle in der Wikipedia gelisteten Wappen des Rems-Murr-Kreises in Baden-Württemberg, inklusive historischer Wappen. Fast alle Städte, Gemeinden und Kreise in Baden-Württemberg führen ein Wappen. Sie sind über die Navigationsleiste am Ende der Seite erreichbar.

Rems-Murr-Kreis

Städtewappen im Rems-Murr-Kreis

Gemeindewappen im Rems-Murr-Kreis

Ehemalige Landkreiswappen

Ehemalige Gemeindewappen

Blasonierungen

Literatur
 Heinz Bardua: Kreis- und Gemeindewappen in Baden-Württemberg. Band 1: Die Kreis- und Gemeindewappen im Regierungsbezirk Stuttgart. Landesarchivdirektion Baden-Württemberg (Hrsg.), Konrad Theiss Verlag, Stuttgart 1987, 158 Seiten, ISBN 3-8062-0801-8.

 Klemens Stadler: Deutsche Wappen. Band VIII: Baden-Württemberg. Mit Zeichnungen von Max Reinhart. Angelsachsen-Verlag, Bremen 1971.
 Heinz Bardua: Was der Kreis und seine Gemeinden im Schilde führen. Kommunale Wappen im Rems-Murr-Kreis. In: An Rems und Murr. 10 (1983) 19, S. 69–81.
 Eberhard Gönner und Heinz Bardua: Wappenbuch des Landkreises Waiblingen. Veröffentlichungen der Staatlichen Archivverwaltung Baden-Württemberg, Heft 24. Stuttgart 1970.

!
Remsmurrkreis
Wappen Remsmurrkreis

redpajama_set_name: RedPajamaWikipedia


The Yahoo! Trip Planner API is called with the query string "Amsterdam" during the initial load and on each subsequent 'next' page. Two Carousels are created to illustrate how to have multiple carousels on the same page, each acting independently.


text:
Justine Damond: Minneapolis police 'heard loud sound' before shooting – BBC News
Media playback is unsupported on your device
A Minneapolis police officer whose partner shot an Australian woman was "startled by a loud sound" just before the incident, investigators say.
Justine Damond, originally from Sydney, was gunned down after calling police to report a possible crime.
On a police radio recording, an officer mentions fireworks being let off near where the shooting happened.
Australian Prime Minister Malcolm Turnbull has said he wants answers from the US over the killing.
"It is a shocking killing, and yes, we are demanding answers on behalf of her family," he told Australian TV.
The shooting occurred as 40-year-old Ms Damond, dressed in her pyjamas, approached the driver's side door to talk to the officer at the wheel after police arrived.
Officer Mohamed Noor, who was sitting in the passenger seat, fired his weapon across his partner and through the driver's side window, striking Ms Damond, the Minnesota Bureau of Criminal Apprehension (BCA) said.
Officer Noor has refused to speak to investigators and US authorities say they cannot compel him to give a statement.
But the BCA said that Officer Matthew Harrity, who was driving the car, had told investigators that Ms Damond had come towards the car immediately after he heard a loud sound.
Shot woman's fiancé wants answers
Death raises questions about camera use
After the shooting, the officers are heard on the police radio recording telling dispatchers they are performing CPR and that "no suspects are at large".
State investigators say the officers failed to activate their body or dashboard cameras and both officers have been placed on administrative leave.
Why weren't the cameras on?
Minneapolis Mayor Betsy Hodges and Hennepin County Attorney Mike Freeman have both raised this question.
Minneapolis police are required to switch on their body cameras only during certain encounters, unlike in Los Angeles or Washington DC, where cameras must be switched on for any response to a call for service.
Instead, there are more than a dozen situations in which cameras should be used, according to the police manual, which adds that failure to use the camera could result in job termination.
"If a BWC [body-worn camera] is not activated prior to a use of force, it shall be activated as soon as it is safe to do so," reads the manual.
Minneapolis Police Chief Janee Harteau has described Ms Damond's death as "tragic" and called for a quick investigation to provide "transparency".
Hennepin County Attorney Mike Freeman has said he will personally decide whether to charge Officer Mohamed Noor, rather than put the question to a grand jury.
Officer Noor, who has been described by local media as a Somali-American, has been with the police force for two years.
A statement from his lawyer said he had arrived in the US "at a young age" and described him as "a caring person with a family he loves and he empathised with the loss others are experiencing".
Ms Damond, born Justine Ruszczyk, studied to be a veterinarian before relocating from Sydney to the US, where she is believed to have been for at least the last three years.
According to her website, she was a "qualified yoga instructor, a personal health and life coach and meditation teacher".
Speaking in Sydney, her father John Ruszczyk said: "Justine was a beacon to all of us, we only ask that the light of justice shine down on the circumstances of her death."
On Wednesday morning, hundreds of people gathered for a dawn vigil at a Sydney beach to honour Ms Damond.
In silence, attendees including her family and friends lit candles and released pink flowers into the ocean.
"We are here to come together as a community around our beautiful Justine, to honour her life, share our love and mourn her death," Ms Damond's family said in a statement ahead of the vigil.
← 'Let Obamacare Fail,' Trump Says as GOP Health Bill Collapses – New York Times
Why can't the Senate repeal Obamacare? Because its policies are actually popular. – Washington Post →