Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved (https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge". We also made some recommendations to improve the User Experience (https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge (https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
* Graph extension is used in thousands of pages, some of them highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution. * Meanwhile, a place like Our World in Data has been publishing data and interactive content with a compatible license for years. (Remember, "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853). * Wolfram Alpha is like a light year ahead us on giving interactive solutions to knowledge questions, even the silliest ones (https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "becoming the essential infrastructure of the ecosystem of free knowledge" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge". * Brilliant (https://brilliant.org/) is brilliant if you want to learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms? * We can build interactive timelines using Wikidata, but we can't embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/http://histropedia.com/ * We could have something very special: inline links in video and audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that. * ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" (https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Hi Galder, I certainly share your sentiment. The world is undoubtedly moving at such a speed that other sites have invested millions to make the experience better. But ours has millions as well, and those of us who edit on a day-to-day basis still have the worst internet experience when it comes for an example to editing and uploading photos. Not to mention the long and tortuous road to video uploading (Commons has no decent support for this https://commons.wikimedia.org/wiki/Commons:Video), in the midst of the biggest generational shift in video consumption.
There is a phrase in my country that if civil servants were on public transport, we would probably have faster improvements. Will it be the same for us, if we do not have staff who do not face our daily "challenges"?
I don't know.
El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly
relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data
and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to learn
lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Thanks Galder
As mentioned Wiki Project Med is working to improve some of these issues this year, supported by funding from the WMF.
1) We are still trying to get OWID working on Wikipedia. Here is what it looks like on MDWiki https://mdwiki.org/wiki/WikiProjectMed:OWID.
2) We are also working on a CT scan viewer that functions better than this https://mdwiki.org/wiki/Mesenteric_ischemia/CT_image.
3) And are trying to get VideoWiki https://mdwiki.org/wiki/WikiProjectMed:VideoWiki functional again after it died a few years back.
Would love to see MP4s uploadable to Commons. Sure we can auto convert to open formats in the background and hide the MP4s until they are fully open, but this should be done by us and we should not be forcing our editors to use other websites to achieve this.
James
On Tue, Jan 23, 2024 at 10:47 AM Ivan Martínez galaver@gmail.com wrote:
Hi Galder, I certainly share your sentiment. The world is undoubtedly moving at such a speed that other sites have invested millions to make the experience better. But ours has millions as well, and those of us who edit on a day-to-day basis still have the worst internet experience when it comes for an example to editing and uploading photos. Not to mention the long and tortuous road to video uploading (Commons has no decent support for this https://commons.wikimedia.org/wiki/Commons:Video), in the midst of the biggest generational shift in video consumption.
There is a phrase in my country that if civil servants were on public transport, we would probably have faster improvements. Will it be the same for us, if we do not have staff who do not face our daily "challenges"?
I don't know.
El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly
relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data
and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
-- *Iván Martínez*
*Voluntario - Wikimedia México A.C.User:ProtoplasmaKid *
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- 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
Agreed, there is a *lot* we could do if there were resources assigned to interactive media.
-- brion
On Tue, Jan 23, 2024 at 10:29 AM James Heilman jmh649@gmail.com wrote:
Thanks Galder
As mentioned Wiki Project Med is working to improve some of these issues this year, supported by funding from the WMF.
- We are still trying to get OWID working on Wikipedia. Here is what it
looks like on MDWiki https://mdwiki.org/wiki/WikiProjectMed:OWID.
- We are also working on a CT scan viewer that functions better than this
https://mdwiki.org/wiki/Mesenteric_ischemia/CT_image.
- And are trying to get VideoWiki
https://mdwiki.org/wiki/WikiProjectMed:VideoWiki functional again after it died a few years back.
Would love to see MP4s uploadable to Commons. Sure we can auto convert to open formats in the background and hide the MP4s until they are fully open, but this should be done by us and we should not be forcing our editors to use other websites to achieve this.
James
On Tue, Jan 23, 2024 at 10:47 AM Ivan Martínez galaver@gmail.com wrote:
Hi Galder, I certainly share your sentiment. The world is undoubtedly moving at such a speed that other sites have invested millions to make the experience better. But ours has millions as well, and those of us who edit on a day-to-day basis still have the worst internet experience when it comes for an example to editing and uploading photos. Not to mention the long and tortuous road to video uploading (Commons has no decent support for this https://commons.wikimedia.org/wiki/Commons:Video), in the midst of the biggest generational shift in video consumption.
There is a phrase in my country that if civil servants were on public transport, we would probably have faster improvements. Will it be the same for us, if we do not have staff who do not face our daily "challenges"?
I don't know.
El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly
relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data
and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
-- *Iván Martínez*
*Voluntario - Wikimedia México A.C.User:ProtoplasmaKid *
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
(What I *have* been able to do, with the help of volunteers and a little spare time from colleagues, is produce an iOS-compatible HTTP Live Streaming packaging for video transcodes. This gets full-featured video playback working on iPhones that are new enough to decode VP9, though may still have compatibility problems with older phones. There is no funding or ongoing work time assignment for this project beyond conforming initial iOS compatibility.)
-- brion
On Tue, Jan 23, 2024 at 11:08 AM Brion Vibber bvibber@wikimedia.org wrote:
Agreed, there is a *lot* we could do if there were resources assigned to interactive media.
-- brion
On Tue, Jan 23, 2024 at 10:29 AM James Heilman jmh649@gmail.com wrote:
Thanks Galder
As mentioned Wiki Project Med is working to improve some of these issues this year, supported by funding from the WMF.
- We are still trying to get OWID working on Wikipedia. Here is what it
looks like on MDWiki https://mdwiki.org/wiki/WikiProjectMed:OWID.
- We are also working on a CT scan viewer that functions better than
this https://mdwiki.org/wiki/Mesenteric_ischemia/CT_image.
- And are trying to get VideoWiki
https://mdwiki.org/wiki/WikiProjectMed:VideoWiki functional again after it died a few years back.
Would love to see MP4s uploadable to Commons. Sure we can auto convert to open formats in the background and hide the MP4s until they are fully open, but this should be done by us and we should not be forcing our editors to use other websites to achieve this.
James
On Tue, Jan 23, 2024 at 10:47 AM Ivan Martínez galaver@gmail.com wrote:
Hi Galder, I certainly share your sentiment. The world is undoubtedly moving at such a speed that other sites have invested millions to make the experience better. But ours has millions as well, and those of us who edit on a day-to-day basis still have the worst internet experience when it comes for an example to editing and uploading photos. Not to mention the long and tortuous road to video uploading (Commons has no decent support for this https://commons.wikimedia.org/wiki/Commons:Video), in the midst of the biggest generational shift in video consumption.
There is a phrase in my country that if civil servants were on public transport, we would probably have faster improvements. Will it be the same for us, if we do not have staff who do not face our daily "challenges"?
I don't know.
El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them
highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing
data and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
-- *Iván Martínez*
*Voluntario - Wikimedia México A.C.User:ProtoplasmaKid *
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Also, note that Wikimedia can choose to ship h.264 files at any time, just like we use CPUs full of patented technology; not doing so is a choice the Commons community made in 2014 and we could revisit that choice in the light of the fact there's no actual downside of working with h.264 when we're not shipping the codec.
-- brion
On Tue, Jan 23, 2024 at 11:11 AM Brion Vibber bvibber@wikimedia.org wrote:
(What I *have* been able to do, with the help of volunteers and a little spare time from colleagues, is produce an iOS-compatible HTTP Live Streaming packaging for video transcodes. This gets full-featured video playback working on iPhones that are new enough to decode VP9, though may still have compatibility problems with older phones. There is no funding or ongoing work time assignment for this project beyond conforming initial iOS compatibility.)
-- brion
On Tue, Jan 23, 2024 at 11:08 AM Brion Vibber bvibber@wikimedia.org wrote:
Agreed, there is a *lot* we could do if there were resources assigned to interactive media.
-- brion
On Tue, Jan 23, 2024 at 10:29 AM James Heilman jmh649@gmail.com wrote:
Thanks Galder
As mentioned Wiki Project Med is working to improve some of these issues this year, supported by funding from the WMF.
- We are still trying to get OWID working on Wikipedia. Here is what
it looks like on MDWiki https://mdwiki.org/wiki/WikiProjectMed:OWID.
- We are also working on a CT scan viewer that functions better than
this https://mdwiki.org/wiki/Mesenteric_ischemia/CT_image.
- And are trying to get VideoWiki
https://mdwiki.org/wiki/WikiProjectMed:VideoWiki functional again after it died a few years back.
Would love to see MP4s uploadable to Commons. Sure we can auto convert to open formats in the background and hide the MP4s until they are fully open, but this should be done by us and we should not be forcing our editors to use other websites to achieve this.
James
On Tue, Jan 23, 2024 at 10:47 AM Ivan Martínez galaver@gmail.com wrote:
Hi Galder, I certainly share your sentiment. The world is undoubtedly moving at such a speed that other sites have invested millions to make the experience better. But ours has millions as well, and those of us who edit on a day-to-day basis still have the worst internet experience when it comes for an example to editing and uploading photos. Not to mention the long and tortuous road to video uploading (Commons has no decent support for this https://commons.wikimedia.org/wiki/Commons:Video), in the midst of the biggest generational shift in video consumption.
There is a phrase in my country that if civil servants were on public transport, we would probably have faster improvements. Will it be the same for us, if we do not have staff who do not face our daily "challenges"?
I don't know.
El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them
highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing
data and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving
interactive solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
-- *Iván Martínez*
*Voluntario - Wikimedia México A.C.User:ProtoplasmaKid *
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
My recommendations for Wikimedia Foundation on this subject:
1) Overturn the requirement to avoid handling h.264 files on Wikimedia servers or accept them from users or serve them to users. Allow importing h.264 uploads and creating h.264 transcodes for playback compatibility. 2) Create an interactive media team with at least two engineers, a designer, and a project manager 3) Give this team a remit to rebuild *and maintain in an ongoing fashion* the existing TimedMediaHandler, Graphs, Score, 3D, etc extensions 4) Integrate those tools cleanly with mobile apps and social media embedding tools managed by other teams
-- brion
On Tue, Jan 23, 2024 at 11:35 AM Brion Vibber bvibber@wikimedia.org wrote:
Also, note that Wikimedia can choose to ship h.264 files at any time, just like we use CPUs full of patented technology; not doing so is a choice the Commons community made in 2014 and we could revisit that choice in the light of the fact there's no actual downside of working with h.264 when we're not shipping the codec.
-- brion
On Tue, Jan 23, 2024 at 11:11 AM Brion Vibber bvibber@wikimedia.org wrote:
(What I *have* been able to do, with the help of volunteers and a little spare time from colleagues, is produce an iOS-compatible HTTP Live Streaming packaging for video transcodes. This gets full-featured video playback working on iPhones that are new enough to decode VP9, though may still have compatibility problems with older phones. There is no funding or ongoing work time assignment for this project beyond conforming initial iOS compatibility.)
-- brion
On Tue, Jan 23, 2024 at 11:08 AM Brion Vibber bvibber@wikimedia.org wrote:
Agreed, there is a *lot* we could do if there were resources assigned to interactive media.
-- brion
On Tue, Jan 23, 2024 at 10:29 AM James Heilman jmh649@gmail.com wrote:
Thanks Galder
As mentioned Wiki Project Med is working to improve some of these issues this year, supported by funding from the WMF.
- We are still trying to get OWID working on Wikipedia. Here is what
it looks like on MDWiki https://mdwiki.org/wiki/WikiProjectMed:OWID.
- We are also working on a CT scan viewer that functions better than
this https://mdwiki.org/wiki/Mesenteric_ischemia/CT_image.
- And are trying to get VideoWiki
https://mdwiki.org/wiki/WikiProjectMed:VideoWiki functional again after it died a few years back.
Would love to see MP4s uploadable to Commons. Sure we can auto convert to open formats in the background and hide the MP4s until they are fully open, but this should be done by us and we should not be forcing our editors to use other websites to achieve this.
James
On Tue, Jan 23, 2024 at 10:47 AM Ivan Martínez galaver@gmail.com wrote:
Hi Galder, I certainly share your sentiment. The world is undoubtedly moving at such a speed that other sites have invested millions to make the experience better. But ours has millions as well, and those of us who edit on a day-to-day basis still have the worst internet experience when it comes for an example to editing and uploading photos. Not to mention the long and tortuous road to video uploading (Commons has no decent support for this https://commons.wikimedia.org/wiki/Commons:Video), in the midst of the biggest generational shift in video consumption.
There is a phrase in my country that if civil servants were on public transport, we would probably have faster improvements. Will it be the same for us, if we do not have staff who do not face our daily "challenges"?
I don't know.
El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them
highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing
data and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving
interactive solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
-- *Iván Martínez*
*Voluntario - Wikimedia México A.C.User:ProtoplasmaKid *
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
On Tue, Jan 23, 2024 at 11:44 AM Brion Vibber bvibber@wikimedia.org wrote:
- Overturn the requirement to avoid handling h.264 files on Wikimedia servers or
accept them from users or serve them to users. Allow importing h.264 uploads and creating h.264 transcodes for playback compatibility.
The last RFC [1] will reach its 10 year anniversary in February, so I think it would be reasonable to re-engage with the (Wikimedia-wide) community if anything about the current policy should change. Personally, I continue to be in favor of Wikimedia transcoding uploads, as long as WMF doesn't end up paying licensing fees to the video patent monopolists.
What's changed over the last 10 years? Looking at Commons:Video, it currently says:
The preferred video format is VP9 video in the WebM container, but Theora video in the ogv container and VP8 or AV1 video in the WebM container are also allowed.
So at least it looks like there are now new royalty-free formats that are widely supported in browsers, right?
Is there anything that can be done to expand the server-side format support further without changing Wikimedia's stance on patents? For example, should Wikimedia Commons support additional container formats or codecs that are royalty-free or whose patents have expired?
Warmly, Erik
[1] https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/MP4_Video
On Sat, Jan 27, 2024 at 12:57 PM Erik Moeller eloquence@gmail.com wrote:
On Tue, Jan 23, 2024 at 11:44 AM Brion Vibber bvibber@wikimedia.org wrote:
- Overturn the requirement to avoid handling h.264 files on Wikimedia
servers or
accept them from users or serve them to users. Allow importing h.264
uploads
and creating h.264 transcodes for playback compatibility.
The last RFC [1] will reach its 10 year anniversary in February, so I think it would be reasonable to re-engage with the (Wikimedia-wide) community if anything about the current policy should change. Personally, I continue to be in favor of Wikimedia transcoding uploads, as long as WMF doesn't end up paying licensing fees to the video patent monopolists.
*nod*
What's changed over the last 10 years? Looking at Commons:Video, it
currently says:
The preferred video format is VP9 video in the WebM container, but Theora video in the ogv container and VP8 or AV1 video in the WebM container are also allowed.
So at least it looks like there are now new royalty-free formats that are widely supported in browsers, right?
We have playback covered reasonably well and it's getting better because our old "frenemies" at Microsoft and Apple are now pulling their weight for universal compatibility. They are both members of the industry consortium pushing the royalty-free AV1 codec and have both adopted VP9 as its predecessor bridge codec. :)
Allowing us to create MP4 h.264/AAC output in limited resolutions would increase compatibility with older iOS devices and other "funky" browsers, but we don't "need" it for the latest devices.
Reuse is more problematic. If you download our VP9 WebM or MP4/HLS playback derivatives, or a WebM, Ogg, or MPEG-1/2 source file, many other sites and tools won't take them because they expect MP4s with h.264 or HEVC. Can you save the video to your camera roll? Repost it? Edit it in your video editor of choice? Maybe, maybe not. Manual conversion will take time and requires extra effort.
Note that h.264/AVC and HEVC are both international standards but not open standards, and they both have active patent pools and require licensing to produce and distribute an encoder or decoder. I'll leave it to a future consultation to figure out what that means to us, users of Debian's ffmpeg package. ;) Allowing us to create MP4 h.264/AVC output could increase ease of use / compatibility for reusers.
Contributing is also more problematic, because most modern cameras and editing tools produce H.264 or HEVC video in some flavor of MP4 container by default. We accept some old formats (MPEG-1 and MPEG-2 and Ogg Theora) and some weird formats (WebM with VP8 or VP9) but not the actually commonly used ones. This means almost every video upload is recoded by the uploader, either manually or through a tool. This reduces the quality of the stored file and the subsequent playback derivatives, and gives another opportunity to massively mis-estimate bitrate and produce a very bad quality stored file by accident that cannot be fixed by anyone else (this happens a lot).
Is there anything that can be done to expand the server-side format support further without changing Wikimedia's stance on patents? For example, should Wikimedia Commons support additional container formats or codecs that are royalty-free or whose patents have expired?
The only functional change we need is to enable uploading .mp4 and .mov files with the h.264 video and AAC-LC audio codecs. (And optionally HEVC if it's not problematic).
Without reinterpreting or changing the policy, I think we're not meant to be *using* the h.264 or HEVC codecs in ffmpeg, even though it's in our Debian installations. This means our only hopes for ingesting common video files are reevaluating the policy or doing a Rube Goldberg machine where we transcode client-side using hardware codecs via Web Codecs. ;)
While that would be a fun project, it shouldn't be necessary IMO.
Container formats are not a problem; everybody ships MP4/ISO BMFF muxer/demuxer code without a second thought about patents. We're even producing MP4 files for HLS playback tracks for iOS (with free codecs inside).
Allowing *ingestion* of MP4 h.264/AAC would allow uploading camera originals from most consumer gear -- a major democratizing feature.Ingestion of MP4 HEVC/AAC would give more compatibility.
In both cases we have all the software we need, we already use the Debian ffmpeg package which includes code supporting both formats; we just don't allow uploading the files, reading them to convert for playback, or downloading the originals from our web site.
Do we need a MPEG-LA patent license for that? Nobody seemed to think so in 2014 but nobody could tell me for sure either, then or now.
We'd also have to make the choice of whether distributing the files as originals is somehow violating a patent or if nobody cares about distribution of files encoded by someone else. Nobody knew for sure what that meant in 2014 under different license agreements but we were pretty sure we wouldn't have to pay anything, even though we put the idea of getting the license to a vote.
Again though, if we do this we need to think seriously about providing better management tools for reviewing large/long uploads (long video, audio etc) as I keep hearing people say "please don't make it easy to upload video, then we'll have to review more uploads and we don't have the human time available to dedicate to it".
-- b
Hard email to read, but Galder's are quite of indisputable thoughts and the harsh reality of Wikimedia's technological state of the art.
Yet this incontestability is, at the same time, the very profound problem: the WMF will not refute it, nor structurally change it, besides silences and inspiring words in progress and strategic reports. Such a change requires millions of dollars that the projects are actually able to annually fundraise for the institution, but that the institution prioritizes to maintain its own (questionable) corporative structure and not the digital one of the projects.
Hopefully someone else prove us wrong with data, factual progress and optimism.
Xavier Dengra El dimarts, 23 de gener 2024 a les 12:02, Galder Gonzalez Larrañaga galder158@hotmail.com va escriure:
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved (https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge". We also made some recommendations to improve the User Experience (https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge (https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data and interactive content with a compatible license for years. (Remember, "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive solutions to knowledge questions, even the silliest ones (https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "becoming the essential infrastructure of the ecosystem of free knowledge" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully,[Histropedia will do it better. http://histropedia.com/%5D(http://histropedia.com/)
- We could have something very special: inline links in video and audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" (https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly
relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data
and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to learn
lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly
relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data
and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta < paulosperneta@gmail.com> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly
relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data
and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman jmh649@gmail.com wrote:
It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta < paulosperneta@gmail.com> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them
highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing
data and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Specifically related to video uploads, we had discussions on Commons on different strategic issues recently, in particular, about this. The general sentiment was, to my understanding (pls correct me if I am wrong) that Commons has no ambition to become Youtube 2.0 and we do not have any resources for this. If video upload is encouraged, very strict policies must be in force concerning of what is in the scope of Commons.
Best Yaroslav
On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber bvibber@wikimedia.org wrote:
Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman jmh649@gmail.com wrote:
It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta < paulosperneta@gmail.com> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them
highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing
data and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving
interactive solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Yes we see this sentiment regarding a number of issues in our movement. The existing community wants to keep certain processes more difficult / time consuming to make sure that those involved in the process are sufficiently "dedicated".
Maybe we just need a flag which can be given to allow certain folks we trust to use an easier process or only allow video upload by people with so many edits which can be removed if they misuse it?
James
On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter ymbalt@gmail.com wrote:
Specifically related to video uploads, we had discussions on Commons on different strategic issues recently, in particular, about this. The general sentiment was, to my understanding (pls correct me if I am wrong) that Commons has no ambition to become Youtube 2.0 and we do not have any resources for this. If video upload is encouraged, very strict policies must be in force concerning of what is in the scope of Commons.
Best Yaroslav
On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber bvibber@wikimedia.org wrote:
Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman jmh649@gmail.com wrote:
It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta < paulosperneta@gmail.com> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them
highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing
data and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving
interactive solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Thanks to everyone for your comments. We don't need to worry about Commons being "Youtube 2.0", because we can't embed Commons video outside. Furthermore, we can't even embed Commons images or videos in Diff, because oEmbed is not working for Commons and Wordpress can't take directly images or videos from Commons. This has been known since... 2010!
* https://phabricator.wikimedia.org/T27854 * https://phabricator.wikimedia.org/T309101
Again, the problem is not about this code or that specific piece of code. The problem is lack of direction, ambition and goals.
Cheers,
Galder ________________________________ From: James Heilman jmh649@gmail.com Sent: Tuesday, January 23, 2024 10:49 PM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yes we see this sentiment regarding a number of issues in our movement. The existing community wants to keep certain processes more difficult / time consuming to make sure that those involved in the process are sufficiently "dedicated".
Maybe we just need a flag which can be given to allow certain folks we trust to use an easier process or only allow video upload by people with so many edits which can be removed if they misuse it?
James
On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter <ymbalt@gmail.commailto:ymbalt@gmail.com> wrote: Specifically related to video uploads, we had discussions on Commons on different strategic issues recently, in particular, about this. The general sentiment was, to my understanding (pls correct me if I am wrong) that Commons has no ambition to become Youtube 2.0 and we do not have any resources for this. If video upload is encouraged, very strict policies must be in force concerning of what is in the scope of Commons.
Best Yaroslav
On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber <bvibber@wikimedia.orgmailto:bvibber@wikimedia.org> wrote: Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman <jmh649@gmail.commailto:jmh649@gmail.com> wrote: It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta <paulosperneta@gmail.commailto:paulosperneta@gmail.com> wrote: Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta <paulosperneta@gmail.commailto:paulosperneta@gmail.com> escreveu (terça, 23/01/2024 à(s) 19:41): I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> escreveu (terça, 23/01/2024 à(s) 11:03): Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved (https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge". We also made some recommendations to improve the User Experience (https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge (https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
* Graph extension is used in thousands of pages, some of them highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution. * Meanwhile, a place like Our World in Data has been publishing data and interactive content with a compatible license for years. (Remember, "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853). * Wolfram Alpha is like a light year ahead us on giving interactive solutions to knowledge questions, even the silliest ones (https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "becoming the essential infrastructure of the ecosystem of free knowledge" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge". * Brilliant (https://brilliant.org/) is brilliant if you want to learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms? * We can build interactive timelines using Wikidata, but we can't embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/http://histropedia.com/ * We could have something very special: inline links in video and audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that. * ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" (https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian
Thank you Yaroslav, I would very much appreciate a link to the discussion. By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure encyclopaedic videos. I see a false dilemma there.
El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Thanks to everyone for your comments. We don't need to worry about Commons being "Youtube 2.0", because we can't embed Commons video outside. Furthermore, we can't even embed Commons images or videos in Diff, because oEmbed is not working for Commons and Wordpress can't take directly images or videos from Commons. This has been known since... 2010!
Again, the problem is not about this code or that specific piece of code. The problem is lack of direction, ambition and goals.
Cheers,
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, January 23, 2024 10:49 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yes we see this sentiment regarding a number of issues in our movement. The existing community wants to keep certain processes more difficult / time consuming to make sure that those involved in the process are sufficiently "dedicated".
Maybe we just need a flag which can be given to allow certain folks we trust to use an easier process or only allow video upload by people with so many edits which can be removed if they misuse it?
James
On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter ymbalt@gmail.com wrote:
Specifically related to video uploads, we had discussions on Commons on different strategic issues recently, in particular, about this. The general sentiment was, to my understanding (pls correct me if I am wrong) that Commons has no ambition to become Youtube 2.0 and we do not have any resources for this. If video upload is encouraged, very strict policies must be in force concerning of what is in the scope of Commons.
Best Yaroslav
On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber bvibber@wikimedia.org wrote:
Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman jmh649@gmail.com wrote:
It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta < paulosperneta@gmail.com> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly
relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data
and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to learn
lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
+1 to Galder.
Sharing a current situation.
A significant number of non wikimedian photographers participate in the wiki loves X campaigns and since the upload process in commons is complex than any other site, most of them feel lost and don't retain.
We are arranging wiki loves folklore in Bangladesh this year and we have prepared a handbook for the participants considering the above situation. The handbook has been uploaded to commons and now we're receiving feedback that our participants are feeling lost after visiting the description page, they can't decide how to view the pdf.
Wikimedia commons needs a user friendly and intuitive pdf viewer asap.
Best, Rafi
On Wed, Jan 24, 2024, 4:24 AM Ivan Martínez galaver@gmail.com wrote:
Thank you Yaroslav, I would very much appreciate a link to the discussion. By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure encyclopaedic videos. I see a false dilemma there.
El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Thanks to everyone for your comments. We don't need to worry about Commons being "Youtube 2.0", because we can't embed Commons video outside. Furthermore, we can't even embed Commons images or videos in Diff, because oEmbed is not working for Commons and Wordpress can't take directly images or videos from Commons. This has been known since... 2010!
Again, the problem is not about this code or that specific piece of code. The problem is lack of direction, ambition and goals.
Cheers,
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, January 23, 2024 10:49 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yes we see this sentiment regarding a number of issues in our movement. The existing community wants to keep certain processes more difficult / time consuming to make sure that those involved in the process are sufficiently "dedicated".
Maybe we just need a flag which can be given to allow certain folks we trust to use an easier process or only allow video upload by people with so many edits which can be removed if they misuse it?
James
On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter ymbalt@gmail.com wrote:
Specifically related to video uploads, we had discussions on Commons on different strategic issues recently, in particular, about this. The general sentiment was, to my understanding (pls correct me if I am wrong) that Commons has no ambition to become Youtube 2.0 and we do not have any resources for this. If video upload is encouraged, very strict policies must be in force concerning of what is in the scope of Commons.
Best Yaroslav
On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber bvibber@wikimedia.org wrote:
Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman jmh649@gmail.com wrote:
It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta < paulosperneta@gmail.com> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly
relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data
and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
-- *Iván Martínez*
*Voluntario - Wikimedia México A.C.User:ProtoplasmaKid *
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- 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
Kaya
I'd like to my perspective from wikimania side the amount of effort volunteers and time to bring every session alive on commons is all consuming yes YouTube is the best place to put that content. It gets harder the smaller the event is. Video needs to be addresses as a priority along with issues raise by galder. Simple mp4 upload option would be a starting point, surely we are big enough for any copyright holders to donate the licensing if wmf comes made a request
On Wed, 24 Jan 2024, 2:44 pm Mrb Rafi, mrbrafi1971@gmail.com wrote:
+1 to Galder.
Sharing a current situation.
A significant number of non wikimedian photographers participate in the wiki loves X campaigns and since the upload process in commons is complex than any other site, most of them feel lost and don't retain.
We are arranging wiki loves folklore in Bangladesh this year and we have prepared a handbook for the participants considering the above situation. The handbook has been uploaded to commons and now we're receiving feedback that our participants are feeling lost after visiting the description page, they can't decide how to view the pdf.
Wikimedia commons needs a user friendly and intuitive pdf viewer asap.
Best, Rafi
On Wed, Jan 24, 2024, 4:24 AM Ivan Martínez galaver@gmail.com wrote:
Thank you Yaroslav, I would very much appreciate a link to the discussion. By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure encyclopaedic videos. I see a false dilemma there.
El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Thanks to everyone for your comments. We don't need to worry about Commons being "Youtube 2.0", because we can't embed Commons video outside. Furthermore, we can't even embed Commons images or videos in Diff, because oEmbed is not working for Commons and Wordpress can't take directly images or videos from Commons. This has been known since... 2010!
Again, the problem is not about this code or that specific piece of code. The problem is lack of direction, ambition and goals.
Cheers,
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, January 23, 2024 10:49 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yes we see this sentiment regarding a number of issues in our movement. The existing community wants to keep certain processes more difficult / time consuming to make sure that those involved in the process are sufficiently "dedicated".
Maybe we just need a flag which can be given to allow certain folks we trust to use an easier process or only allow video upload by people with so many edits which can be removed if they misuse it?
James
On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter ymbalt@gmail.com wrote:
Specifically related to video uploads, we had discussions on Commons on different strategic issues recently, in particular, about this. The general sentiment was, to my understanding (pls correct me if I am wrong) that Commons has no ambition to become Youtube 2.0 and we do not have any resources for this. If video upload is encouraged, very strict policies must be in force concerning of what is in the scope of Commons.
Best Yaroslav
On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber bvibber@wikimedia.org wrote:
Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman jmh649@gmail.com wrote:
It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta < paulosperneta@gmail.com> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly
relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data
and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
-- *Iván Martínez*
*Voluntario - Wikimedia México A.C.User:ProtoplasmaKid *
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Dear All,
I can easily find two recent discussions which touch the topic of video on Commons:
https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2023/12#Prio...
and
https://commons.wikimedia.org/wiki/Commons_talk:Requests_for_comment/Technic.... ..
I am sure there were more.
I do not know whether videos can be embedded externally, but images certainly can. I for example embed them in my blog (random example: https://ymblanter.dreamwidth.org/146913.html; the text is in Russian which is irrelevant for my point). I have been doing this for years and never encountered any issues.
Best Yaroslav
On Wed, Jan 24, 2024 at 8:00 AM Gnangarra gnangarra@gmail.com wrote:
Kaya
I'd like to my perspective from wikimania side the amount of effort volunteers and time to bring every session alive on commons is all consuming yes YouTube is the best place to put that content. It gets harder the smaller the event is. Video needs to be addresses as a priority along with issues raise by galder. Simple mp4 upload option would be a starting point, surely we are big enough for any copyright holders to donate the licensing if wmf comes made a request
On Wed, 24 Jan 2024, 2:44 pm Mrb Rafi, mrbrafi1971@gmail.com wrote:
+1 to Galder.
Sharing a current situation.
A significant number of non wikimedian photographers participate in the wiki loves X campaigns and since the upload process in commons is complex than any other site, most of them feel lost and don't retain.
We are arranging wiki loves folklore in Bangladesh this year and we have prepared a handbook for the participants considering the above situation. The handbook has been uploaded to commons and now we're receiving feedback that our participants are feeling lost after visiting the description page, they can't decide how to view the pdf.
Wikimedia commons needs a user friendly and intuitive pdf viewer asap.
Best, Rafi
On Wed, Jan 24, 2024, 4:24 AM Ivan Martínez galaver@gmail.com wrote:
Thank you Yaroslav, I would very much appreciate a link to the discussion. By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure encyclopaedic videos. I see a false dilemma there.
El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Thanks to everyone for your comments. We don't need to worry about Commons being "Youtube 2.0", because we can't embed Commons video outside. Furthermore, we can't even embed Commons images or videos in Diff, because oEmbed is not working for Commons and Wordpress can't take directly images or videos from Commons. This has been known since... 2010!
Again, the problem is not about this code or that specific piece of code. The problem is lack of direction, ambition and goals.
Cheers,
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, January 23, 2024 10:49 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yes we see this sentiment regarding a number of issues in our movement. The existing community wants to keep certain processes more difficult / time consuming to make sure that those involved in the process are sufficiently "dedicated".
Maybe we just need a flag which can be given to allow certain folks we trust to use an easier process or only allow video upload by people with so many edits which can be removed if they misuse it?
James
On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter ymbalt@gmail.com wrote:
Specifically related to video uploads, we had discussions on Commons on different strategic issues recently, in particular, about this. The general sentiment was, to my understanding (pls correct me if I am wrong) that Commons has no ambition to become Youtube 2.0 and we do not have any resources for this. If video upload is encouraged, very strict policies must be in force concerning of what is in the scope of Commons.
Best Yaroslav
On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber bvibber@wikimedia.org wrote:
Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman jmh649@gmail.com wrote:
It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta < paulosperneta@gmail.com> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them
highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing
data and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
-- *Iván Martínez*
*Voluntario - Wikimedia México A.C.User:ProtoplasmaKid *
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Thanks for the links, Yaroslav, I'll take a look.
About the embedding, yes, you can embed an image using HTML code. You can't embed an image or a video using oEmbed, so you can't share a video from Commons in, lets's say, Facebook. And you can't just add the URL of the video in WordPress and play it, like millions of blogs are doing with YouTube or Vimeo videos. So you can't share externally a video (or an image) just using the URL, which is one of the main entry points YouTube is using for external playing. Is it technically possible to embed a video from Commons in a place which is not Facebook/Xitter/Mastodon... yes, it is, but coding is necessary, which is not how to make Commons part of the essential ecosystem of free knowledge.
In the same way, you can upload a video to Commons. We upload two every week for the project Ikusgela (https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Ikusgela), but it's not a simple process, which is the point of this message.
Thanks
Galder
________________________________ From: Yaroslav Blanter ymbalt@gmail.com Sent: Wednesday, January 24, 2024 5:59 PM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Dear All,
I can easily find two recent discussions which touch the topic of video on Commons:
https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2023/12#Prio...
and
https://commons.wikimedia.org/wiki/Commons_talk:Requests_for_comment/Technic......
I am sure there were more.
I do not know whether videos can be embedded externally, but images certainly can. I for example embed them in my blog (random example: https://ymblanter.dreamwidth.org/146913.html; the text is in Russian which is irrelevant for my point). I have been doing this for years and never encountered any issues.
Best Yaroslav
On Wed, Jan 24, 2024 at 8:00 AM Gnangarra <gnangarra@gmail.commailto:gnangarra@gmail.com> wrote: Kaya
I'd like to my perspective from wikimania side the amount of effort volunteers and time to bring every session alive on commons is all consuming yes YouTube is the best place to put that content. It gets harder the smaller the event is. Video needs to be addresses as a priority along with issues raise by galder. Simple mp4 upload option would be a starting point, surely we are big enough for any copyright holders to donate the licensing if wmf comes made a request
On Wed, 24 Jan 2024, 2:44 pm Mrb Rafi, <mrbrafi1971@gmail.commailto:mrbrafi1971@gmail.com> wrote: +1 to Galder.
Sharing a current situation.
A significant number of non wikimedian photographers participate in the wiki loves X campaigns and since the upload process in commons is complex than any other site, most of them feel lost and don't retain.
We are arranging wiki loves folklore in Bangladesh this year and we have prepared a handbook for the participants considering the above situation. The handbook has been uploaded to commons and now we're receiving feedback that our participants are feeling lost after visiting the description page, they can't decide how to view the pdf.
Wikimedia commons needs a user friendly and intuitive pdf viewer asap.
Best, Rafi
On Wed, Jan 24, 2024, 4:24 AM Ivan Martínez <galaver@gmail.commailto:galaver@gmail.com> wrote: Thank you Yaroslav, I would very much appreciate a link to the discussion. By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure encyclopaedic videos. I see a false dilemma there.
El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (<galder158@hotmail.commailto:galder158@hotmail.com>) escribió: Thanks to everyone for your comments. We don't need to worry about Commons being "Youtube 2.0", because we can't embed Commons video outside. Furthermore, we can't even embed Commons images or videos in Diff, because oEmbed is not working for Commons and Wordpress can't take directly images or videos from Commons. This has been known since... 2010!
* https://phabricator.wikimedia.org/T27854 * https://phabricator.wikimedia.org/T309101
Again, the problem is not about this code or that specific piece of code. The problem is lack of direction, ambition and goals.
Cheers,
Galder ________________________________ From: James Heilman <jmh649@gmail.commailto:jmh649@gmail.com> Sent: Tuesday, January 23, 2024 10:49 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yes we see this sentiment regarding a number of issues in our movement. The existing community wants to keep certain processes more difficult / time consuming to make sure that those involved in the process are sufficiently "dedicated".
Maybe we just need a flag which can be given to allow certain folks we trust to use an easier process or only allow video upload by people with so many edits which can be removed if they misuse it?
James
On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter <ymbalt@gmail.commailto:ymbalt@gmail.com> wrote: Specifically related to video uploads, we had discussions on Commons on different strategic issues recently, in particular, about this. The general sentiment was, to my understanding (pls correct me if I am wrong) that Commons has no ambition to become Youtube 2.0 and we do not have any resources for this. If video upload is encouraged, very strict policies must be in force concerning of what is in the scope of Commons.
Best Yaroslav
On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber <bvibber@wikimedia.orgmailto:bvibber@wikimedia.org> wrote: Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman <jmh649@gmail.commailto:jmh649@gmail.com> wrote: It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta <paulosperneta@gmail.commailto:paulosperneta@gmail.com> wrote: Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta <paulosperneta@gmail.commailto:paulosperneta@gmail.com> escreveu (terça, 23/01/2024 à(s) 19:41): I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> escreveu (terça, 23/01/2024 à(s) 11:03): Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved (https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge". We also made some recommendations to improve the User Experience (https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge (https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
* Graph extension is used in thousands of pages, some of them highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution. * Meanwhile, a place like Our World in Data has been publishing data and interactive content with a compatible license for years. (Remember, "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853). * Wolfram Alpha is like a light year ahead us on giving interactive solutions to knowledge questions, even the silliest ones (https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "becoming the essential infrastructure of the ecosystem of free knowledge" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge". * Brilliant (https://brilliant.org/) is brilliant if you want to learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms? * We can build interactive timelines using Wikidata, but we can't embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/http://histropedia.com/ * We could have something very special: inline links in video and audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that. * ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" (https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- Iván Martínez Voluntario - Wikimedia México A.C. User:ProtoplasmaKid
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
And with this thread, we had an example of exactly what tends to happen to novices, to new contributors, to interested people who are used to other simpler interfaces. Faced with raising a problem like the one Galder exposed, and having as an answer the technicalities and the tortuous path of having to go through 10 steps to place a video that is aligned with the Commons mission.
I love the *different* way of our free and openly developed community tools, except that Strategy 2030 was clear that the way was in the opposite direction https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_User_Experience .
Best,
El mié, 24 ene 2024 a las 11:13, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Thanks for the links, Yaroslav, I'll take a look.
About the embedding, yes, you can embed an image using HTML code. You can't embed an image or a video using oEmbed, so you can't share a video from Commons in, lets's say, Facebook. And you can't just add the URL of the video in WordPress and play it, like millions of blogs are doing with YouTube or Vimeo videos. So you can't share externally a video (or an image) just using the URL, which is one of the main entry points YouTube is using for external playing. Is it technically possible to embed a video from Commons in a place which is not Facebook/Xitter/Mastodon... yes, it is, but coding is necessary, which is not how to make Commons part of the essential ecosystem of free knowledge.
In the same way, you can upload a video to Commons. We upload two every week for the project Ikusgela ( https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Ikusgela), but it's not a simple process, which is the point of this message.
Thanks
Galder
*From:* Yaroslav Blanter ymbalt@gmail.com *Sent:* Wednesday, January 24, 2024 5:59 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Dear All,
I can easily find two recent discussions which touch the topic of video on Commons:
https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2023/12#Prio...
and
https://commons.wikimedia.org/wiki/Commons_talk:Requests_for_comment/Technic.... ..
I am sure there were more.
I do not know whether videos can be embedded externally, but images certainly can. I for example embed them in my blog (random example: https://ymblanter.dreamwidth.org/146913.html; the text is in Russian which is irrelevant for my point). I have been doing this for years and never encountered any issues.
Best Yaroslav
On Wed, Jan 24, 2024 at 8:00 AM Gnangarra gnangarra@gmail.com wrote:
Kaya
I'd like to my perspective from wikimania side the amount of effort volunteers and time to bring every session alive on commons is all consuming yes YouTube is the best place to put that content. It gets harder the smaller the event is. Video needs to be addresses as a priority along with issues raise by galder. Simple mp4 upload option would be a starting point, surely we are big enough for any copyright holders to donate the licensing if wmf comes made a request
On Wed, 24 Jan 2024, 2:44 pm Mrb Rafi, mrbrafi1971@gmail.com wrote:
+1 to Galder.
Sharing a current situation.
A significant number of non wikimedian photographers participate in the wiki loves X campaigns and since the upload process in commons is complex than any other site, most of them feel lost and don't retain.
We are arranging wiki loves folklore in Bangladesh this year and we have prepared a handbook for the participants considering the above situation. The handbook has been uploaded to commons and now we're receiving feedback that our participants are feeling lost after visiting the description page, they can't decide how to view the pdf.
Wikimedia commons needs a user friendly and intuitive pdf viewer asap.
Best, Rafi
On Wed, Jan 24, 2024, 4:24 AM Ivan Martínez galaver@gmail.com wrote:
Thank you Yaroslav, I would very much appreciate a link to the discussion. By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure encyclopaedic videos. I see a false dilemma there.
El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (< galder158@hotmail.com>) escribió:
Thanks to everyone for your comments. We don't need to worry about Commons being "Youtube 2.0", because we can't embed Commons video outside. Furthermore, we can't even embed Commons images or videos in Diff, because oEmbed is not working for Commons and Wordpress can't take directly images or videos from Commons. This has been known since... 2010!
Again, the problem is not about this code or that specific piece of code. The problem is lack of direction, ambition and goals.
Cheers,
Galder
*From:* James Heilman jmh649@gmail.com *Sent:* Tuesday, January 23, 2024 10:49 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yes we see this sentiment regarding a number of issues in our movement. The existing community wants to keep certain processes more difficult / time consuming to make sure that those involved in the process are sufficiently "dedicated".
Maybe we just need a flag which can be given to allow certain folks we trust to use an easier process or only allow video upload by people with so many edits which can be removed if they misuse it?
James
On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter ymbalt@gmail.com wrote:
Specifically related to video uploads, we had discussions on Commons on different strategic issues recently, in particular, about this. The general sentiment was, to my understanding (pls correct me if I am wrong) that Commons has no ambition to become Youtube 2.0 and we do not have any resources for this. If video upload is encouraged, very strict policies must be in force concerning of what is in the scope of Commons.
Best Yaroslav
On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber bvibber@wikimedia.org wrote:
Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman jmh649@gmail.com wrote:
It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta < paulosperneta@gmail.com> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them highly
relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing data
and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to learn
lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
-- *Iván Martínez*
*Voluntario - Wikimedia México A.C. User:ProtoplasmaKid *
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
On Thu, Jan 25, 2024 at 9:51 PM Ivan Martínez galaver@gmail.com wrote:
Strategy 2030 was clear that the way was in the opposite direction
https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_User_Experience .
Absolutely. That has only become more true. (Happy new year, my friend.)
Brion wrote:
- Overturn the requirement to avoid handling h.264 files on Wikimedia
servers or accept them from users or serve them to users. Allow importing h.264 uploads and creating h.264 transcodes for playback compatibility.
Yes, this is essential. Can be via a separate videowiki in the short term (or NCcommons) if the WM Commons community is united in opposition.
- Create an interactive media team with at least two engineers, a
designer, and a project manager
- Give this team a remit to rebuild *and maintain in an ongoing fashion*
the existing TimedMediaHandler, Graphs, Score, 3D, etc extensions
Yes. Just to coordinate + streamline all the development, design, and coordination across the movement. It would likely save everyone time and resources in the end, instead of so many half-focused groups and good ideas hitting dead ends.
wʍ, SJ
Hi all,
Who is in charge to make the call for this to happen?
It just seems so necessary and yet, here we are. Video handling is not the future, is the present, and that's just the beginning...
Cheers,
On Fri, Jan 26, 2024, 00:10 Samuel Klein meta.sj@gmail.com wrote:
On Thu, Jan 25, 2024 at 9:51 PM Ivan Martínez galaver@gmail.com wrote:
Strategy 2030 was clear that the way was in the opposite direction
https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_User_Experience .
Absolutely. That has only become more true. (Happy new year, my friend.)
Brion wrote:
- Overturn the requirement to avoid handling h.264 files on Wikimedia
servers or accept them from users or serve them to users. Allow importing h.264 uploads and creating h.264 transcodes for playback compatibility.
Yes, this is essential. Can be via a separate videowiki in the short term (or NCcommons) if the WM Commons community is united in opposition.
- Create an interactive media team with at least two engineers, a
designer, and a project manager
- Give this team a remit to rebuild *and maintain in an ongoing
fashion* the existing TimedMediaHandler, Graphs, Score, 3D, etc extensions
Yes. Just to coordinate + streamline all the development, design, and coordination across the movement. It would likely save everyone time and resources in the end, instead of so many half-focused groups and good ideas hitting dead ends.
wʍ, SJ _______________________________________________ Wikimedia-l mailing list -- 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
Den fre 26 jan. 2024 kl 04:10 skrev Samuel Klein meta.sj@gmail.com:
Brion wrote:
- Overturn the requirement to avoid handling h.264 files on Wikimedia
servers or accept them from users or serve them to users. Allow importing h.264 uploads and creating h.264 transcodes for playback compatibility.
Yes, this is essential. Can be via a separate videowiki in the short term (or NCcommons) if the WM Commons community is united in opposition.
I disagree. Using non-open tools in our workflows is a poison that should be resisted by any means possible.
Instead, we should create an app (or integrate in the Commons app), the possibility to record video natively in a free and open format. Yes, it would be a big task, but it would show that we mean what we say when we talk about the essential infrastructure of the ecosystem of free knowledge and would be of great benefit not only to our movement, but to the society in general.
/Jan
Bon dia/Hi,
I don't want to add even more seriousness to the thread; I am happy to read that there is an absolute agreement on the topic.
But interactivity is not only about embedding video: we currently must leave each project to Toolforge for supporting editing tools, to Humanwiki to read biases, to OAuth to participate in polls or some editathons, or to MediawikiStats + WMFCloud to even see mapped or plotted the simplest statistics of each article or user contributions! Not to mention the struggles to keep “attractive” main pages of our hundreds of projects. Mobile browsers open them as mobile versions, and most become an unreadable disaster. Who will be still willing to read a minoritized language content like the Kurdish Wikiquote (just an example) if there are no templates that can support thriving communities to show decent main pages after the 2010s social desktop-to-phone transition? That's also interactivity, and that fight we already heavily lost it since a decade ago. No wonder that another thread brings up Google not indexing Wikisource properly... It is somehow part of the same problem.
Technical teams have been around 15 years externalizing an interface ecosystem to not confront that what needs to be improved and reintegrated is Mediawiki itself. The result is a labyrinth for the newcomers and a vast ocean of pending updates and bugs. Video failures are among the symptoms of such software externalization.
Salutacions/Best,
Xavier Dengra El divendres, 26 de gener 2024 a les 08:53, Jan Ainali jan@aina.li va escriure:
Den fre 26 jan. 2024 kl 04:10 skrev Samuel Klein meta.sj@gmail.com:
Brion wrote:
- Overturn the requirement to avoid handling h.264 files on Wikimedia servers or accept them from users or serve them to users. Allow importing h.264 uploads and creating h.264 transcodes for playback compatibility.
Yes, this is essential. Can be via a separate videowiki in the short term (or NCcommons) if the WM Commons community is united in opposition.
I disagree. Using non-open tools in our workflows is a poison that should be resisted by any means possible.
Instead, we should create an app (or integrate in the Commons app), the possibility to record video natively in a free and open format. Yes, it would be a big task, but it would show that we mean what we say when we talk about the essential infrastructure of the ecosystem of free knowledge and would be of great benefit not only to our movement, but to the society in general.
/Jan
On Fri, Jan 26, 2024 at 2:53 AM Jan Ainali jan@aina.li wrote:
Brion wrote:
- Overturn the requirement to avoid handling h.264 files on Wikimedia
servers or accept them from users or serve them to users. Allow importing h.264 uploads and creating h.264 transcodes for playback compatibility.
Yes, this is essential. Can be via a separate videowiki in the short term (or NCcommons) if the WM Commons community is united in opposition.
I disagree. Using non-open tools in our workflows is a poison that should be resisted by any means possible.
You've single-handedly contributed massively to free knowledge outputs and education across a range of formats, so surely something poisonous to your work (or enthusiasm!) would be problematic. But I don't think tools that allow people to share free knowledge in whatever format they have and thereby convert it to free formats, are remotely harmful.
People who have existing media will generally not use a new app; the most impactful missing steps are a) a stickier intake wizard (iterative uploading and license-clearing) b) automatic transcoding (without the uploader having to grok + do it)
geni wrote:
I really doubt we will ever get much in the way of encyclopaedic videos
on our platforms
? Many creators say they are glad to relicense their existing fantastic work, but don't have time/will to overcome the current obstacles to such reuse that they have to [personally] overcome for each video. So we only get bulk contributions, through a third-party who is familiar with the wikis, once in a while... a modest homegrown example: depthsofwiki has a range of great short videos that are partly educational and mainly inspiring to delve into the wikis and learn things. I suspect none of them are on Commons despite obvious relevance to the movement for outreach, illustration, and the like.
SJ.
On Sat, 27 Jan 2024 at 05:07, Samuel Klein meta.sj@gmail.com wrote:
? Many creators say they are glad to relicense their existing fantastic work, but don't have time/will to overcome the current obstacles to such reuse that they have to [personally] overcome for each video. So we only get bulk contributions, through a third-party who is familiar with the wikis, once in a while... a modest homegrown example: depthsofwiki has a range of great short videos that are partly educational and mainly inspiring to delve into the wikis and learn things. I suspect none of them are on Commons despite obvious relevance to the movement for outreach, illustration, and the like.
I suspect we are dealing with Stated vs. Revealed Preferences. Saying no to wikipedia has more of a social cost than talking about technical issues. Converting to something wikipedia will accept is fairly straightforward. Handbrake has a GUI and pops up in creator workflows as a convient way to compress B-roll. Uploading presents more of a challange than most areas but that would be because we care more about copyright than most so probably unavoidable,
On Mon, Jan 29, 2024 at 10:29 PM geni geniice@gmail.com wrote:
On Sat, 27 Jan 2024 at 05:07, Samuel Klein meta.sj@gmail.com wrote:
? Many creators say they are glad to relicense their existing
fantastic work, but don't have time/will to overcome the current obstacles to such reuse that they have to [personally] overcome for each video. So we only get bulk contributions, through a third-party who is familiar with the wikis, once in a while... a modest homegrown example: depthsofwiki has a range of great short videos that are partly educational and mainly inspiring to delve into the wikis and learn things. I suspect none of them are on Commons despite obvious relevance to the movement for outreach, illustration, and the like.
I suspect we are dealing with Stated vs. Revealed Preferences. Saying no to wikipedia has more of a social cost than talking about technical issues. Converting to something wikipedia will accept is fairly straightforward. Handbrake has a GUI and pops up in creator workflows as a convient way to compress B-roll. Uploading presents more of a challange than most areas but that would be because we care more about copyright than most so probably unavoidable,
A bigger issue with a random YouTuber or other individual video creator re-licensing their work is that *very* often, their "own work" is not purely "own work"; rather, they use non-free music as background, incorporate clips or memes in their video, etc., making the video potentially *unacceptable* on Commons, even if the author of the full video represents that they are willing to license their work under a free license.
This is a sticky issue, because there is no easy fix, technological or otherwise, for clearing those copyright concerns. If a video creator has their contributions wait in some review limbo for weeks (or months), and then has, say, four out of five of them rejected on copyright grounds, they would be overwhelmingly unlikely to keep contributing.
(I'm just bringing up this issue that doesn't seem to have been mentioned as a factor. I do agree and wholeheartedly support the need to accept more formats and take on the burden of determining whether videos are usable (what SJ above called "a stickier ingenstion process"); even if it won't attract hordes of YouTubers to contribute, it could allow those of us already involved with and interested in free knowledge/culture to contribute more easily and frequently, and that itself could be transformative, in terms of the presence of video content on the wikis compared to status quo.)
A. (in my volunteer capacity)
Thanks Asaf, very true: I can totally see how the copyright issue would remain a big problem, even if you solve the technical challenges...
I can see one solution to that (albeit farfetched): an analogue to a super rigorous referencing approach. I am imagining it's possible to verify in an automated way that an edited video is exclusively constructed out of a list of cited materials. So if we would be able to build a database of freely licensed raw materials that can be sourced from (HUGE if, I know!) I imagine that video editors could possibly limit themselves to that and credibly claim free licensing that way? But I'm guessing that the typical youtuber won't be very excited about that prospect with severe limitations on their creativity. You may still have to deal with a bunch of edge cases, but it would give a starting point.
Another way would be if we force creators to edit their videos all the way from the raw materials on a platform controlled by us, rather than upload the end product - resulting in an edit history that can trace back what materials were used and that they were freely licensed. This is very much in line with our traditional Wikipedia approach, but would be impossible to sell unless we have a pretty awesome video editor. Which brings us back to the start of this conversation :). In a way, the Kaltura editor felt more advanced than what we currently make available.
The downside is, as long as we remain copyright sticklers, it'll not be very 'fun' to develop videos for us, let alone with us. Any solution will have to be a combination of massive technical improvements, a change of attitude and an increased library of free raw materials.
Lodewijk
On Mon, Jan 29, 2024 at 3:24 PM Asaf Bartov asaf.bartov@gmail.com wrote:
On Mon, Jan 29, 2024 at 10:29 PM geni geniice@gmail.com wrote:
On Sat, 27 Jan 2024 at 05:07, Samuel Klein meta.sj@gmail.com wrote:
? Many creators say they are glad to relicense their existing
fantastic work, but don't have time/will to overcome the current obstacles to such reuse that they have to [personally] overcome for each video. So we only get bulk contributions, through a third-party who is familiar with the wikis, once in a while... a modest homegrown example: depthsofwiki has a range of great short videos that are partly educational and mainly inspiring to delve into the wikis and learn things. I suspect none of them are on Commons despite obvious relevance to the movement for outreach, illustration, and the like.
I suspect we are dealing with Stated vs. Revealed Preferences. Saying no to wikipedia has more of a social cost than talking about technical issues. Converting to something wikipedia will accept is fairly straightforward. Handbrake has a GUI and pops up in creator workflows as a convient way to compress B-roll. Uploading presents more of a challange than most areas but that would be because we care more about copyright than most so probably unavoidable,
A bigger issue with a random YouTuber or other individual video creator re-licensing their work is that *very* often, their "own work" is not purely "own work"; rather, they use non-free music as background, incorporate clips or memes in their video, etc., making the video potentially *unacceptable* on Commons, even if the author of the full video represents that they are willing to license their work under a free license.
This is a sticky issue, because there is no easy fix, technological or otherwise, for clearing those copyright concerns. If a video creator has their contributions wait in some review limbo for weeks (or months), and then has, say, four out of five of them rejected on copyright grounds, they would be overwhelmingly unlikely to keep contributing.
(I'm just bringing up this issue that doesn't seem to have been mentioned as a factor. I do agree and wholeheartedly support the need to accept more formats and take on the burden of determining whether videos are usable (what SJ above called "a stickier ingenstion process"); even if it won't attract hordes of YouTubers to contribute, it could allow those of us already involved with and interested in free knowledge/culture to contribute more easily and frequently, and that itself could be transformative, in terms of the presence of video content on the wikis compared to status quo.)
A. (in my volunteer capacity) -- Asaf Bartov asaf.bartov@gmail.com _______________________________________________ Wikimedia-l mailing list -- 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
Den tis 30 jan. 2024 kl 02:37 skrev effe iets anders < effeietsanders@gmail.com>:
I can see one solution to that (albeit farfetched): an analogue to a super rigorous referencing approach. I am imagining it's possible to verify in an automated way that an edited video is exclusively constructed out of a list of cited materials. So if we would be able to build a database of freely licensed raw materials that can be sourced from (HUGE if, I know!)
It sounds like you are describing Videowiki: https://meta.wikimedia.org/wiki/VideoWiki (where the database is Commons).
While valuable, I think that original content is needed, be it homemade animations, or videos from events or places recorded by the user and never published anywhere else.
/Jan
On Wed, 24 Jan 2024 at 07:00, Gnangarra gnangarra@gmail.com wrote:
Simple mp4 upload option would be a starting point, surely we are big enough for any copyright holders to donate the licensing if wmf comes made a request
No. There are still members of the MP4 patent pool who expect that at some point they will make a lot of money off it.
I'm not an expert in multimedia codecs or patents so I leave the actual decision to people who know better (maybe legal team in WMF?) but according to tech news, major patents for mp4 have already expired and the rest will expire soon, a large batch of them expired in November 2023 and a major batch will expire by March this year.
There are many types of mp4, I think H.263 is now expired but again, not an expert. https://meta.wikimedia.org/wiki/Have_the_patents_for_H.263_expired_yet%3F https://meta.wikimedia.org/wiki/Have_the_patents_for_MPEG-4_Visual_expired_y...
VP9 and H.264 are not expired yet (but H.264 seems to be expiring soon so maybe we should prepare?): https://meta.wikimedia.org/wiki/Have_the_patents_for_VP9_expired_yet%3F https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_MPEG-4_AVC_expire...
Am Fr., 26. Jan. 2024 um 18:59 Uhr schrieb geni geniice@gmail.com:
On Wed, 24 Jan 2024 at 07:00, Gnangarra gnangarra@gmail.com wrote:
Simple mp4 upload option would be a starting point, surely we are big
enough for any copyright holders to donate the licensing if wmf comes made a request
No. There are still members of the MP4 patent pool who expect that at some point they will make a lot of money off it.
-- geni _______________________________________________ Wikimedia-l mailing list -- 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
On Tue, 23 Jan 2024 at 22:24, Ivan Martínez galaver@gmail.com wrote:
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure encyclopaedic videos. I see a false dilemma there.
Creating good encyclopaedic videos is from a video production point of view a far harder problem that dealing with the technical hurdles in uploading video to commons. Going to take a lot of effort in scripting, shooting, lighting and editing. And having your editor of choice render the final project in a wikipedia friendly format should not present a problem (and if it does handbrake exists).
I really doubt we will ever get much in the way of encyclopaedic videos on our platforms since they take so much time and cost so much to make that they are only viable at scale from people who can do it at as a full time job. Youtubers find ways to do that through adsense, sponsor spots and Patreon. Not really something you can do on wikipedia.
On 1/26/24 12:05 PM, geni wrote:
On Tue, 23 Jan 2024 at 22:24, Ivan Martínez galaver@gmail.com wrote:
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure encyclopaedic videos. I see a false dilemma there.
Creating good encyclopaedic videos is from a video production point of view a far harder problem that dealing with the technical hurdles in uploading video to commons. Going to take a lot of effort in scripting, shooting, lighting and editing. And having your editor of choice render the final project in a wikipedia friendly format should not present a problem (and if it does handbrake exists).
I really doubt we will ever get much in the way of encyclopaedic videos on our platforms since they take so much time and cost so much to make that they are only viable at scale from people who can do it at as a full time job. Youtubers find ways to do that through adsense, sponsor spots and Patreon. Not really something you can do on wikipedia.
I don't know much of anything about youtube licensing... is it possible for youtubers to dual or re-license their content? Could we invite creators to donate their content to the commons after a year or two when their revenue stream has trailed off?
Maybe people don't know but video donation happens in Wikimedia already and it doesn't need to be from Youtubers.
Here is my favorite example: German public broadcaster (ARD) donates short informational videos to Wikipedia and they are used in articles in German Wikipedia. They get a lot of views. Here is a list of videos from one of their programs named Tagesschau: https://mvc.toolforge.org/index.php?category=Videos+by+Tagesschau+(ARD)%C3%9...
For example, this video about Golf Stream and impact of climate change on it which is used in the article of Golf Stream in German Wikipedia: https://commons.wikimedia.org/wiki/File:Kurzerkl%C3%A4rt,_Golfstrom_-_Tagess... Or when cold or hot temperatures can be dangerous to humans: https://commons.wikimedia.org/wiki/File:Gut_zu_wissen,_Wann_wird_K%C3%A4lte_... Or an explanation on Carthage, even with English subtitles: https://commons.wikimedia.org/wiki/File:Karthago,_Ph%C3%B6nizische_Gro%C3%9F...
It'd really be nice to see more partnerships like this. Whether with youtubers, public broadcasters, museums, universities, or anything like that!
Am Fr., 26. Jan. 2024 um 19:29 Uhr schrieb Andrew Bogott < abogott@wikimedia.org>:
On 1/26/24 12:05 PM, geni wrote:
On Tue, 23 Jan 2024 at 22:24, Ivan Martínez galaver@gmail.com wrote:
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
encyclopaedic videos. I see a false dilemma there.
Creating good encyclopaedic videos is from a video production point of view a far harder problem that dealing with the technical hurdles in uploading video to commons. Going to take a lot of effort in scripting, shooting, lighting and editing. And having your editor of choice render the final project in a wikipedia friendly format should not present a problem (and if it does handbrake exists).
I really doubt we will ever get much in the way of encyclopaedic videos on our platforms since they take so much time and cost so much to make that they are only viable at scale from people who can do it at as a full time job. Youtubers find ways to do that through adsense, sponsor spots and Patreon. Not really something you can do on wikipedia.
I don't know much of anything about youtube licensing... is it possible for youtubers to dual or re-license their content? Could we invite creators to donate their content to the commons after a year or two when their revenue stream has trailed off? _______________________________________________ Wikimedia-l mailing list -- 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
And here we have >300 videos donated by Osmosis
https://commons.wikimedia.org/wiki/Category:Videos_from_Osmosis
James
On Fri, Jan 26, 2024 at 11:45 AM Amir Sarabadani ladsgroup@gmail.com wrote:
Maybe people don't know but video donation happens in Wikimedia already and it doesn't need to be from Youtubers.
Here is my favorite example: German public broadcaster (ARD) donates short informational videos to Wikipedia and they are used in articles in German Wikipedia. They get a lot of views. Here is a list of videos from one of their programs named Tagesschau:
https://mvc.toolforge.org/index.php?category=Videos+by+Tagesschau+(ARD)%C3%9...
For example, this video about Golf Stream and impact of climate change on it which is used in the article of Golf Stream in German Wikipedia:
https://commons.wikimedia.org/wiki/File:Kurzerkl%C3%A4rt,_Golfstrom_-_Tagess... Or when cold or hot temperatures can be dangerous to humans: https://commons.wikimedia.org/wiki/File:Gut_zu_wissen,_Wann_wird_K%C3%A4lte_... Or an explanation on Carthage, even with English subtitles: https://commons.wikimedia.org/wiki/File:Karthago,_Ph%C3%B6nizische_Gro%C3%9F...
It'd really be nice to see more partnerships like this. Whether with youtubers, public broadcasters, museums, universities, or anything like that!
Am Fr., 26. Jan. 2024 um 19:29 Uhr schrieb Andrew Bogott < abogott@wikimedia.org>:
On 1/26/24 12:05 PM, geni wrote:
On Tue, 23 Jan 2024 at 22:24, Ivan Martínez galaver@gmail.com wrote:
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
encyclopaedic videos. I see a false dilemma there.
Creating good encyclopaedic videos is from a video production point of view a far harder problem that dealing with the technical hurdles in uploading video to commons. Going to take a lot of effort in scripting, shooting, lighting and editing. And having your editor of choice render the final project in a wikipedia friendly format should not present a problem (and if it does handbrake exists).
I really doubt we will ever get much in the way of encyclopaedic videos on our platforms since they take so much time and cost so much to make that they are only viable at scale from people who can do it at as a full time job. Youtubers find ways to do that through adsense, sponsor spots and Patreon. Not really something you can do on wikipedia.
I don't know much of anything about youtube licensing... is it possible for youtubers to dual or re-license their content? Could we invite creators to donate their content to the commons after a year or two when their revenue stream has trailed off? _______________________________________________ Wikimedia-l mailing list -- 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
-- Amir (he/him)
Wikimedia-l mailing list -- 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
It is not difficult to do something that is already happening. By referring to encyclopedic videos I am talking about multimedia that can enrich existing content. I understand your point, it's a bit like what happened with the project of reading recorded Wikipedia articles that after years seem obsolete.
What I am referring to is all that multimedia material that is visual, that can be made into video to complement articles. The process you mention is complicated, but not impossible, in fact, there are many of us editors who have all those skills already implemented in the projects.
El vie, 26 ene 2024 a las 12:06, geni (geniice@gmail.com) escribió:
On Tue, 23 Jan 2024 at 22:24, Ivan Martínez galaver@gmail.com wrote:
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
encyclopaedic videos. I see a false dilemma there.
Creating good encyclopaedic videos is from a video production point of view a far harder problem that dealing with the technical hurdles in uploading video to commons. Going to take a lot of effort in scripting, shooting, lighting and editing. And having your editor of choice render the final project in a wikipedia friendly format should not present a problem (and if it does handbrake exists).
I really doubt we will ever get much in the way of encyclopaedic videos on our platforms since they take so much time and cost so much to make that they are only viable at scale from people who can do it at as a full time job. Youtubers find ways to do that through adsense, sponsor spots and Patreon. Not really something you can do on wikipedia.
-- geni _______________________________________________ Wikimedia-l mailing list -- 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
Dear all, I think we are mixing two different topics here, which are two different problems we should solve:
We have series of problems regarding video upload, some of them technical (codecs, uploading process...) and other social (how to know if the video is freely licensed, etc). Both are interesting issues, and we should have a plan to solve them. Still, there are videos uploaded and used in Wikipedia. Technically, it is even possible to make a video portal, take a look to: https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Ikusgelahttps://eu.wikipedia.org/wiki/Atari:Hezkuntza/Ikusgela. But videos are not, by definition, more interactive than audios, images or text. Videos are still passive content: you play them in the same way you could hear an audio sample or just read a text.
When I talk about interactive content, I'm talking about content that can be manipulated by the reader:
* Take a look to OurWorldInData climate change graphs and charts (https://ourworldindata.org/explorers/climate-change). These are freely licensed, we could have them in articles, but we can't because there are road blocks for this to happen (https://phabricator.wikimedia.org/T303853). * Take a look to brilliant and how to learn geometry there : https://brilliant.org/courses/geometry-fundamentals/?from_topic=geometryhttps://brilliant.org/courses/geometry-fundamentals/?from_topic=geometry. You can just learn geometry manipulating objects, learning directly how changing a parameter changes the result. * Now take a look to this material by NASA:https://moon.nasa.gov/moon-in-motion/phases-eclipses-supermoons/moon-phases/. You can explore the moon phase with a slider, but for us this is completely impossible (there are more interactive features here: https://moon.nasa.gov/interactives/). * Now take a look to this 3D interactive models: https://sketchfab.com/juanbruallahttps://sketchfab.com/juanbrualla. There are many more, and some of them are directly under cc-by license, but we can't use them because we can't render 3D objects with textures (https://phabricator.wikimedia.org/T246901). * Do you want to learn about equations? Wikipedia is not the best starting point, as math articles are normally complex. But we could have this: https://www.desmos.com/calculator. No, is not going to happen because we are going in the opposite direction. There are more great examples of graphic calculators in https://www.desmos.com/ or https://www.geogebra.org/. Now we have some GeoGebra created videos in Commons, even if there are some users who have tried to delete them:https://commons.wikimedia.org/wiki/Category:GeoGebra. Is to say, instead of adding a graphic calculator, we add the video of someone using it, losing all the interactivity of the learning process. * This is a vertical video in the project Ikusgela:https://eu.wikipedia.org/wiki/Fitxategi:Ikusgela-Tupustarriak.webm. It has subtitles, but we can't add more information than that, even if we have the script with links, because adding links to subtitles is not allowed. Now imagine you can annotate this audio by JFK to add context and links to what he is saying: https://commons.wikimedia.org/wiki/File:Jfk_berlin_address_high.ogghttps://commons.wikimedia.org/wiki/File:Jfk_berlin_address_high.ogg. * Now, this is the timeline of symphonies by Beethoven, with audio, from Wikidata: https://w.wiki/8$jk. The good news is that we can see it. The bad news is that we can't embed it in any article. Which is extremely weird, because both are our projects.
So, we have two different problems. Video playing is quite evident. But lack of interactivity will add to the cost, because there are other platforms doing it way better.
I would really like to have an answer by the WMF.
Thanks
Galder
________________________________ From: Ivan Martínez galaver@gmail.com Sent: Tuesday, January 30, 2024 8:25 AM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
It is not difficult to do something that is already happening. By referring to encyclopedic videos I am talking about multimedia that can enrich existing content. I understand your point, it's a bit like what happened with the project of reading recorded Wikipedia articles that after years seem obsolete.
What I am referring to is all that multimedia material that is visual, that can be made into video to complement articles. The process you mention is complicated, but not impossible, in fact, there are many of us editors who have all those skills already implemented in the projects.
El vie, 26 ene 2024 a las 12:06, geni (<geniice@gmail.commailto:geniice@gmail.com>) escribió: On Tue, 23 Jan 2024 at 22:24, Ivan Martínez <galaver@gmail.commailto:galaver@gmail.com> wrote:
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure encyclopaedic videos. I see a false dilemma there.
Creating good encyclopaedic videos is from a video production point of view a far harder problem that dealing with the technical hurdles in uploading video to commons. Going to take a lot of effort in scripting, shooting, lighting and editing. And having your editor of choice render the final project in a wikipedia friendly format should not present a problem (and if it does handbrake exists).
I really doubt we will ever get much in the way of encyclopaedic videos on our platforms since they take so much time and cost so much to make that they are only viable at scale from people who can do it at as a full time job. Youtubers find ways to do that through adsense, sponsor spots and Patreon. Not really something you can do on wikipedia.
-- geni _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- Iván Martínez Voluntario - Wikimedia México A.C. User:ProtoplasmaKid
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org
With respect to OWID, one can see the interactive graphs working within a mediawiki environment here https://mdwiki.org/wiki/WikiProjectMed:OWID. Our hope for next steps to get around the current blockers is to show a static version of the graph from Commons with a play button overlay. When the play button is hit a consent pop up similar to what you see for maps on Wikivoyage https://en.wikivoyage.org/wiki/Cranbrook when you request a layer such as "relief maps". This will then bring in the corresponding interactive content hosted from the wmcloud https://owidm.wmcloud.org/grapher/share-of-population-with-schizophrenia. While this be acceptable to the powers that be? I am not sure.
With VideoWiki we have been able to create some higher quality content with a partner at MyUpchar. The text was written by us, the individual short animations were done by them, and then the tool combines it all together with text to speech. Hope to get the tool working again soon:
https://mdwiki.org/wiki/Video:Tuberculosis
On Tue, Jan 30, 2024 at 1:56 AM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Dear all, I think we are mixing two different topics here, which are two different problems we should solve:
We have series of problems regarding video upload, some of them technical (codecs, uploading process...) and other social (how to know if the video is freely licensed, etc). Both are interesting issues, and we should have a plan to solve them. Still, there are videos uploaded and used in Wikipedia. Technically, it is even possible to make a video portal, take a look to: https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Ikusgela https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Ikusgela. But videos are not, by definition, more interactive than audios, images or text. Videos are still passive content: you play them in the same way you could hear an audio sample or just read a text.
When I talk about interactive content, I'm talking about content that can be manipulated by the reader:
- Take a look to OurWorldInData climate change graphs and charts (
https://ourworldindata.org/explorers/climate-change). These are freely licensed, we could have them in articles, but we can't because there are road blocks for this to happen ( https://phabricator.wikimedia.org/T303853).
- Take a look to brilliant and how to learn geometry there :
https://brilliant.org/courses/geometry-fundamentals/?from_topic=geometryhttps://brilliant.org/courses/geometry-fundamentals/?from_topic=geometry. You can just learn geometry manipulating objects, learning directly how changing a parameter changes the result.
- Now take a look to this material by NASA:
https://moon.nasa.gov/moon-in-motion/phases-eclipses-supermoons/moon-phases/. You can explore the moon phase with a slider, but for us this is completely impossible (there are more interactive features here: https://moon.nasa.gov/interactives/).
- Now take a look to this 3D interactive models:
https://sketchfab.com/juanbrualla <https://sketchfab.com/juanbrualla>.There are many more, and some of them are directly under cc-by license, but we can't use them because we can't render 3D objects with textures ( https://phabricator.wikimedia.org/T246901).
- Do you want to learn about equations? Wikipedia is not the best
starting point, as math articles are normally complex. But we could have this: https://www.desmos.com/calculator. No, is not going to happen because we are going in the opposite direction. There are more great examples of graphic calculators in https://www.desmos.com/ or https://www.geogebra.org/. Now we have some GeoGebra created videos in Commons, even if there are some users who have tried to delete them: https://commons.wikimedia.org/wiki/Category:GeoGebra. Is to say, instead of adding a graphic calculator, we add the video of someone using it, losing all the interactivity of the learning process.
- This is a vertical video in the project Ikusgela:
https://eu.wikipedia.org/wiki/Fitxategi:Ikusgela-Tupustarriak.webm. It has subtitles, but we can't add more information than that, even if we have the script with links, because adding links to subtitles is not allowed. Now imagine you can annotate this audio by JFK to add context and links to what he is saying: https://commons.wikimedia.org/wiki/File:Jfk_berlin_address_high.ogg https://commons.wikimedia.org/wiki/File:Jfk_berlin_address_high.ogg.
- Now, this is the timeline of symphonies by Beethoven, with audio,
from Wikidata: https://w.wiki/8$jk. The good news is that we can see it. The bad news is that we can't embed it in any article. Which is extremely weird, because both are our projects.
So, we have two different problems. Video playing is quite evident. But lack of interactivity will add to the cost, because there are other platforms doing it way better.
I would really like to have an answer by the WMF.
Thanks
Galder
*From:* Ivan Martínez galaver@gmail.com *Sent:* Tuesday, January 30, 2024 8:25 AM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
It is not difficult to do something that is already happening. By referring to encyclopedic videos I am talking about multimedia that can enrich existing content. I understand your point, it's a bit like what happened with the project of reading recorded Wikipedia articles that after years seem obsolete.
What I am referring to is all that multimedia material that is visual, that can be made into video to complement articles. The process you mention is complicated, but not impossible, in fact, there are many of us editors who have all those skills already implemented in the projects.
El vie, 26 ene 2024 a las 12:06, geni (geniice@gmail.com) escribió:
On Tue, 23 Jan 2024 at 22:24, Ivan Martínez galaver@gmail.com wrote:
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
encyclopaedic videos. I see a false dilemma there.
Creating good encyclopaedic videos is from a video production point of view a far harder problem that dealing with the technical hurdles in uploading video to commons. Going to take a lot of effort in scripting, shooting, lighting and editing. And having your editor of choice render the final project in a wikipedia friendly format should not present a problem (and if it does handbrake exists).
I really doubt we will ever get much in the way of encyclopaedic videos on our platforms since they take so much time and cost so much to make that they are only viable at scale from people who can do it at as a full time job. Youtubers find ways to do that through adsense, sponsor spots and Patreon. Not really something you can do on wikipedia.
-- geni _______________________________________________ Wikimedia-l mailing list -- 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
-- *Iván Martínez*
*Voluntario - Wikimedia México A.C. User:ProtoplasmaKid *
// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una moratoria en su atención debido a que es un voluntariado. // Ayuda a proteger a Wikipedia, dona ahora: https://donate.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- 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
Galder: fair enough, let's keep this thread for interactive content. Brion's excellent suggestions deserve their own thread.
On Tue, Jan 30, 2024 at 1:14 PM James Heilman jmh649@gmail.com wrote:
With respect to OWID, one can see the interactive graphs working within a mediawiki environment here https://mdwiki.org/wiki/WikiProjectMed:OWID. Our hope for next steps to get around the current blockers is to show a static version of the graph from Commons with a play button overlay. When the play button is hit a consent pop up similar to what you see for maps on Wikivoyage https://en.wikivoyage.org/wiki/Cranbrook when you request a layer such as "relief maps". This will then bring in the corresponding interactive content hosted from the wmcloud https://owidm.wmcloud.org/grapher/share-of-population-with-schizophrenia. While this be acceptable to the powers that be? I am not sure.
Yea, this is fantastic. Thank you for the demonstration. We should creatively upgrade our approaches to privacy and security to make it possible to do this. This is a purely technical challenge, not a social adoption or licensing one, for overcoming self-imposed obstacles of our ecosystem.
S.
On Tue, Jan 30, 2024 at 2:52 PM Samuel Klein meta.sj@gmail.com wrote:
Galder: fair enough, let's keep this thread for interactive content. Brion's excellent suggestions deserve their own thread.
On Tue, Jan 30, 2024 at 1:14 PM James Heilman jmh649@gmail.com wrote:
With respect to OWID, one can see the interactive graphs working within a mediawiki environment here https://mdwiki.org/wiki/WikiProjectMed:OWID. Our hope for next steps to get around the current blockers is to show a static version of the graph from Commons with a play button overlay. When the play button is hit a consent pop up similar to what you see for maps on Wikivoyage https://en.wikivoyage.org/wiki/Cranbrook when you request a layer such as "relief maps". This will then bring in the corresponding interactive content hosted from the wmcloud https://owidm.wmcloud.org/grapher/share-of-population-with-schizophrenia. While this be acceptable to the powers that be? I am not sure.
Yea, this is fantastic. Thank you for the demonstration. We should creatively upgrade our approaches to privacy and security to make it possible to do this. This is a purely technical challenge, not a social adoption or licensing one, for overcoming self-imposed obstacles of our ecosystem.
I appreciate Galder focusing the attention back on non-video content.
If we're collecting exemplars, I'd like to add Bartosz Ciechanowski's superlative articles https://ciechanow.ski/archives/, like the ones on bicycles https://ciechanow.ski/bicycle/ and sound https://ciechanow.ski/sound/. His articles are the best examples I know of interactive content that complements long-form text content.
Beside the complementary relationship with long-form text, there is another aspect to this type of content that makes it a great fit for Wikipedia. Interactive visualizations are usually built by combining vector graphics (graphics based on geometric shapes that are defined mathematically, rather than bitmaps) and code. Both of these are at bottom textual media and thus very amenable to collaborative, iterative improvement via wikis.
Proposals to enable support for this sort of content (for example, via interactive SVGs https://phabricator.wikimedia.org/T138665) have languished for years. I think it is worth asking why, and to approach the question with intellectual curiosity rather than frustration. My intuition is that the core reason is that the security dimension of this work is non-intuitive and poorly understood.
My hunch is that if you asked a bunch of random people about what sort of engineering work might be needed to support more interactive content on Wikipedia, the answers you will get will be disproportionately focused on missing user-facing interfaces and functionality for editing and displaying such content. And if that's your view, it is very natural for various assumptions to follow about what sort of expertise is required. But it's the wrong view and the wrong assumptions.
The critical issue is *security*. Security is the reason the graph extension is not enabled. Security is the reason why interactive SVGs are not enabled. Interactive visualizations have a programmatic element that consists of code that executes in the user's browser. Such code needs to be carefully sandboxed to ensure it cannot be used to exfiltrate user data or surreptitiously perform actions on wiki.
The bar for shipping security-critical features is high. You can ship code with crummy UX and iterate on it. But something that touches security requires a higher amount of up-front technical design work and close scrutiny in the form of peer review. And this means that it cannot progress spontaneously, through sporadic bursts of effort here and there (which is how a lot of engineering work happens) but requires a solid commitment of focused attention from multiple people with relevant expertise.
There are engineers at the Wikimedia Foundation and in the technical contributor community with the relevant expertise but as a rule they are extremely oversubscribed. My recommendation would be to engage them in crafting a job description for this role and in reviewing candidates.
On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh ori.livneh@gmail.com wrote:
If we're collecting exemplars, I'd like to add Bartosz Ciechanowski's superlative articles https://ciechanow.ski/archives/, like the ones on bicycles https://ciechanow.ski/bicycle/ and sound https://ciechanow.ski/sound/. His articles are the best examples I know of interactive content that complements long-form text content.
This concept was popularized by Bret Victor under the name "explorable explanations http://worrydream.com/ExplorableExplanations/". There is a whole Wikipedia article https://en.wikipedia.org/wiki/Explorable_explanation on it. There are some great examples on his website, and there are some websites for collecting similar content, such as explorabl.es and an awesome list https://github.com/blob42/awesome-explorables. I agree they are really cool but...
The critical issue is *security*. Security is the reason the graph extension is not enabled. Security is the reason why interactive SVGs are not enabled. Interactive visualizations have a programmatic element that consists of code that executes in the user's browser. Such code needs to be carefully sandboxed to ensure it cannot be used to exfiltrate user data or surreptitiously perform actions on wiki.
I think it's fundamentally a human scaling problem. Being able to create good interactive content is just a much more niche skill than being able to create good text content. Interactive animations were very much part of Yuri's vision https://meta.wikimedia.org/wiki/User:Yurik/I_Dream_of_Content for the Graph extension, but during the decade Graph was deployed in production the number of such animations made was approximately zero. Granted Vega is probably not the easiest framework for creating animations, but I don't think there are other tools which would make it much easier. You could just write arbitrary Javascript and package it as a gadget; but no one did that either. Instead, both gadgets and Graph usage are mostly focused on very basic things like showing a chess board or showing bar charts, because those are the things that can be reused across a large number of articles without manually tailoring the code to each, so the economics of creating them work out.
Security is a challenge but could be worked around via iframes. But it's hard to justify the effort required for doing that when there is no community of animation makers interested in it - there are plenty of volunteers who want to *have* animations, but it's not very clear that there are any who want to *make* animations. This is the same problem geni mentioned for videos - a lot of people say "we should have more videos", but it's not very clear who would make them. If platform support were the bottleneck here, I think the platform support would happen. But as things look now, it would just be a poor investment of resources IMO (compared to e.g. the Gadgets extension or Toolforge or Scribunto which do sustain vibrant volunteer ecosystems which are significantly held back by the limitations of these platforms).
On Wed, Jan 31, 2024 at 1:27 AM Gergő Tisza gtisza@gmail.com wrote:
On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh ori.livneh@gmail.com wrote:
If we're collecting exemplars, I'd like to add Bartosz Ciechanowski's superlative articles https://ciechanow.ski/archives/, like the ones on bicycles https://ciechanow.ski/bicycle/ and sound https://ciechanow.ski/sound/. His articles are the best examples I know of interactive content that complements long-form text content.
This concept was popularized by Bret Victor under the name "explorable explanations http://worrydream.com/ExplorableExplanations/". There is a whole Wikipedia article https://en.wikipedia.org/wiki/Explorable_explanation on it. There are some great examples on his website, and there are some websites for collecting similar content, such as explorabl.es and an awesome list https://github.com/blob42/awesome-explorables. I agree they are really cool but...
The critical issue is *security*. Security is the reason the graph extension is not enabled. Security is the reason why interactive SVGs are not enabled. Interactive visualizations have a programmatic element that consists of code that executes in the user's browser. Such code needs to be carefully sandboxed to ensure it cannot be used to exfiltrate user data or surreptitiously perform actions on wiki.
I think it's fundamentally a human scaling problem. Being able to create good interactive content is just a much more niche skill than being able to create good text content. Interactive animations were very much part of Yuri's vision https://meta.wikimedia.org/wiki/User:Yurik/I_Dream_of_Content for the Graph extension, but during the decade Graph was deployed in production the number of such animations made was approximately zero. Granted Vega is probably not the easiest framework for creating animations, but I don't think there are other tools which would make it much easier. You could just write arbitrary Javascript and package it as a gadget; but no one did that either. Instead, both gadgets and Graph usage are mostly focused on very basic things like showing a chess board or showing bar charts, because those are the things that can be reused across a large number of articles without manually tailoring the code to each, so the economics of creating them work out.
Security is a challenge but could be worked around via iframes. But it's hard to justify the effort required for doing that when there is no community of animation makers interested in it - there are plenty of volunteers who want to *have* animations, but it's not very clear that there are any who want to *make* animations. This is the same problem geni mentioned for videos - a lot of people say "we should have more videos", but it's not very clear who would make them. If platform support were the bottleneck here, I think the platform support would happen. But as things look now, it would just be a poor investment of resources IMO (compared to e.g. the Gadgets extension or Toolforge or Scribunto which do sustain vibrant volunteer ecosystems which are significantly held back by the limitations of these platforms).
thank you for sharing ori and gergo. coming from i opened the page "how to tune a guitar": https://mathisonian.github.io/idyll/how-to-tune-a-guitar/, and the readings about "reinventing human explanations" and so on: https://explorabl.es/reading/. the sheer number of examples is saw out of these links does not sound like there is a lack of persons who love to do that.
rupert
I also think the WMF should prioritize hiring more developers over other roles and expenditures. The WMF has only a few hundred developers while other top sites have many thousands. While this efficiency is something to be proud of, it evidently comes at a cost.
El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER < rupert.thurner@gmail.com> escribió:
On Wed, Jan 31, 2024 at 1:27 AM Gergő Tisza gtisza@gmail.com wrote:
On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh ori.livneh@gmail.com wrote:
If we're collecting exemplars, I'd like to add Bartosz Ciechanowski's superlative articles https://ciechanow.ski/archives/, like the ones on bicycles https://ciechanow.ski/bicycle/ and sound https://ciechanow.ski/sound/. His articles are the best examples I know of interactive content that complements long-form text content.
This concept was popularized by Bret Victor under the name "explorable explanations http://worrydream.com/ExplorableExplanations/". There is a whole Wikipedia article https://en.wikipedia.org/wiki/Explorable_explanation on it. There are some great examples on his website, and there are some websites for collecting similar content, such as explorabl.es and an awesome list https://github.com/blob42/awesome-explorables. I agree they are really cool but...
The critical issue is *security*. Security is the reason the graph extension is not enabled. Security is the reason why interactive SVGs are not enabled. Interactive visualizations have a programmatic element that consists of code that executes in the user's browser. Such code needs to be carefully sandboxed to ensure it cannot be used to exfiltrate user data or surreptitiously perform actions on wiki.
I think it's fundamentally a human scaling problem. Being able to create good interactive content is just a much more niche skill than being able to create good text content. Interactive animations were very much part of Yuri's vision https://meta.wikimedia.org/wiki/User:Yurik/I_Dream_of_Content for the Graph extension, but during the decade Graph was deployed in production the number of such animations made was approximately zero. Granted Vega is probably not the easiest framework for creating animations, but I don't think there are other tools which would make it much easier. You could just write arbitrary Javascript and package it as a gadget; but no one did that either. Instead, both gadgets and Graph usage are mostly focused on very basic things like showing a chess board or showing bar charts, because those are the things that can be reused across a large number of articles without manually tailoring the code to each, so the economics of creating them work out.
Security is a challenge but could be worked around via iframes. But it's hard to justify the effort required for doing that when there is no community of animation makers interested in it - there are plenty of volunteers who want to *have* animations, but it's not very clear that there are any who want to *make* animations. This is the same problem geni mentioned for videos - a lot of people say "we should have more videos", but it's not very clear who would make them. If platform support were the bottleneck here, I think the platform support would happen. But as things look now, it would just be a poor investment of resources IMO (compared to e.g. the Gadgets extension or Toolforge or Scribunto which do sustain vibrant volunteer ecosystems which are significantly held back by the limitations of these platforms).
thank you for sharing ori and gergo. coming from i opened the page "how to tune a guitar": https://mathisonian.github.io/idyll/how-to-tune-a-guitar/, and the readings about "reinventing human explanations" and so on: https://explorabl.es/reading/. the sheer number of examples is saw out of these links does not sound like there is a lack of persons who love to do that.
rupert _______________________________________________ Wikimedia-l mailing list -- 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
Before the WMF starts hiring, we need to be very clear exactly what pathways and objectives we want to pursue, along with what functions should be internally maintained. With that what happens with community built tools that cross over from great tools to essential community infrastructure that needs continued updates. Perhaps part of the "hiring" option is rewarding volunteers who create them to help transition the tool to the internal system.
On Thu, 1 Feb 2024 at 01:35, Felipe Schenone schenonef@gmail.com wrote:
I also think the WMF should prioritize hiring more developers over other roles and expenditures. The WMF has only a few hundred developers while other top sites have many thousands. While this efficiency is something to be proud of, it evidently comes at a cost.
El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER < rupert.thurner@gmail.com> escribió:
On Wed, Jan 31, 2024 at 1:27 AM Gergő Tisza gtisza@gmail.com wrote:
On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh ori.livneh@gmail.com wrote:
If we're collecting exemplars, I'd like to add Bartosz Ciechanowski's superlative articles https://ciechanow.ski/archives/, like the ones on bicycles https://ciechanow.ski/bicycle/ and sound https://ciechanow.ski/sound/. His articles are the best examples I know of interactive content that complements long-form text content.
This concept was popularized by Bret Victor under the name "explorable explanations http://worrydream.com/ExplorableExplanations/". There is a whole Wikipedia article https://en.wikipedia.org/wiki/Explorable_explanation on it. There are some great examples on his website, and there are some websites for collecting similar content, such as explorabl.es and an awesome list https://github.com/blob42/awesome-explorables. I agree they are really cool but...
The critical issue is *security*. Security is the reason the graph extension is not enabled. Security is the reason why interactive SVGs are not enabled. Interactive visualizations have a programmatic element that consists of code that executes in the user's browser. Such code needs to be carefully sandboxed to ensure it cannot be used to exfiltrate user data or surreptitiously perform actions on wiki.
I think it's fundamentally a human scaling problem. Being able to create good interactive content is just a much more niche skill than being able to create good text content. Interactive animations were very much part of Yuri's vision https://meta.wikimedia.org/wiki/User:Yurik/I_Dream_of_Content for the Graph extension, but during the decade Graph was deployed in production the number of such animations made was approximately zero. Granted Vega is probably not the easiest framework for creating animations, but I don't think there are other tools which would make it much easier. You could just write arbitrary Javascript and package it as a gadget; but no one did that either. Instead, both gadgets and Graph usage are mostly focused on very basic things like showing a chess board or showing bar charts, because those are the things that can be reused across a large number of articles without manually tailoring the code to each, so the economics of creating them work out.
Security is a challenge but could be worked around via iframes. But it's hard to justify the effort required for doing that when there is no community of animation makers interested in it - there are plenty of volunteers who want to *have* animations, but it's not very clear that there are any who want to *make* animations. This is the same problem geni mentioned for videos - a lot of people say "we should have more videos", but it's not very clear who would make them. If platform support were the bottleneck here, I think the platform support would happen. But as things look now, it would just be a poor investment of resources IMO (compared to e.g. the Gadgets extension or Toolforge or Scribunto which do sustain vibrant volunteer ecosystems which are significantly held back by the limitations of these platforms).
thank you for sharing ori and gergo. coming from i opened the page "how to tune a guitar": https://mathisonian.github.io/idyll/how-to-tune-a-guitar/, and the readings about "reinventing human explanations" and so on: https://explorabl.es/reading/. the sheer number of examples is saw out of these links does not sound like there is a lack of persons who love to do that.
rupert _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Well, perhaps you'll be elated to know then that the grants for tech seem to have been removed https://meta.wikimedia.org/w/index.php?title=Grants:Start&diff=prev&oldid=26136082 after many months of waiting for them https://meta.wikimedia.org/wiki/Grants_talk:Start#Timeline_for_%22Wikimedia_Technology_Fund%22 . We're doing it wrong, indeed.
El mié., 31 de ene. de 2024 11:02 p. m., Gnangarra gnangarra@gmail.com escribió:
Before the WMF starts hiring, we need to be very clear exactly what pathways and objectives we want to pursue, along with what functions should be internally maintained. With that what happens with community built tools that cross over from great tools to essential community infrastructure that needs continued updates. Perhaps part of the "hiring" option is rewarding volunteers who create them to help transition the tool to the internal system.
On Thu, 1 Feb 2024 at 01:35, Felipe Schenone schenonef@gmail.com wrote:
I also think the WMF should prioritize hiring more developers over other roles and expenditures. The WMF has only a few hundred developers while other top sites have many thousands. While this efficiency is something to be proud of, it evidently comes at a cost.
El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER < rupert.thurner@gmail.com> escribió:
On Wed, Jan 31, 2024 at 1:27 AM Gergő Tisza gtisza@gmail.com wrote:
On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh ori.livneh@gmail.com wrote:
If we're collecting exemplars, I'd like to add Bartosz Ciechanowski's superlative articles https://ciechanow.ski/archives/, like the ones on bicycles https://ciechanow.ski/bicycle/ and sound https://ciechanow.ski/sound/. His articles are the best examples I know of interactive content that complements long-form text content.
This concept was popularized by Bret Victor under the name "explorable explanations http://worrydream.com/ExplorableExplanations/". There is a whole Wikipedia article https://en.wikipedia.org/wiki/Explorable_explanation on it. There are some great examples on his website, and there are some websites for collecting similar content, such as explorabl.es and an awesome list https://github.com/blob42/awesome-explorables. I agree they are really cool but...
The critical issue is *security*. Security is the reason the graph extension is not enabled. Security is the reason why interactive SVGs are not enabled. Interactive visualizations have a programmatic element that consists of code that executes in the user's browser. Such code needs to be carefully sandboxed to ensure it cannot be used to exfiltrate user data or surreptitiously perform actions on wiki.
I think it's fundamentally a human scaling problem. Being able to create good interactive content is just a much more niche skill than being able to create good text content. Interactive animations were very much part of Yuri's vision https://meta.wikimedia.org/wiki/User:Yurik/I_Dream_of_Content for the Graph extension, but during the decade Graph was deployed in production the number of such animations made was approximately zero. Granted Vega is probably not the easiest framework for creating animations, but I don't think there are other tools which would make it much easier. You could just write arbitrary Javascript and package it as a gadget; but no one did that either. Instead, both gadgets and Graph usage are mostly focused on very basic things like showing a chess board or showing bar charts, because those are the things that can be reused across a large number of articles without manually tailoring the code to each, so the economics of creating them work out.
Security is a challenge but could be worked around via iframes. But it's hard to justify the effort required for doing that when there is no community of animation makers interested in it - there are plenty of volunteers who want to *have* animations, but it's not very clear that there are any who want to *make* animations. This is the same problem geni mentioned for videos - a lot of people say "we should have more videos", but it's not very clear who would make them. If platform support were the bottleneck here, I think the platform support would happen. But as things look now, it would just be a poor investment of resources IMO (compared to e.g. the Gadgets extension or Toolforge or Scribunto which do sustain vibrant volunteer ecosystems which are significantly held back by the limitations of these platforms).
thank you for sharing ori and gergo. coming from i opened the page "how to tune a guitar": https://mathisonian.github.io/idyll/how-to-tune-a-guitar/, and the readings about "reinventing human explanations" and so on: https://explorabl.es/reading/. the sheer number of examples is saw out of these links does not sound like there is a lack of persons who love to do that.
rupert _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
WMF is doing it wrong, not we. Many people in the movement have been alerting to this situation over the years, apparently to deaf ears.
Paulo
Felipe Schenone schenonef@gmail.com escreveu (quinta, 1/02/2024 à(s) 07:09):
Well, perhaps you'll be elated to know then that the grants for tech seem to have been removed https://meta.wikimedia.org/w/index.php?title=Grants:Start&diff=prev&oldid=26136082 after many months of waiting for them https://meta.wikimedia.org/wiki/Grants_talk:Start#Timeline_for_%22Wikimedia_Technology_Fund%22 . We're doing it wrong, indeed.
El mié., 31 de ene. de 2024 11:02 p. m., Gnangarra gnangarra@gmail.com escribió:
Before the WMF starts hiring, we need to be very clear exactly what pathways and objectives we want to pursue, along with what functions should be internally maintained. With that what happens with community built tools that cross over from great tools to essential community infrastructure that needs continued updates. Perhaps part of the "hiring" option is rewarding volunteers who create them to help transition the tool to the internal system.
On Thu, 1 Feb 2024 at 01:35, Felipe Schenone schenonef@gmail.com wrote:
I also think the WMF should prioritize hiring more developers over other roles and expenditures. The WMF has only a few hundred developers while other top sites have many thousands. While this efficiency is something to be proud of, it evidently comes at a cost.
El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER < rupert.thurner@gmail.com> escribió:
On Wed, Jan 31, 2024 at 1:27 AM Gergő Tisza gtisza@gmail.com wrote:
On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh ori.livneh@gmail.com wrote:
If we're collecting exemplars, I'd like to add Bartosz Ciechanowski's superlative articles https://ciechanow.ski/archives/, like the ones on bicycles https://ciechanow.ski/bicycle/ and sound https://ciechanow.ski/sound/. His articles are the best examples I know of interactive content that complements long-form text content.
This concept was popularized by Bret Victor under the name "explorable explanations http://worrydream.com/ExplorableExplanations/". There is a whole Wikipedia article https://en.wikipedia.org/wiki/Explorable_explanation on it. There are some great examples on his website, and there are some websites for collecting similar content, such as explorabl.es and an awesome list https://github.com/blob42/awesome-explorables. I agree they are really cool but...
The critical issue is *security*. Security is the reason the graph extension is not enabled. Security is the reason why interactive SVGs are not enabled. Interactive visualizations have a programmatic element that consists of code that executes in the user's browser. Such code needs to be carefully sandboxed to ensure it cannot be used to exfiltrate user data or surreptitiously perform actions on wiki.
I think it's fundamentally a human scaling problem. Being able to create good interactive content is just a much more niche skill than being able to create good text content. Interactive animations were very much part of Yuri's vision https://meta.wikimedia.org/wiki/User:Yurik/I_Dream_of_Content for the Graph extension, but during the decade Graph was deployed in production the number of such animations made was approximately zero. Granted Vega is probably not the easiest framework for creating animations, but I don't think there are other tools which would make it much easier. You could just write arbitrary Javascript and package it as a gadget; but no one did that either. Instead, both gadgets and Graph usage are mostly focused on very basic things like showing a chess board or showing bar charts, because those are the things that can be reused across a large number of articles without manually tailoring the code to each, so the economics of creating them work out.
Security is a challenge but could be worked around via iframes. But it's hard to justify the effort required for doing that when there is no community of animation makers interested in it - there are plenty of volunteers who want to *have* animations, but it's not very clear that there are any who want to *make* animations. This is the same problem geni mentioned for videos - a lot of people say "we should have more videos", but it's not very clear who would make them. If platform support were the bottleneck here, I think the platform support would happen. But as things look now, it would just be a poor investment of resources IMO (compared to e.g. the Gadgets extension or Toolforge or Scribunto which do sustain vibrant volunteer ecosystems which are significantly held back by the limitations of these platforms).
thank you for sharing ori and gergo. coming from i opened the page "how to tune a guitar": https://mathisonian.github.io/idyll/how-to-tune-a-guitar/, and the readings about "reinventing human explanations" and so on: https://explorabl.es/reading/. the sheer number of examples is saw out of these links does not sound like there is a lack of persons who love to do that.
rupert _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
We at Wiki Project Med Foundation are looking for contractors to work on aspects of this problem. Reach out if you are interested.
James
On Thu, Feb 1, 2024 at 3:32 AM Paulo Santos Perneta paulosperneta@gmail.com wrote:
WMF is doing it wrong, not we. Many people in the movement have been alerting to this situation over the years, apparently to deaf ears.
Paulo
Felipe Schenone schenonef@gmail.com escreveu (quinta, 1/02/2024 à(s) 07:09):
Well, perhaps you'll be elated to know then that the grants for tech seem to have been removed https://meta.wikimedia.org/w/index.php?title=Grants:Start&diff=prev&oldid=26136082 after many months of waiting for them https://meta.wikimedia.org/wiki/Grants_talk:Start#Timeline_for_%22Wikimedia_Technology_Fund%22 . We're doing it wrong, indeed.
El mié., 31 de ene. de 2024 11:02 p. m., Gnangarra gnangarra@gmail.com escribió:
Before the WMF starts hiring, we need to be very clear exactly what pathways and objectives we want to pursue, along with what functions should be internally maintained. With that what happens with community built tools that cross over from great tools to essential community infrastructure that needs continued updates. Perhaps part of the "hiring" option is rewarding volunteers who create them to help transition the tool to the internal system.
On Thu, 1 Feb 2024 at 01:35, Felipe Schenone schenonef@gmail.com wrote:
I also think the WMF should prioritize hiring more developers over other roles and expenditures. The WMF has only a few hundred developers while other top sites have many thousands. While this efficiency is something to be proud of, it evidently comes at a cost.
El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER < rupert.thurner@gmail.com> escribió:
On Wed, Jan 31, 2024 at 1:27 AM Gergő Tisza gtisza@gmail.com wrote:
On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh ori.livneh@gmail.com wrote:
> If we're collecting exemplars, I'd like to add Bartosz > Ciechanowski's superlative articles > https://ciechanow.ski/archives/, like the ones on bicycles > https://ciechanow.ski/bicycle/ and sound > https://ciechanow.ski/sound/. His articles are the best examples > I know of interactive content that complements long-form text content. >
This concept was popularized by Bret Victor under the name "explorable explanations http://worrydream.com/ExplorableExplanations/". There is a whole Wikipedia article https://en.wikipedia.org/wiki/Explorable_explanation on it. There are some great examples on his website, and there are some websites for collecting similar content, such as explorabl.es and an awesome list https://github.com/blob42/awesome-explorables. I agree they are really cool but...
> The critical issue is *security*. Security is the reason the graph > extension is not enabled. Security is the reason why interactive SVGs are > not enabled. Interactive visualizations have a programmatic element that > consists of code that executes in the user's browser. Such code needs to be > carefully sandboxed to ensure it cannot be used to exfiltrate user data or > surreptitiously perform actions on wiki. >
I think it's fundamentally a human scaling problem. Being able to create good interactive content is just a much more niche skill than being able to create good text content. Interactive animations were very much part of Yuri's vision https://meta.wikimedia.org/wiki/User:Yurik/I_Dream_of_Content for the Graph extension, but during the decade Graph was deployed in production the number of such animations made was approximately zero. Granted Vega is probably not the easiest framework for creating animations, but I don't think there are other tools which would make it much easier. You could just write arbitrary Javascript and package it as a gadget; but no one did that either. Instead, both gadgets and Graph usage are mostly focused on very basic things like showing a chess board or showing bar charts, because those are the things that can be reused across a large number of articles without manually tailoring the code to each, so the economics of creating them work out.
Security is a challenge but could be worked around via iframes. But it's hard to justify the effort required for doing that when there is no community of animation makers interested in it - there are plenty of volunteers who want to *have* animations, but it's not very clear that there are any who want to *make* animations. This is the same problem geni mentioned for videos - a lot of people say "we should have more videos", but it's not very clear who would make them. If platform support were the bottleneck here, I think the platform support would happen. But as things look now, it would just be a poor investment of resources IMO (compared to e.g. the Gadgets extension or Toolforge or Scribunto which do sustain vibrant volunteer ecosystems which are significantly held back by the limitations of these platforms).
thank you for sharing ori and gergo. coming from i opened the page "how to tune a guitar": https://mathisonian.github.io/idyll/how-to-tune-a-guitar/, and the readings about "reinventing human explanations" and so on: https://explorabl.es/reading/. the sheer number of examples is saw out of these links does not sound like there is a lack of persons who love to do that.
rupert _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate!
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon. https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
---------------------
On Wed, Feb 7, 2024, 09:17 Gnangarra gnangarra@gmail.com wrote:
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate ! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Hi everyone, good news!
Thanks to this humble change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipedia https://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgets https://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk page https://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui danboy12342@gmail.com wrote:
Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
On Wed, Feb 7, 2024, 09:17 Gnangarra gnangarra@gmail.com wrote:
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate ! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder ________________________________ From: Felipe Schenone schenonef@gmail.com Sent: Friday, March 22, 2024 10:39 PM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble changehttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipediahttps://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgetshttps://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk pagehttps://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui <danboy12342@gmail.commailto:danboy12342@gmail.com> wrote: Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
---------------------
On Wed, Feb 7, 2024, 09:17 Gnangarra <gnangarra@gmail.commailto:gnangarra@gmail.com> wrote: Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria <bustrias@gmail.commailto:bustrias@gmail.com> wrote: Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon. https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
Butch Bustria
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber <bvibber@wikimedia.orgmailto:bvibber@wikimedia.org> wrote: Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM <mmiller@wikimedia.orgmailto:mmiller@wikimedia.org> wrote: Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
Hi Galder, I just did this fix https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder
*From:* Felipe Schenone schenonef@gmail.com *Sent:* Friday, March 22, 2024 10:39 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipedia https://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgets https://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk page https://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui danboy12342@gmail.com wrote:
Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
On Wed, Feb 7, 2024, 09:17 Gnangarra gnangarra@gmail.com wrote:
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone schenonef@gmail.com wrote:
Hi Galder, I just did this fix https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder
*From:* Felipe Schenone schenonef@gmail.com *Sent:* Friday, March 22, 2024 10:39 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipedia https://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgets https://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk page https://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui danboy12342@gmail.com wrote:
Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
On Wed, Feb 7, 2024, 09:17 Gnangarra gnangarra@gmail.com wrote:
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Dear all, Soon it will be a year since the Graph extension is disabled in all wikis. Meanwhile, we have been discussing about interactive content here and there, and there have been some promises about changes in the platform so these changes are possible in the future.
Today the draft of the Key Results for the 2024-2025 annual plan was published and there's no single mention to this, nor to improving the multimedia experience. The disconnection between the needs and the plans is so evident, that I don't really know why we even bother discussing. You can see the Key Results here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P...https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs.
This is extremely disappointing.
Best, Galder
________________________________ From: Samuel Klein meta.sj@gmail.com Sent: Saturday, March 23, 2024 3:37 PM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone <schenonef@gmail.commailto:schenonef@gmail.com> wrote: Hi Galder, I just did this fixhttps://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder ________________________________ From: Felipe Schenone <schenonef@gmail.commailto:schenonef@gmail.com> Sent: Friday, March 22, 2024 10:39 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble changehttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipediahttps://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgetshttps://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk pagehttps://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui <danboy12342@gmail.commailto:danboy12342@gmail.com> wrote: Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
---------------------
On Wed, Feb 7, 2024, 09:17 Gnangarra <gnangarra@gmail.commailto:gnangarra@gmail.com> wrote: Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria <bustrias@gmail.commailto:bustrias@gmail.com> wrote: Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon. https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
Butch Bustria
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber <bvibber@wikimedia.orgmailto:bvibber@wikimedia.org> wrote: Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM <mmiller@wikimedia.orgmailto:mmiller@wikimedia.org> wrote: Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
I would agree that no mention in the OKR would be quite disturbing... However the 2024 report is NOT out yet, these are draft issues and I would not make judgement until the full report is ready, which i believe to be april.
------------------------------ Dear All,
I understand the frustration around the lack of progress on interactive content and the discontinuation of the Graph extension. However, I'd like to point out a few things.
First, the response from staff members reaching out to editors for their opinions was remarkably quick. This type of response is not common, and Wikipedia is unique in its hands-on approach to issues like this, it is something to be proud of and also something that takes time.
Second, the Graph tool is being overhauled rather than patched. This is a significant undertaking that will bring all our tools into the modern age, making them more accessible and removing the underlying vulnerabilities that led to the current situation in the first place, it will also ensure the tool is up-to-date in terms of UX through things like codex and other modern improvements that long term will allow more users to create graphs which hopefully will keep it a priority to maintain, again thinking long term here.
I know that this is taking time, but I believe that developing a robust and sustainable solution is the best approach. Doing it this way rather than delaying it for another six months is something I'd rather have and I'd like to thank the hard working wikimedia team for that.
Thanks, Daniel
On Tue, Mar 26, 2024 at 8:03 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Dear all, Soon it will be a year since the Graph extension is disabled in all wikis. Meanwhile, we have been discussing about interactive content here and there, and there have been some promises about changes in the platform so these changes are possible in the future.
Today the draft of the Key Results for the 2024-2025 annual plan was published and there's no single mention to this, nor to improving the multimedia experience. The disconnection between the needs and the plans is so evident, that I don't really know why we even bother discussing. You can see the Key Results here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P... https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs .
This is extremely disappointing.
Best, Galder
*From:* Samuel Klein meta.sj@gmail.com *Sent:* Saturday, March 23, 2024 3:37 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone schenonef@gmail.com wrote:
Hi Galder, I just did this fix https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder
*From:* Felipe Schenone schenonef@gmail.com *Sent:* Friday, March 22, 2024 10:39 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipedia https://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgets https://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk page https://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui danboy12342@gmail.com wrote:
Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
On Wed, Feb 7, 2024, 09:17 Gnangarra gnangarra@gmail.com wrote:
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Has this discussion impacted somehow on the WMF's approach to the future.
Well, today we had the answer: https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#c-Mark_Bergsma_(WMF)-202406...
(TL;DR: no)
Galder ________________________________ From: Daniel Mui danboy12342@gmail.com Sent: Tuesday, March 26, 2024 9:40 PM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
I would agree that no mention in the OKR would be quite disturbing... However the 2024 report is NOT out yet, these are draft issues and I would not make judgement until the full report is ready, which i believe to be april.
________________________________ Dear All,
I understand the frustration around the lack of progress on interactive content and the discontinuation of the Graph extension. However, I'd like to point out a few things.
First, the response from staff members reaching out to editors for their opinions was remarkably quick. This type of response is not common, and Wikipedia is unique in its hands-on approach to issues like this, it is something to be proud of and also something that takes time.
Second, the Graph tool is being overhauled rather than patched. This is a significant undertaking that will bring all our tools into the modern age, making them more accessible and removing the underlying vulnerabilities that led to the current situation in the first place, it will also ensure the tool is up-to-date in terms of UX through things like codex and other modern improvements that long term will allow more users to create graphs which hopefully will keep it a priority to maintain, again thinking long term here.
I know that this is taking time, but I believe that developing a robust and sustainable solution is the best approach. Doing it this way rather than delaying it for another six months is something I'd rather have and I'd like to thank the hard working wikimedia team for that.
Thanks, Daniel
On Tue, Mar 26, 2024 at 8:03 PM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: Dear all, Soon it will be a year since the Graph extension is disabled in all wikis. Meanwhile, we have been discussing about interactive content here and there, and there have been some promises about changes in the platform so these changes are possible in the future.
Today the draft of the Key Results for the 2024-2025 annual plan was published and there's no single mention to this, nor to improving the multimedia experience. The disconnection between the needs and the plans is so evident, that I don't really know why we even bother discussing. You can see the Key Results here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P...https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs.
This is extremely disappointing.
Best, Galder
________________________________ From: Samuel Klein <meta.sj@gmail.commailto:meta.sj@gmail.com> Sent: Saturday, March 23, 2024 3:37 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone <schenonef@gmail.commailto:schenonef@gmail.com> wrote: Hi Galder, I just did this fixhttps://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder ________________________________ From: Felipe Schenone <schenonef@gmail.commailto:schenonef@gmail.com> Sent: Friday, March 22, 2024 10:39 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble changehttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipediahttps://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgetshttps://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk pagehttps://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui <danboy12342@gmail.commailto:danboy12342@gmail.com> wrote: Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
---------------------
On Wed, Feb 7, 2024, 09:17 Gnangarra <gnangarra@gmail.commailto:gnangarra@gmail.com> wrote: Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria <bustrias@gmail.commailto:bustrias@gmail.com> wrote: Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon. https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
Butch Bustria
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber <bvibber@wikimedia.orgmailto:bvibber@wikimedia.org> wrote: Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM <mmiller@wikimedia.orgmailto:mmiller@wikimedia.org> wrote: Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
Hi,
Just as a practical question in terms of what has been already done. As it seems that all proposals where extension will require external connections outside of Wikimedia production sites are no-go the feasible next step would be to modify the OurWorldInData extension so that it would load the graph data from Wikimedia commons. Is this already done even for a limited number of example graphs? If not then this could be the next step and then ask for a new security review on this approach.
Though, even after it is solved that extension doesn't need external connections outside wikimedia production it still would require some level code review that OWID grapher doesn't do anything unexpected.
Data itself in least some extend is in Commons - https://commons.wikimedia.org/wiki/Category:Our_World_in_Data_datasets
The OurWorldInData grapher - https://github.com/owid/owid-grapher/tree/master/packages/%40ourworldindata/...
Application Security Review Request : OurWorldInData - https://phabricator.wikimedia.org/T324989
Br, -- Kimmo Virtanen, Zache
On Thu, Jun 6, 2024 at 6:46 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Has this discussion impacted somehow on the WMF's approach to the future.
Well, today we had the answer: https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#c-Mark_Bergsma_(WMF)-202406...
(TL;DR: no)
Galder
*From:* Daniel Mui danboy12342@gmail.com *Sent:* Tuesday, March 26, 2024 9:40 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
I would agree that no mention in the OKR would be quite disturbing... However the 2024 report is NOT out yet, these are draft issues and I would not make judgement until the full report is ready, which i believe to be april.
Dear All,
I understand the frustration around the lack of progress on interactive content and the discontinuation of the Graph extension. However, I'd like to point out a few things.
First, the response from staff members reaching out to editors for their opinions was remarkably quick. This type of response is not common, and Wikipedia is unique in its hands-on approach to issues like this, it is something to be proud of and also something that takes time.
Second, the Graph tool is being overhauled rather than patched. This is a significant undertaking that will bring all our tools into the modern age, making them more accessible and removing the underlying vulnerabilities that led to the current situation in the first place, it will also ensure the tool is up-to-date in terms of UX through things like codex and other modern improvements that long term will allow more users to create graphs which hopefully will keep it a priority to maintain, again thinking long term here.
I know that this is taking time, but I believe that developing a robust and sustainable solution is the best approach. Doing it this way rather than delaying it for another six months is something I'd rather have and I'd like to thank the hard working wikimedia team for that.
Thanks, Daniel
On Tue, Mar 26, 2024 at 8:03 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Dear all, Soon it will be a year since the Graph extension is disabled in all wikis. Meanwhile, we have been discussing about interactive content here and there, and there have been some promises about changes in the platform so these changes are possible in the future.
Today the draft of the Key Results for the 2024-2025 annual plan was published and there's no single mention to this, nor to improving the multimedia experience. The disconnection between the needs and the plans is so evident, that I don't really know why we even bother discussing. You can see the Key Results here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P... https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs .
This is extremely disappointing.
Best, Galder
*From:* Samuel Klein meta.sj@gmail.com *Sent:* Saturday, March 23, 2024 3:37 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone schenonef@gmail.com wrote:
Hi Galder, I just did this fix https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder
*From:* Felipe Schenone schenonef@gmail.com *Sent:* Friday, March 22, 2024 10:39 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipedia https://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgets https://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk page https://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui danboy12342@gmail.com wrote:
Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
On Wed, Feb 7, 2024, 09:17 Gnangarra gnangarra@gmail.com wrote:
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Yah, not sure what Bergsma (WMF) https://meta.wikimedia.org/wiki/User:Mark_Bergsma_(WMF) is trying to say... No one is dismissing security or privacy. One; however, does need to balance risk versus benefit and of course mitigate security and privacy issues along the way. Allowing fear of security or privacy risks to paralyse us is also not ideal.
Kimmo for sure we could internalize everything ie run their software on production servers, we already host their data on Commons (that was a many year effort). Made the request 8 or so years ago to host their software in fact, but the WMF dissolved the team / individual working on this effort. I still think that is a reasonable way forwards.
James
On Thu, Jun 6, 2024 at 8:03 PM Kimmo Virtanen kimmo.virtanen@wikimedia.fi wrote:
Hi,
Just as a practical question in terms of what has been already done. As it seems that all proposals where extension will require external connections outside of Wikimedia production sites are no-go the feasible next step would be to modify the OurWorldInData extension so that it would load the graph data from Wikimedia commons. Is this already done even for a limited number of example graphs? If not then this could be the next step and then ask for a new security review on this approach.
Though, even after it is solved that extension doesn't need external connections outside wikimedia production it still would require some level code review that OWID grapher doesn't do anything unexpected.
Data itself in least some extend is in Commons
The OurWorldInData grapher
https://github.com/owid/owid-grapher/tree/master/packages/%40ourworldindata/...
Application Security Review Request : OurWorldInData
Br, -- Kimmo Virtanen, Zache
On Thu, Jun 6, 2024 at 6:46 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Has this discussion impacted somehow on the WMF's approach to the future.
Well, today we had the answer: https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#c-Mark_Bergsma_(WMF)-202406...
(TL;DR: no)
Galder
*From:* Daniel Mui danboy12342@gmail.com *Sent:* Tuesday, March 26, 2024 9:40 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
I would agree that no mention in the OKR would be quite disturbing... However the 2024 report is NOT out yet, these are draft issues and I would not make judgement until the full report is ready, which i believe to be april.
Dear All,
I understand the frustration around the lack of progress on interactive content and the discontinuation of the Graph extension. However, I'd like to point out a few things.
First, the response from staff members reaching out to editors for their opinions was remarkably quick. This type of response is not common, and Wikipedia is unique in its hands-on approach to issues like this, it is something to be proud of and also something that takes time.
Second, the Graph tool is being overhauled rather than patched. This is a significant undertaking that will bring all our tools into the modern age, making them more accessible and removing the underlying vulnerabilities that led to the current situation in the first place, it will also ensure the tool is up-to-date in terms of UX through things like codex and other modern improvements that long term will allow more users to create graphs which hopefully will keep it a priority to maintain, again thinking long term here.
I know that this is taking time, but I believe that developing a robust and sustainable solution is the best approach. Doing it this way rather than delaying it for another six months is something I'd rather have and I'd like to thank the hard working wikimedia team for that.
Thanks, Daniel
On Tue, Mar 26, 2024 at 8:03 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Dear all, Soon it will be a year since the Graph extension is disabled in all wikis. Meanwhile, we have been discussing about interactive content here and there, and there have been some promises about changes in the platform so these changes are possible in the future.
Today the draft of the Key Results for the 2024-2025 annual plan was published and there's no single mention to this, nor to improving the multimedia experience. The disconnection between the needs and the plans is so evident, that I don't really know why we even bother discussing. You can see the Key Results here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P... https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs .
This is extremely disappointing.
Best, Galder
*From:* Samuel Klein meta.sj@gmail.com *Sent:* Saturday, March 23, 2024 3:37 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone schenonef@gmail.com wrote:
Hi Galder, I just did this fix https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder
*From:* Felipe Schenone schenonef@gmail.com *Sent:* Friday, March 22, 2024 10:39 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipedia https://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgets https://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk page https://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui danboy12342@gmail.com wrote:
Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
On Wed, Feb 7, 2024, 09:17 Gnangarra gnangarra@gmail.com wrote:
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
It doesn't matter what we think. It doesn't even matter if we collectively decide that we want to go on that direction. The WMF's Annual Plan and every single answer points that they don't mind.
We were doing it wrong one year ago. Now is even worse. Catastrophic, but not serious. ________________________________ From: James Heilman jmh649@gmail.com Sent: Thursday, June 6, 2024 9:09 PM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yah, not sure what Bergsma (WMF)https://meta.wikimedia.org/wiki/User:Mark_Bergsma_(WMF) is trying to say... No one is dismissing security or privacy. One; however, does need to balance risk versus benefit and of course mitigate security and privacy issues along the way. Allowing fear of security or privacy risks to paralyse us is also not ideal.
Kimmo for sure we could internalize everything ie run their software on production servers, we already host their data on Commons (that was a many year effort). Made the request 8 or so years ago to host their software in fact, but the WMF dissolved the team / individual working on this effort. I still think that is a reasonable way forwards.
James
On Thu, Jun 6, 2024 at 8:03 PM Kimmo Virtanen <kimmo.virtanen@wikimedia.fimailto:kimmo.virtanen@wikimedia.fi> wrote: Hi,
Just as a practical question in terms of what has been already done. As it seems that all proposals where extension will require external connections outside of Wikimedia production sites are no-go the feasible next step would be to modify the OurWorldInData extension so that it would load the graph data from Wikimedia commons. Is this already done even for a limited number of example graphs? If not then this could be the next step and then ask for a new security review on this approach.
Though, even after it is solved that extension doesn't need external connections outside wikimedia production it still would require some level code review that OWID grapher doesn't do anything unexpected.
Data itself in least some extend is in Commons - https://commons.wikimedia.org/wiki/Category:Our_World_in_Data_datasets
The OurWorldInData grapher - https://github.com/owid/owid-grapher/tree/master/packages/%40ourworldindata/...
Application Security Review Request : OurWorldInData - https://phabricator.wikimedia.org/T324989
Br, -- Kimmo Virtanen, Zache
On Thu, Jun 6, 2024 at 6:46 PM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: Has this discussion impacted somehow on the WMF's approach to the future.
Well, today we had the answer: https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#c-Mark_Bergsma_(WMF)-202406...
(TL;DR: no)
Galder ________________________________ From: Daniel Mui <danboy12342@gmail.commailto:danboy12342@gmail.com> Sent: Tuesday, March 26, 2024 9:40 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
I would agree that no mention in the OKR would be quite disturbing... However the 2024 report is NOT out yet, these are draft issues and I would not make judgement until the full report is ready, which i believe to be april.
________________________________ Dear All,
I understand the frustration around the lack of progress on interactive content and the discontinuation of the Graph extension. However, I'd like to point out a few things.
First, the response from staff members reaching out to editors for their opinions was remarkably quick. This type of response is not common, and Wikipedia is unique in its hands-on approach to issues like this, it is something to be proud of and also something that takes time.
Second, the Graph tool is being overhauled rather than patched. This is a significant undertaking that will bring all our tools into the modern age, making them more accessible and removing the underlying vulnerabilities that led to the current situation in the first place, it will also ensure the tool is up-to-date in terms of UX through things like codex and other modern improvements that long term will allow more users to create graphs which hopefully will keep it a priority to maintain, again thinking long term here.
I know that this is taking time, but I believe that developing a robust and sustainable solution is the best approach. Doing it this way rather than delaying it for another six months is something I'd rather have and I'd like to thank the hard working wikimedia team for that.
Thanks, Daniel
On Tue, Mar 26, 2024 at 8:03 PM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: Dear all, Soon it will be a year since the Graph extension is disabled in all wikis. Meanwhile, we have been discussing about interactive content here and there, and there have been some promises about changes in the platform so these changes are possible in the future.
Today the draft of the Key Results for the 2024-2025 annual plan was published and there's no single mention to this, nor to improving the multimedia experience. The disconnection between the needs and the plans is so evident, that I don't really know why we even bother discussing. You can see the Key Results here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P...https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs.
This is extremely disappointing.
Best, Galder
________________________________ From: Samuel Klein <meta.sj@gmail.commailto:meta.sj@gmail.com> Sent: Saturday, March 23, 2024 3:37 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone <schenonef@gmail.commailto:schenonef@gmail.com> wrote: Hi Galder, I just did this fixhttps://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder ________________________________ From: Felipe Schenone <schenonef@gmail.commailto:schenonef@gmail.com> Sent: Friday, March 22, 2024 10:39 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble changehttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipediahttps://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgetshttps://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk pagehttps://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui <danboy12342@gmail.commailto:danboy12342@gmail.com> wrote: Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
---------------------
On Wed, Feb 7, 2024, 09:17 Gnangarra <gnangarra@gmail.commailto:gnangarra@gmail.com> wrote: Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria <bustrias@gmail.commailto:bustrias@gmail.com> wrote: Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon. https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
Butch Bustria
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber <bvibber@wikimedia.orgmailto:bvibber@wikimedia.org> wrote: Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM <mmiller@wikimedia.orgmailto:mmiller@wikimedia.org> wrote: Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian
I have laid out 4 strategies for including OWID in mediawiki here
https://mdwiki.org/wiki/WikiProjectMed:OWID
We can of course do the third one immediately. Ie simply link in the caption to the interactive graphs hosted by OWID itself.
James
On Thu, Jun 6, 2024 at 9:15 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
It doesn't matter what we think. It doesn't even matter if we collectively decide that we want to go on that direction. The WMF's Annual Plan and every single answer points that they don't mind.
We were doing it wrong one year ago. Now is even worse. Catastrophic, but not serious.
*From:* James Heilman jmh649@gmail.com *Sent:* Thursday, June 6, 2024 9:09 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yah, not sure what Bergsma (WMF) https://meta.wikimedia.org/wiki/User:Mark_Bergsma_(WMF) is trying to say... No one is dismissing security or privacy. One; however, does need to balance risk versus benefit and of course mitigate security and privacy issues along the way. Allowing fear of security or privacy risks to paralyse us is also not ideal.
Kimmo for sure we could internalize everything ie run their software on production servers, we already host their data on Commons (that was a many year effort). Made the request 8 or so years ago to host their software in fact, but the WMF dissolved the team / individual working on this effort. I still think that is a reasonable way forwards.
James
On Thu, Jun 6, 2024 at 8:03 PM Kimmo Virtanen kimmo.virtanen@wikimedia.fi wrote:
Hi,
Just as a practical question in terms of what has been already done. As it seems that all proposals where extension will require external connections outside of Wikimedia production sites are no-go the feasible next step would be to modify the OurWorldInData extension so that it would load the graph data from Wikimedia commons. Is this already done even for a limited number of example graphs? If not then this could be the next step and then ask for a new security review on this approach.
Though, even after it is solved that extension doesn't need external connections outside wikimedia production it still would require some level code review that OWID grapher doesn't do anything unexpected.
Data itself in least some extend is in Commons
The OurWorldInData grapher
https://github.com/owid/owid-grapher/tree/master/packages/%40ourworldindata/...
Application Security Review Request : OurWorldInData
Br, -- Kimmo Virtanen, Zache
On Thu, Jun 6, 2024 at 6:46 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Has this discussion impacted somehow on the WMF's approach to the future.
Well, today we had the answer: https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#c-Mark_Bergsma_(WMF)-202406...
(TL;DR: no)
Galder
*From:* Daniel Mui danboy12342@gmail.com *Sent:* Tuesday, March 26, 2024 9:40 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
I would agree that no mention in the OKR would be quite disturbing... However the 2024 report is NOT out yet, these are draft issues and I would not make judgement until the full report is ready, which i believe to be april.
Dear All,
I understand the frustration around the lack of progress on interactive content and the discontinuation of the Graph extension. However, I'd like to point out a few things.
First, the response from staff members reaching out to editors for their opinions was remarkably quick. This type of response is not common, and Wikipedia is unique in its hands-on approach to issues like this, it is something to be proud of and also something that takes time.
Second, the Graph tool is being overhauled rather than patched. This is a significant undertaking that will bring all our tools into the modern age, making them more accessible and removing the underlying vulnerabilities that led to the current situation in the first place, it will also ensure the tool is up-to-date in terms of UX through things like codex and other modern improvements that long term will allow more users to create graphs which hopefully will keep it a priority to maintain, again thinking long term here.
I know that this is taking time, but I believe that developing a robust and sustainable solution is the best approach. Doing it this way rather than delaying it for another six months is something I'd rather have and I'd like to thank the hard working wikimedia team for that.
Thanks, Daniel
On Tue, Mar 26, 2024 at 8:03 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Dear all, Soon it will be a year since the Graph extension is disabled in all wikis. Meanwhile, we have been discussing about interactive content here and there, and there have been some promises about changes in the platform so these changes are possible in the future.
Today the draft of the Key Results for the 2024-2025 annual plan was published and there's no single mention to this, nor to improving the multimedia experience. The disconnection between the needs and the plans is so evident, that I don't really know why we even bother discussing. You can see the Key Results here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P... https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs .
This is extremely disappointing.
Best, Galder
*From:* Samuel Klein meta.sj@gmail.com *Sent:* Saturday, March 23, 2024 3:37 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone schenonef@gmail.com wrote:
Hi Galder, I just did this fix https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder
*From:* Felipe Schenone schenonef@gmail.com *Sent:* Friday, March 22, 2024 10:39 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipedia https://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgets https://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk page https://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui danboy12342@gmail.com wrote:
Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
On Wed, Feb 7, 2024, 09:17 Gnangarra gnangarra@gmail.com wrote:
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
James,
Way 1-3 was effectively banned by WMF today. Way 4 is still viable, but expecting the staff to start it up for you is a pipe dream.
- Charles
On Thu, Jun 6, 2024 at 4:01 PM James Heilman jmh649@gmail.com wrote:
I have laid out 4 strategies for including OWID in mediawiki here
https://mdwiki.org/wiki/WikiProjectMed:OWID
We can of course do the third one immediately. Ie simply link in the caption to the interactive graphs hosted by OWID itself.
James
On Thu, Jun 6, 2024 at 9:15 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
It doesn't matter what we think. It doesn't even matter if we collectively decide that we want to go on that direction. The WMF's Annual Plan and every single answer points that they don't mind.
We were doing it wrong one year ago. Now is even worse. Catastrophic, but not serious.
*From:* James Heilman jmh649@gmail.com *Sent:* Thursday, June 6, 2024 9:09 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yah, not sure what Bergsma (WMF) https://meta.wikimedia.org/wiki/User:Mark_Bergsma_(WMF) is trying to say... No one is dismissing security or privacy. One; however, does need to balance risk versus benefit and of course mitigate security and privacy issues along the way. Allowing fear of security or privacy risks to paralyse us is also not ideal.
Kimmo for sure we could internalize everything ie run their software on production servers, we already host their data on Commons (that was a many year effort). Made the request 8 or so years ago to host their software in fact, but the WMF dissolved the team / individual working on this effort. I still think that is a reasonable way forwards.
James
On Thu, Jun 6, 2024 at 8:03 PM Kimmo Virtanen < kimmo.virtanen@wikimedia.fi> wrote:
Hi,
Just as a practical question in terms of what has been already done. As it seems that all proposals where extension will require external connections outside of Wikimedia production sites are no-go the feasible next step would be to modify the OurWorldInData extension so that it would load the graph data from Wikimedia commons. Is this already done even for a limited number of example graphs? If not then this could be the next step and then ask for a new security review on this approach.
Though, even after it is solved that extension doesn't need external connections outside wikimedia production it still would require some level code review that OWID grapher doesn't do anything unexpected.
Data itself in least some extend is in Commons
The OurWorldInData grapher
https://github.com/owid/owid-grapher/tree/master/packages/%40ourworldindata/...
Application Security Review Request : OurWorldInData
Br, -- Kimmo Virtanen, Zache
On Thu, Jun 6, 2024 at 6:46 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Has this discussion impacted somehow on the WMF's approach to the future.
Well, today we had the answer: https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#c-Mark_Bergsma_(WMF)-202406...
(TL;DR: no)
Galder
*From:* Daniel Mui danboy12342@gmail.com *Sent:* Tuesday, March 26, 2024 9:40 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
I would agree that no mention in the OKR would be quite disturbing... However the 2024 report is NOT out yet, these are draft issues and I would not make judgement until the full report is ready, which i believe to be april.
Dear All,
I understand the frustration around the lack of progress on interactive content and the discontinuation of the Graph extension. However, I'd like to point out a few things.
First, the response from staff members reaching out to editors for their opinions was remarkably quick. This type of response is not common, and Wikipedia is unique in its hands-on approach to issues like this, it is something to be proud of and also something that takes time.
Second, the Graph tool is being overhauled rather than patched. This is a significant undertaking that will bring all our tools into the modern age, making them more accessible and removing the underlying vulnerabilities that led to the current situation in the first place, it will also ensure the tool is up-to-date in terms of UX through things like codex and other modern improvements that long term will allow more users to create graphs which hopefully will keep it a priority to maintain, again thinking long term here.
I know that this is taking time, but I believe that developing a robust and sustainable solution is the best approach. Doing it this way rather than delaying it for another six months is something I'd rather have and I'd like to thank the hard working wikimedia team for that.
Thanks, Daniel
On Tue, Mar 26, 2024 at 8:03 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Dear all, Soon it will be a year since the Graph extension is disabled in all wikis. Meanwhile, we have been discussing about interactive content here and there, and there have been some promises about changes in the platform so these changes are possible in the future.
Today the draft of the Key Results for the 2024-2025 annual plan was published and there's no single mention to this, nor to improving the multimedia experience. The disconnection between the needs and the plans is so evident, that I don't really know why we even bother discussing. You can see the Key Results here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P... https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs .
This is extremely disappointing.
Best, Galder
*From:* Samuel Klein meta.sj@gmail.com *Sent:* Saturday, March 23, 2024 3:37 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone schenonef@gmail.com wrote:
Hi Galder, I just did this fix https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder
*From:* Felipe Schenone schenonef@gmail.com *Sent:* Friday, March 22, 2024 10:39 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipedia https://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgets https://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk page https://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui danboy12342@gmail.com wrote:
Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
On Wed, Feb 7, 2024, 09:17 Gnangarra gnangarra@gmail.com wrote:
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Way 3 is only banned if staff decide external links are too dangerous.
J
Sent from Gmail Mobile
On Fri, Jun 7, 2024 at 01:54 Charles Roberson clandonroberson@gmail.com wrote:
James,
Way 1-3 was effectively banned by WMF today. Way 4 is still viable, but expecting the staff to start it up for you is a pipe dream.
- Charles
On Thu, Jun 6, 2024 at 4:01 PM James Heilman jmh649@gmail.com wrote:
I have laid out 4 strategies for including OWID in mediawiki here
https://mdwiki.org/wiki/WikiProjectMed:OWID
We can of course do the third one immediately. Ie simply link in the caption to the interactive graphs hosted by OWID itself.
James
On Thu, Jun 6, 2024 at 9:15 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
It doesn't matter what we think. It doesn't even matter if we collectively decide that we want to go on that direction. The WMF's Annual Plan and every single answer points that they don't mind.
We were doing it wrong one year ago. Now is even worse. Catastrophic, but not serious.
*From:* James Heilman jmh649@gmail.com *Sent:* Thursday, June 6, 2024 9:09 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yah, not sure what Bergsma (WMF) https://meta.wikimedia.org/wiki/User:Mark_Bergsma_(WMF) is trying to say... No one is dismissing security or privacy. One; however, does need to balance risk versus benefit and of course mitigate security and privacy issues along the way. Allowing fear of security or privacy risks to paralyse us is also not ideal.
Kimmo for sure we could internalize everything ie run their software on production servers, we already host their data on Commons (that was a many year effort). Made the request 8 or so years ago to host their software in fact, but the WMF dissolved the team / individual working on this effort. I still think that is a reasonable way forwards.
James
On Thu, Jun 6, 2024 at 8:03 PM Kimmo Virtanen < kimmo.virtanen@wikimedia.fi> wrote:
Hi,
Just as a practical question in terms of what has been already done. As it seems that all proposals where extension will require external connections outside of Wikimedia production sites are no-go the feasible next step would be to modify the OurWorldInData extension so that it would load the graph data from Wikimedia commons. Is this already done even for a limited number of example graphs? If not then this could be the next step and then ask for a new security review on this approach.
Though, even after it is solved that extension doesn't need external connections outside wikimedia production it still would require some level code review that OWID grapher doesn't do anything unexpected.
Data itself in least some extend is in Commons
The OurWorldInData grapher
https://github.com/owid/owid-grapher/tree/master/packages/%40ourworldindata/...
Application Security Review Request : OurWorldInData
Br, -- Kimmo Virtanen, Zache
On Thu, Jun 6, 2024 at 6:46 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Has this discussion impacted somehow on the WMF's approach to the future.
Well, today we had the answer: https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#c-Mark_Bergsma_(WMF)-202406...
(TL;DR: no)
Galder
*From:* Daniel Mui danboy12342@gmail.com *Sent:* Tuesday, March 26, 2024 9:40 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
I would agree that no mention in the OKR would be quite disturbing... However the 2024 report is NOT out yet, these are draft issues and I would not make judgement until the full report is ready, which i believe to be april.
Dear All,
I understand the frustration around the lack of progress on interactive content and the discontinuation of the Graph extension. However, I'd like to point out a few things.
First, the response from staff members reaching out to editors for their opinions was remarkably quick. This type of response is not common, and Wikipedia is unique in its hands-on approach to issues like this, it is something to be proud of and also something that takes time.
Second, the Graph tool is being overhauled rather than patched. This is a significant undertaking that will bring all our tools into the modern age, making them more accessible and removing the underlying vulnerabilities that led to the current situation in the first place, it will also ensure the tool is up-to-date in terms of UX through things like codex and other modern improvements that long term will allow more users to create graphs which hopefully will keep it a priority to maintain, again thinking long term here.
I know that this is taking time, but I believe that developing a robust and sustainable solution is the best approach. Doing it this way rather than delaying it for another six months is something I'd rather have and I'd like to thank the hard working wikimedia team for that.
Thanks, Daniel
On Tue, Mar 26, 2024 at 8:03 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Dear all, Soon it will be a year since the Graph extension is disabled in all wikis. Meanwhile, we have been discussing about interactive content here and there, and there have been some promises about changes in the platform so these changes are possible in the future.
Today the draft of the Key Results for the 2024-2025 annual plan was published and there's no single mention to this, nor to improving the multimedia experience. The disconnection between the needs and the plans is so evident, that I don't really know why we even bother discussing. You can see the Key Results here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P... https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs .
This is extremely disappointing.
Best, Galder
*From:* Samuel Klein meta.sj@gmail.com *Sent:* Saturday, March 23, 2024 3:37 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone schenonef@gmail.com wrote:
Hi Galder, I just did this fix https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder
*From:* Felipe Schenone schenonef@gmail.com *Sent:* Friday, March 22, 2024 10:39 PM *To:* Wikimedia Mailing List wikimedia-l@lists.wikimedia.org *Subject:* [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipedia https://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgets https://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk page https://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui danboy12342@gmail.com wrote:
Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
On Wed, Feb 7, 2024, 09:17 Gnangarra gnangarra@gmail.com wrote:
Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
It's interesting to see the WMF talking clearly about the issue of interactivity. The word "interactiv*" appears exactly ZERO TIMES in the Annual plan Objetives, Key Results and Hypotheses (just published): https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P...
Could it be worse? Yes, for sure. Everything can be worse, but we need to make an extra effort to find how.
________________________________ From: James Heilman jmh649@gmail.com Sent: Friday, June 7, 2024 5:28 AM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Way 3 is only banned if staff decide external links are too dangerous.
J
Sent from Gmail Mobile
On Fri, Jun 7, 2024 at 01:54 Charles Roberson <clandonroberson@gmail.commailto:clandonroberson@gmail.com> wrote: James,
Way 1-3 was effectively banned by WMF today. Way 4 is still viable, but expecting the staff to start it up for you is a pipe dream.
- Charles
On Thu, Jun 6, 2024 at 4:01 PM James Heilman <jmh649@gmail.commailto:jmh649@gmail.com> wrote: I have laid out 4 strategies for including OWID in mediawiki here
https://mdwiki.org/wiki/WikiProjectMed:OWID
We can of course do the third one immediately. Ie simply link in the caption to the interactive graphs hosted by OWID itself.
James
On Thu, Jun 6, 2024 at 9:15 PM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: It doesn't matter what we think. It doesn't even matter if we collectively decide that we want to go on that direction. The WMF's Annual Plan and every single answer points that they don't mind.
We were doing it wrong one year ago. Now is even worse. Catastrophic, but not serious. ________________________________ From: James Heilman <jmh649@gmail.commailto:jmh649@gmail.com> Sent: Thursday, June 6, 2024 9:09 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Yah, not sure what Bergsma (WMF)https://meta.wikimedia.org/wiki/User:Mark_Bergsma_(WMF) is trying to say... No one is dismissing security or privacy. One; however, does need to balance risk versus benefit and of course mitigate security and privacy issues along the way. Allowing fear of security or privacy risks to paralyse us is also not ideal.
Kimmo for sure we could internalize everything ie run their software on production servers, we already host their data on Commons (that was a many year effort). Made the request 8 or so years ago to host their software in fact, but the WMF dissolved the team / individual working on this effort. I still think that is a reasonable way forwards.
James
On Thu, Jun 6, 2024 at 8:03 PM Kimmo Virtanen <kimmo.virtanen@wikimedia.fimailto:kimmo.virtanen@wikimedia.fi> wrote: Hi,
Just as a practical question in terms of what has been already done. As it seems that all proposals where extension will require external connections outside of Wikimedia production sites are no-go the feasible next step would be to modify the OurWorldInData extension so that it would load the graph data from Wikimedia commons. Is this already done even for a limited number of example graphs? If not then this could be the next step and then ask for a new security review on this approach.
Though, even after it is solved that extension doesn't need external connections outside wikimedia production it still would require some level code review that OWID grapher doesn't do anything unexpected.
Data itself in least some extend is in Commons - https://commons.wikimedia.org/wiki/Category:Our_World_in_Data_datasets
The OurWorldInData grapher - https://github.com/owid/owid-grapher/tree/master/packages/%40ourworldindata/...
Application Security Review Request : OurWorldInData - https://phabricator.wikimedia.org/T324989
Br, -- Kimmo Virtanen, Zache
On Thu, Jun 6, 2024 at 6:46 PM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: Has this discussion impacted somehow on the WMF's approach to the future.
Well, today we had the answer: https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#c-Mark_Bergsma_(WMF)-202406...
(TL;DR: no)
Galder ________________________________ From: Daniel Mui <danboy12342@gmail.commailto:danboy12342@gmail.com> Sent: Tuesday, March 26, 2024 9:40 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
I would agree that no mention in the OKR would be quite disturbing... However the 2024 report is NOT out yet, these are draft issues and I would not make judgement until the full report is ready, which i believe to be april.
________________________________ Dear All,
I understand the frustration around the lack of progress on interactive content and the discontinuation of the Graph extension. However, I'd like to point out a few things.
First, the response from staff members reaching out to editors for their opinions was remarkably quick. This type of response is not common, and Wikipedia is unique in its hands-on approach to issues like this, it is something to be proud of and also something that takes time.
Second, the Graph tool is being overhauled rather than patched. This is a significant undertaking that will bring all our tools into the modern age, making them more accessible and removing the underlying vulnerabilities that led to the current situation in the first place, it will also ensure the tool is up-to-date in terms of UX through things like codex and other modern improvements that long term will allow more users to create graphs which hopefully will keep it a priority to maintain, again thinking long term here.
I know that this is taking time, but I believe that developing a robust and sustainable solution is the best approach. Doing it this way rather than delaying it for another six months is something I'd rather have and I'd like to thank the hard working wikimedia team for that.
Thanks, Daniel
On Tue, Mar 26, 2024 at 8:03 PM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: Dear all, Soon it will be a year since the Graph extension is disabled in all wikis. Meanwhile, we have been discussing about interactive content here and there, and there have been some promises about changes in the platform so these changes are possible in the future.
Today the draft of the Key Results for the 2024-2025 annual plan was published and there's no single mention to this, nor to improving the multimedia experience. The disconnection between the needs and the plans is so evident, that I don't really know why we even bother discussing. You can see the Key Results here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/P...https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs.
This is extremely disappointing.
Best, Galder
________________________________ From: Samuel Klein <meta.sj@gmail.commailto:meta.sj@gmail.com> Sent: Saturday, March 23, 2024 3:37 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Beautiful. Thank you Felipe!!
🌍🌏🌎🌑
On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone <schenonef@gmail.commailto:schenonef@gmail.com> wrote: Hi Galder, I just did this fixhttps://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=9637458 and your Vivarium seems to be working now. The documentation was ok, but a bit confusing, so I improved it too. Soon I'll send a patch to make those "special categories" unnecessary. In the meantime, they're a necessary annoyance, I'm afraid. Cheers!
On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> wrote: Thanks Felipe, that's a really great move. I looked to these examples a couple o years ago, and this seems that a good option to add some interactive content. Anyway, I have tried to replicate it and can't make it work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?
Best
Galder ________________________________ From: Felipe Schenone <schenonef@gmail.commailto:schenonef@gmail.com> Sent: Friday, March 22, 2024 10:39 PM To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.orgmailto:wikimedia-l@lists.wikimedia.org> Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi everyone, good news!
Thanks to this humble changehttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092 (deployed today) it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipediahttps://es.wikipedia.org/wiki/Juego_de_la_vida for an interactive instance of Conway's Game of Life, and scroll down for more instances!
I started documenting the system at MediaWiki.org, under the title template gadgetshttps://www.mediawiki.org/wiki/Template_gadgets, and included many working examples. Check it out!
Perhaps the system isn't as friendly or powerful a solution as some might hope. But it's very real, and it only depends on us now. Next week, when the documentation and examples are a bit more cooked, I'll propose adding a few "template gadgets" to the English Wikipedia, since my experience has taught me that when something hits the English Wikipedia, it quickly spreads elsewhere. I'll link to the proposal when I do, in case you want to participate.
There's so much more that could be said about this, but I'd rather keep it short. If you have questions or ideas, feel free to write them here or at the relevant talk pagehttps://www.mediawiki.org/wiki/Talk:Template_gadgets.
Kind regards, Felipe (User:Sophivorus)
On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui <danboy12342@gmail.commailto:danboy12342@gmail.com> wrote: Hi everyone,
I agree that Wikipedia needs to spend a few quarters spending time on our main product. The website is very impressively still the top result of a huge number of searches and in this new AI age; despite the controversy around it, wikipedia is the top source for many LLMs. Therefore while it doesn't need to be the only focus or even *the* focus most of the time it does need to be kept working but not just kept as is, it needs to be innovative and continue to meet the growing demands of a "modern" and "useable" site that allow users to get the information they need as fast and effectively as possible, these days that means interactivity.
I feel I'm repeating others but a quick burst of very serious investment into the site and its many sister pages needs to happen sooner rather than later. Finally I'd like to thank Marshall again for his remarkable comments. It's good to see that this issue is clearly a priority that foundation staff are already looking at.
- Daniel.
---------------------
On Wed, Feb 7, 2024, 09:17 Gnangarra <gnangarra@gmail.commailto:gnangarra@gmail.com> wrote: Hi
I just like to highlight one point, that raises concerns;
perhaps enabling other platforms/apps to use our content to make interactive or video materials there.
While this sounds like an easy solution we run into a number of hidden costs. These are significant when we push for reusers to present what we are doing in better ways we lose the movement's revenue stream as less people see our donation banners. With less direct traffic we also sacrifice the ability to convert readers into contributors which has always been our primary source of community sustainability and growth. I know other providers will find different ways to present our efforts in part or in whole that is part of our purpose, to do our mission and achieve our goals we need prioritise internal solutions.
This also leads us to a related issue that our mission is to make the sum of all knowledge freely available. When we look to outside parties to share our efforts we lose our ability to ensure that the information is neutral, and that it's freely accessible. Butch is right in noting that when we put funding into third party sites it is taking resources away from the movement, yet those same funds were donated to us on the basis of maintaining and building our infrastructure. It would be a wise investment to enable some of those much needed interactive and video content here through purchasing rights.
On Wed, 7 Feb 2024 at 12:20, Butch Bustria <bustrias@gmail.commailto:bustrias@gmail.com> wrote: Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon. https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
Butch Bustria
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber <bvibber@wikimedia.orgmailto:bvibber@wikimedia.org> wrote: Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM <mmiller@wikimedia.orgmailto:mmiller@wikimedia.org> wrote: Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- Boodarwun Gnangarra 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
The fundamental, unfixed problem is that WMF decision-makers will do what they want to do, regardless of what the movement thinks, wants, or cares about. Interest the WMF in technological improvements that are crucial to the core mission? Nope. Form a committee that chooses a committee to write a document that lays out the rules to select a committee to do something maybe? Sign them up. Nobody levels up their next C-Suite landing spot by achieving boring old mission goals.
-- Dan Szymborski
There should be something we as a community can do to make the WMF use their "very limited resources", as they usually call them, to actually fix and improve the stuff we need, instead of deriving them into whatever that nobody asked and is of dubious impact?
Paulo
Dan Szymborski dszymborski@gmail.com escreveu (domingo, 23/06/2024 à(s) 01:35):
The fundamental, unfixed problem is that WMF decision-makers will do what they want to do, regardless of what the movement thinks, wants, or cares about. Interest the WMF in technological improvements that are crucial to the core mission? Nope. Form a committee that chooses a committee to write a document that lays out the rules to select a committee to do something maybe? Sign them up. Nobody levels up their next C-Suite landing spot by achieving boring old mission goals.
-- Dan Szymborski _______________________________________________ Wikimedia-l mailing list -- 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
I agree with Butch Bustria.
Considering that the WMF is not short of funds, and there appears to be adequate funds to establish fund deposits outside WMF and fund third party organisations not directly involved in the core vision of the Movement, i.e. to make the sum of human knowledge available to all (paraphrasing here), it is hard to understand how funds are a constraint as one understands by the lead of the Product Team.
Without delivery of the most modern and highest quality content, all other activities such as Movement strategy, offline activities etc are meaningless activity that can be done away with.
There is urgent need for a vision that gives primacy to the platform, it's capabilities and tools to support those that make the content. If it requires substantial investment and time, so be it, but at present there seems to be no sign on ground that the infrastructure is being improved us a substantial rewrite or major upgrade.
The activities mentioned by the Products lead are reasonably important but they are just isolated disjunct things while the creaking infrastructure isn't addressed as a whole.
I hope this changes in the near future and we get the strong framework that will enable graphs, video, interactivity, accessibility and all modern features of the future.
AshLin
On Wed, 7 Feb 2024, 09:50 Butch Bustria, bustrias@gmail.com wrote:
Hi Everyone,
My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial Plan prioritize and I mean put first among all is the technical infrastructure among all its budgetary items. We can scale down budgets to 3rd party organizations like the Knowledge Equity Fund, Movement Strategy Governance funding, campaign grants, and other "wants" to accomodate a highly technically reliable and stable Wikimedia online projects ("needs"), future proof, and user friendly experience which require investments on quality manpower, hardware, applications and the like. We love open source but we also be pragmatic and wise on selection of choices because we want our content be conveniently available and reliable to our readers, users, consumers and also editors.
A welcome development is the MediaWiki Users and Developers Conference, the successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_202...
The said conference will be held in Portland, Oregon, from April 17–19, 2024.
I also hope the Foundation invest in more technical gatherings, both onsite, hybrid or online to engage and reach out to more technical contributors, within and beyond the Wikimedia movement. I also hope WMF to start exploring eastward to Asia or elsewhere in the world as well fully diversify the technical community.
Kind regards,
*Butch Bustria*
On Wed, Feb 7, 2024, 4:54 AM Brion Vibber bvibber@wikimedia.org wrote:
Thanks for weighing in, Marshall!
I agree wholeheartedly that we need to do a proper architecture for a sandbox for interactive media, that will be safe (first and foremost), perform well in the browser, work across device types (desktop web, mobile web, mobile apps), and maintain our key requirements on editability and reusability, balanced against the security and privacy needs of users if we're going to invest the effort.
Backing up to do it right rather than patch up Graphs “one more time” is the right thing, and I’m very happy to see a confluence of interest around this now!
My hope is we can figure out how to make that architecture & testing work happen in the near term until we collectively (inside WMF and out) can wrangle resources to make the implementation production-ready.
Once we have a common infrastructure to build on, it’ll be easier for work to progress on individual types of media (graphs, charts, maps, animations, editable simulations, coding examples, etc, as well as classics like panorama viewers and integrating the audio/video player into a sandbox for heightened security).
My biggest hope is that we’ll enable more work from outside WMF to happen – letting volunteers and other orgs who might have their own specialty areas and work funding to progress without every change being a potential new security risk.
When we have succeeded in the past, we have succeeded by making tools that other people can use as their own basis to build their own works. I’m confident we can get there on interactive media with some common focus.
Let's all try to capture some of this momentum while we've got it and set ourselves up for success down the road.
– b
On Tue, Feb 6, 2024, 12:27 PM mmiller@wikimedia.org wrote:
Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at the Wikimedia Foundation, and I work with many of the teams that are involved with the user experience of our websites and apps, such as the Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership group that makes decisions about how the WMF teams approach things like graphs, interactive content, and video. Thank you all for having this in-depth and important discussion.
I know that issues with graphs [2] are what started this discussion, but I agree that it makes sense to think about this in terms of the broader category of “interactive content”, because other kinds of interactive content, such as maps or timelines, would share architecture with what is needed for graphs (video is a different and more complicated content type). I wrote a lot in this email, but here are a couple of the main points up front: to support graphs and other interactive content, we would need to take a step back and make a substantial investment in sustainable architecture to do it – so that it works well, safely, and is built to last. And because that’s a substantial investment, we need to weigh it against other important investments in order to decide whether and when to do it.
I know that it is very frustrating that the Graph extension has not been operational for many months – it means readers haven’t been seeing graphs in articles, and editors haven’t been able to use graphs to do things like monitor backlogs in WikiProjects. Over the months of trying to find a way to turn graphs back on, it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on. Every year we have to make difficult tradeoffs around what areas of our technical infrastructure we can and cannot take on. In the current fiscal year, the Product and Technology department has made experienced editors a priority [3], and many things that volunteers have asked for are either accomplished or in flight:
Improvements to PageTriage (complete) [4] Watchlist in the iOS app (complete) [5] Patrolling in the Android app (in progress) [6] Dark mode (in progress) [7] Improvements to the Commons Upload Wizard (in progress) [8] …and other projects.
But I know this conversation isn’t as much about what editors need as what current and future readers need. Between talking about interactive content and talking about video, it sounds like we’re having the larger conversation of what we should be offering today’s and tomorrow’s readers to help them learn from encyclopedic content – whether we need to be offering interactivity, or video, or perhaps enabling other platforms/apps to use our content to make interactive or video materials there. This is a really important conversation, because even working together we probably will not be able to build all of it – we’ll have to make hard choices about where to invest. One place where this broader conversation is happening is called “Future Audiences”, which does experiments on how to reach newer generations who use the internet differently than previous generations – and thinking particularly about video. Future Audiences has regular calls with community members to shape the direction of those experiments, which in turn inform how the broader Foundation prioritizes. I hope many of you will get involved in those conversations – you can sign up here. [9]
Focusing back on graphs, since that’s what kicked this thread off, the several approaches we’ve attempted for quickly re-enabling the extension have ended up having security or performance problems. Therefore, we think that if we were to support graphs and other interactive content, we would need to plan substantial investment in sustainable architecture. This way, our approach would work securely and stably for the longer term. But that would take significant resources, and we’ll need to weigh it against many other important priorities, like tools for functionaries, improvements to the editing experience, automated ways to stop vandals, etc.
To be clear, if we do assign resources to the planning and building of an architecture for graphs (and other interactive content), it means that we are still at least several more months away from having a working Foundation-supported architecture. Therefore, I think we should also be having the additional conversation that many others have brought up about what volunteers can do in these intervening months to make graphs somewhat available to users. I know people are talking about that concretely on the Phabricator task, and I will join that conversation as well. For the bigger question, I would like to start with some more learning about which kinds of interactive content are important for our encyclopedia, and how our community members see the evolution of the reading experience on our projects. I’d like to have some small conversations with many of you so that we can get into the details and ideas, joined by some of my colleagues. I’ll start reaching out to see who is interested in talking – and please let me know directly if you’d like to talk.
Thank you for weighing in so far, and let’s keep talking and planning together.
Marshall
[1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF) [2] https://phabricator.wikimedia.org/T334940 [3] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#O... [4] https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_p... ! [5] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_202... [6] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading [8] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wi... [9] https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate! _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Hi
Just chiming into this discussion on *Graphs*. During the pandemic, I devoted much time on Wikidata building large datasets such as poverty incidence data and financial data. It is live now with at least being queried in 1700 Wikipedia articles multiplied by 8 languages and one chart contain 5-7 wikidata queries. With the graph not visible, it makes the chart useless in the Wikipedia article. I am mulling the idea to change it to a table of figures rather than a chart since the graph module downtime is taking too long already.
There are more datasets in the pipeline but I am holding it for now.
I am not sure if the Foundation lack budget for technical infrastructure research and development and that Wikimedia's technical features is at the level of the year 2012 or they lack manpower. I hope they invest donor's money on this first then when there is budget surplus it could go to conference & meetings travel and grants to 3rd party organizations.
Kind regards,
Butch Bustria
On Wed, Jan 31, 2024, 5:57 AM Ori Livneh ori.livneh@gmail.com wrote:
On Tue, Jan 30, 2024 at 2:52 PM Samuel Klein meta.sj@gmail.com wrote:
Galder: fair enough, let's keep this thread for interactive content. Brion's excellent suggestions deserve their own thread.
On Tue, Jan 30, 2024 at 1:14 PM James Heilman jmh649@gmail.com wrote:
With respect to OWID, one can see the interactive graphs working within a mediawiki environment here https://mdwiki.org/wiki/WikiProjectMed:OWID. Our hope for next steps to get around the current blockers is to show a static version of the graph from Commons with a play button overlay. When the play button is hit a consent pop up similar to what you see for maps on Wikivoyage https://en.wikivoyage.org/wiki/Cranbrook when you request a layer such as "relief maps". This will then bring in the corresponding interactive content hosted from the wmcloud https://owidm.wmcloud.org/grapher/share-of-population-with-schizophrenia. While this be acceptable to the powers that be? I am not sure.
Yea, this is fantastic. Thank you for the demonstration. We should creatively upgrade our approaches to privacy and security to make it possible to do this. This is a purely technical challenge, not a social adoption or licensing one, for overcoming self-imposed obstacles of our ecosystem.
I appreciate Galder focusing the attention back on non-video content.
If we're collecting exemplars, I'd like to add Bartosz Ciechanowski's superlative articles https://ciechanow.ski/archives/, like the ones on bicycles https://ciechanow.ski/bicycle/ and sound https://ciechanow.ski/sound/. His articles are the best examples I know of interactive content that complements long-form text content.
Beside the complementary relationship with long-form text, there is another aspect to this type of content that makes it a great fit for Wikipedia. Interactive visualizations are usually built by combining vector graphics (graphics based on geometric shapes that are defined mathematically, rather than bitmaps) and code. Both of these are at bottom textual media and thus very amenable to collaborative, iterative improvement via wikis.
Proposals to enable support for this sort of content (for example, via interactive SVGs https://phabricator.wikimedia.org/T138665) have languished for years. I think it is worth asking why, and to approach the question with intellectual curiosity rather than frustration. My intuition is that the core reason is that the security dimension of this work is non-intuitive and poorly understood.
My hunch is that if you asked a bunch of random people about what sort of engineering work might be needed to support more interactive content on Wikipedia, the answers you will get will be disproportionately focused on missing user-facing interfaces and functionality for editing and displaying such content. And if that's your view, it is very natural for various assumptions to follow about what sort of expertise is required. But it's the wrong view and the wrong assumptions.
The critical issue is *security*. Security is the reason the graph extension is not enabled. Security is the reason why interactive SVGs are not enabled. Interactive visualizations have a programmatic element that consists of code that executes in the user's browser. Such code needs to be carefully sandboxed to ensure it cannot be used to exfiltrate user data or surreptitiously perform actions on wiki.
The bar for shipping security-critical features is high. You can ship code with crummy UX and iterate on it. But something that touches security requires a higher amount of up-front technical design work and close scrutiny in the form of peer review. And this means that it cannot progress spontaneously, through sporadic bursts of effort here and there (which is how a lot of engineering work happens) but requires a solid commitment of focused attention from multiple people with relevant expertise.
There are engineers at the Wikimedia Foundation and in the technical contributor community with the relevant expertise but as a rule they are extremely oversubscribed. My recommendation would be to engage them in crafting a job description for this role and in reviewing candidates. _______________________________________________ Wikimedia-l mailing list -- 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
[New thread for the discussions started by brion, Ivan, James and others on becoming video-friendly and building a community of video editors and curators. Was "*Re: We need more interactive content.*"]
James Heilman wrote:
With VideoWiki we have been able to create some higher quality content with a partner at MyUpchar. The text was written by us, the individual short animations were done by them, and then the tool combines it all together with text to speech. Hope to get the tool working again soon: https://mdwiki.org/wiki/Video:Tuberculosis
A nice example of a) creating a space explicitly to develop new tools and encourage one another in using them; b) trialing a workflow that can be automated at need.
Text-to-speech and animation tools have also advanced tremendously since that was produced; this is also becoming an important channel for more mainstream media (I see the spammers taking over mainstream social media with it as well, in how-tos, education, news, sports, and leisure).
SJ
On Tue, Jan 30, 2024 at 2:25 AM Ivan Martínez galaver@gmail.com wrote:
It is not difficult to do something that is already happening. By referring to encyclopedic videos I am talking about multimedia that can enrich existing content. I understand your point, it's a bit like what happened with the project of reading recorded Wikipedia articles that after years seem obsolete.
What I am referring to is all that multimedia material that is visual, that can be made into video to complement articles. The process you mention is complicated, but not impossible, in fact, there are many of us editors who have all those skills already implemented in the projects.
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
encyclopaedic videos. I see a false dilemma there.
brion wrote:
My recommendations for Wikimedia Foundation on this subject:
- Overturn the requirement to avoid handling h.264 files on Wikimedia
servers or accept them from users or serve them to users. Allow importing h.264 uploads and creating h.264 transcodes for playback compatibility. 2) Create an interactive media team with at least two engineers, a designer, and a project manager 3) Give this team a remit to rebuild *and maintain in an ongoing fashion* the existing TimedMediaHandler, Graphs, Score, 3D, etc extensions 4) Integrate those tools cleanly with mobile apps and social media embedding tools managed by other teams
Thanks Brion for the detailed breakdown re: video issues. Replying under the changed subject line :)
Re: transcoding video, Brion wrote:
Allowing *ingestion* of MP4 h.264/AAC would allow uploading camera originals from most consumer gear -- a major democratizing feature. Ingestion of MP4 HEVC/AAC would give more compatibility.
In both cases we have all the software we need, we already use the Debian ffmpeg package which includes code supporting both formats; we just don't allow uploading the files, reading them to convert for playback, or downloading the originals from our web site.
Do we need a MPEG-LA patent license for that? Nobody seemed to think so in 2014 but nobody could tell me for sure either, then or now.
IMO it would be useful to commission a renewed legal/policy assessment of those questions. Similarly, it would be good to know if any expiring patents might soon expand the range of options Wikimedia projects could enable without a patent policy change. At least for H.264 it seems like a pile of patents are coming up for expiry in 2024 and 2025, but I don't know if they alone help us much. [1]
Regardless of any changes to Wikimedia's hard line policy stance on patent-encumbered codecs, the industry trend towards more open formats does make me optimistic about video in the long run.
Warmly, Erik
[1] Per this community-maintained page: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_MPEG-4_AVC_expire...
On Tue, Jan 30, 2024 at 11:59 AM Samuel Klein meta.sj@gmail.com wrote:
[New thread for the discussions started by brion, Ivan, James and others on becoming video-friendly and building a community of video editors and curators. Was "Re: We need more interactive content."]
James Heilman wrote:
With VideoWiki we have been able to create some higher quality content with a partner at MyUpchar. The text was written by us, the individual short animations were done by them, and then the tool combines it all together with text to speech. Hope to get the tool working again soon: https://mdwiki.org/wiki/Video:Tuberculosis
A nice example of a) creating a space explicitly to develop new tools and encourage one another in using them; b) trialing a workflow that can be automated at need.
Text-to-speech and animation tools have also advanced tremendously since that was produced; this is also becoming an important channel for more mainstream media (I see the spammers taking over mainstream social media with it as well, in how-tos, education, news, sports, and leisure).
SJ
On Tue, Jan 30, 2024 at 2:25 AM Ivan Martínez galaver@gmail.com wrote:
It is not difficult to do something that is already happening. By referring to encyclopedic videos I am talking about multimedia that can enrich existing content. I understand your point, it's a bit like what happened with the project of reading recorded Wikipedia articles that after years seem obsolete.
What I am referring to is all that multimedia material that is visual, that can be made into video to complement articles. The process you mention is complicated, but not impossible, in fact, there are many of us editors who have all those skills already implemented in the projects.
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure encyclopaedic videos. I see a false dilemma there.
brion wrote:
My recommendations for Wikimedia Foundation on this subject:
- Overturn the requirement to avoid handling h.264 files on Wikimedia servers or accept them from users or serve them to users. Allow importing h.264 uploads and creating h.264 transcodes for playback compatibility.
- Create an interactive media team with at least two engineers, a designer, and a project manager
- Give this team a remit to rebuild *and maintain in an ongoing fashion* the existing TimedMediaHandler, Graphs, Score, 3D, etc extensions
- Integrate those tools cleanly with mobile apps and social media embedding tools managed by other teams
Wikimedia-l mailing list -- 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
Hi,
Could somebody explain what is problem with VP9 or AV1 with WebM container? These are supported in Wikimedia Commons.
Br, -- Kimmo Virtanen / Zache
On Tue, Jan 23, 2024 at 11:05 PM Brion Vibber bvibber@wikimedia.org wrote:
Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman jmh649@gmail.com wrote:
It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta < paulosperneta@gmail.com> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta paulosperneta@gmail.com escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga galder158@hotmail.com escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved ( https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
- Graph extension is used in thousands of pages, some of them
highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution.
- Meanwhile, a place like Our World in Data has been publishing
data and interactive content with a compatible license for years. (Remember, "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy ( https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving
interactive solutions to knowledge questions, even the silliest ones ( https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "*becoming the essential infrastructure of the ecosystem of free knowledge*" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge".
- Brilliant (https://brilliant.org/) is brilliant if you want to
learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms?
- We can build interactive timelines using Wikidata, but we can't
embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/ http://histropedia.com/
- We could have something very special: inline links in video and
audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that.
- ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" ( https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- 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
Wikimedia-l mailing list -- 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
Thanks for bringing this also, Xavier. Last Wikimania I went to a great session about the new tools the Research Team is building. Most of them are really useful. It's a pity I can't find them if I don't try to search specifically for them, and that no one will ever find them because we don't have those tools are external and not integrated in our platforms. This is another great example of the lack of ambition in the product infrastructure.
I really hope someone will handle these issues, but I have more doubts that it will happen by the day.
Have a nice weekend to those that have weekends,
Galder ________________________________ From: Kimmo Virtanen kimmo.virtanen@wikimedia.fi Sent: Friday, January 26, 2024 12:23 PM To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi,
Could somebody explain what is problem with VP9 or AV1 with WebM container? These are supported in Wikimedia Commons.
Br, -- Kimmo Virtanen / Zache
On Tue, Jan 23, 2024 at 11:05 PM Brion Vibber <bvibber@wikimedia.orgmailto:bvibber@wikimedia.org> wrote: Converting them to suitably compact files in h.264/aac in .MP4 format would be by far the simplest way. Use ffmpeg as we do on the server side for online playback.
Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll play in standalone files (not in HLS)
If you jump through enough hoops you might get vp9 working in HLS offline, but adaptive streaming may be irrelevant to offline use.
-- brion
On Tue, Jan 23, 2024, 12:52 PM James Heilman <jmh649@gmail.commailto:jmh649@gmail.com> wrote: It would be amazing if one could play videos on iPhones when the videos are within ZIMs in an offline environment aswell. Brion not sure what barriers there are to this currently?
James
On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta <paulosperneta@gmail.commailto:paulosperneta@gmail.com> wrote: Should read 2030 Strategy, not 2023 strategy, sorry.
Paulo Santos Perneta <paulosperneta@gmail.commailto:paulosperneta@gmail.com> escreveu (terça, 23/01/2024 à(s) 19:41): I wholeheartedly agree with this sentiment. We are currently grappling with rather rudimentary approaches when it comes to uploading and reusing video and music files... The incredibly useful Graph has been down for quite some time. The extensive capabilities of Wikidata query representations, particularly with geolocated data on maps, appear to have barely scratched the surface. Listeria frequently experiences issues and underwent a major update that disrupted previous queries.
On a personal note, I attempted to create a dynamic digital library of works under a free license using Wikidata for our Digital Humanistics centre. However, I discovered that with the available tools, I would need to code the presentation myself, as the options for reuse outside of Wikidata were very basic.
On the whole, the Wikipedia experience remains challenging, especially for newcomers. The much wanted Visual Editor developments and improvements seem to have stopped years ago. The recent changes made by the 'Desktop Improvement' team to the default Wikipedia skin seem to be more geared towards readers than editors and have apparently worsened the overall experience, according to feedback I've received from newcomers.
These are just a few instances that have underscored, and continue to underscore, my belief that we are likely not on the path towards achieving the objectives outlined in the 2023 Strategy.
My personal impression is that the issue doesn't necessarily stem from a lack of funding to pursue these objectives but rather from the ineffective expenditure and allocation of those funds. I wish I knew how to contribute to changing or improving this situation. It would also be great to see a comment/opinion from current CEO Maryana Iskander on this state of affairs, and if there is some roadmap for improving it.
Best, Paulo
Galder Gonzalez Larrañaga <galder158@hotmail.commailto:galder158@hotmail.com> escreveu (terça, 23/01/2024 à(s) 11:03): Dear wikimedians, Nearly one year ago, the Graphs extension was disabled from all wikis, because there was a security issue that should be solved (https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on a solution for some weeks, but after Northern Hemisphere spring ended, summer came, then the monsoon season, and now it is again summer in the Southern Hemisphere... and Graphs are still disabled. All the solutions proposed have been dismissed, but every two months there's a proposal to make a new roadmap to solve the issue. We have plenty of roadmaps, but no vehicle to reach our destination.
Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge". We also made some recommendations to improve the User Experience (https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge (https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i...). Well, the situation is now worse than it was seven years ago, let me give some examples:
* Graph extension is used in thousands of pages, some of them highly relevant, as COVID or Climate Change information. There are thousands of graphs broken now, and the only partial solution give is loading these graphs as images, instead of promoting an interactive solution. * Meanwhile, a place like Our World in Data has been publishing data and interactive content with a compatible license for years. (Remember, "By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge"). Trying to add this data and graphs to Wikimedia projects has been done by WikiMed, and it is technically possible, but still blocked to deploy (https://phabricator.wikimedia.org/T303853). * Wolfram Alpha is like a light year ahead us on giving interactive solutions to knowledge questions, even the silliest ones (https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). We have good technical articles about a lot of things, but sometimes "becoming the essential infrastructure of the ecosystem of free knowledge" needs to provide solutions to exact problems, like the answer to an equation, and how to solve it. That's also "free knowledge". * Brilliant (https://brilliant.org/) is brilliant if you want to learn lots of things, like geometry or programming. Way better than Wikipedia. But... you need to pay for it. How could we even try if we can't add anything interactive to our platforms? * We can build interactive timelines using Wikidata, but we can't embed them at Wikipedia. Weird, because I can do it in any external page. Hopefully, Histropedia will do it better. http://histropedia.com/http://histropedia.com/ * We could have something very special: inline links in video and audio subtitles. We used to have them, but the new video infrastructure doesn't allow it. Imagine a world where you can watch a video and link a link in the subtitles just to know more about that. * ...
The list can go on an on ("which phase the moon is today?"), but I think that the idea is clear. We could have interactive content, but we are going in the opposite direction, and every year we are further from our goal, because other platforms are doing it better, way better. And this seems like some wild ideas, but then I read the 2023-2024 annual plan section called "Wiki Experiences" (https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/G...) and it looks like we should be going there. But we aren't.
I'm sorry if this e-mail feels bitter. My experience in the last years is that we are now further of what we need that we were before, even if many chapters and volunteers are trying to overturn it.
Thank to everyone who have been trying.
Galder
_______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.orgmailto: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.orgmailto:wikimedia-l-leave@lists.wikimedia.org
On Fri, Jan 26, 2024 at 1:23 PM Kimmo Virtanen kimmo.virtanen@wikimedia.fi wrote:
Could somebody explain what is problem with VP9 or AV1 with WebM container? These are supported in Wikimedia Commons.
OK, I will try to answer my own question:
AV1 is technically superior to h.264 in terms of file size and quality as it is one generation newer. h.265 (HVEC) would be in quality level than AV1, but there is licence fee for using it and open source tools support is better for AV1 than h.265. If we include closed source encoders then h.265 encoders are in ame level than open source AV1 encoders. AV1 is generally widely used as it is used by Netflix and Youtube etc.
Browser support for AV1 seems to be OK - https://caniuse.com/?search=VP9
The missing thing is that hardware support is in the transition phase. Ie. Most notably, widely available Apple support is missing as it supports AV1 only devices where there is hardware support for decoding. Apple added hardware decoding AV1 support to its latest generation chipsets (A17, M3).
On Android Google defined that AV1 support is mandatory for Android 14 (released 2023) compliance.
On PC side hardware decoding / encoding support has been added like this * AMD RDNA2 = AV1 decode (released 2020) * AMD RDNA3 = AV1 decode/encode (released 2022) * Intel 11th gen = AV1 decode (released 2021) * Intel 14th gen = AV1 decode/encode (released 2023)
So, all new devices which are released in 2024 will support AV1 and in a couple years perspective the devices which don't support AV1 are legacy ones. Hardware decoding is relevant for mobile devices as without it power consumption would be too high even if the device could decode the stream. Legacy desktop computers can do the software decoding in terms of CPU/GPU performance required.
Br, -- Kimmo Virtanen, Zache
From my non-lawyer reading of the Wikipedia page on the topic, the patent is for the devices or hardware that reads the files, not on those that distribute or make the files.
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
Since we do not manufacture hardware. Not seeing the issue.
James
On Sat, Jan 27, 2024 at 1:11 AM Kimmo Virtanen kimmo.virtanen@wikimedia.fi wrote:
On Fri, Jan 26, 2024 at 1:23 PM Kimmo Virtanen < kimmo.virtanen@wikimedia.fi> wrote:
Could somebody explain what is problem with VP9 or AV1 with WebM container? These are supported in Wikimedia Commons.
OK, I will try to answer my own question:
AV1 is technically superior to h.264 in terms of file size and quality as it is one generation newer. h.265 (HVEC) would be in quality level than AV1, but there is licence fee for using it and open source tools support is better for AV1 than h.265. If we include closed source encoders then h.265 encoders are in ame level than open source AV1 encoders. AV1 is generally widely used as it is used by Netflix and Youtube etc.
Browser support for AV1 seems to be OK
The missing thing is that hardware support is in the transition phase. Ie. Most notably, widely available Apple support is missing as it supports AV1 only devices where there is hardware support for decoding. Apple added hardware decoding AV1 support to its latest generation chipsets (A17, M3).
On Android Google defined that AV1 support is mandatory for Android 14 (released 2023) compliance.
On PC side hardware decoding / encoding support has been added like this
- AMD RDNA2 = AV1 decode (released 2020)
- AMD RDNA3 = AV1 decode/encode (released 2022)
- Intel 11th gen = AV1 decode (released 2021)
- Intel 14th gen = AV1 decode/encode (released 2023)
So, all new devices which are released in 2024 will support AV1 and in a couple years perspective the devices which don't support AV1 are legacy ones. Hardware decoding is relevant for mobile devices as without it power consumption would be too high even if the device could decode the stream. Legacy desktop computers can do the software decoding in terms of CPU/GPU performance required.
Br, -- Kimmo Virtanen, Zache
Wikimedia-l mailing list -- 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
On Tue, Jan 23, 2024 at 12:03 PM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
We have plenty of roadmaps, but no vehicle to reach our destination. Seven years ago, we were discussing our Strategy for 2030. We used thousands of volunteer hours, thousands of staff hours and millions of dollars to build a really well-balanced strategy. There we concluded that "*By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge*". We also made some recommendations to improve the User Experience ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_Us...) and claimed that we wanted to Innovate in Free Knowledge ( https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_i... ).
cool summary, galder! there is one sentence in there:
Build the necessary technology to make free knowledge content accessible in various formats. Support more diverse modes of consumption and contribution https://meta.wikimedia.org/wiki/Special:MyLanguage/Strategy/Wikimedia_movement/2018-20/Recommendations/Glossary#Contributor to our projects (e.g. text, audio, visual, video, geospatial, etc.).
the result is not so satisfying, i'd say. alone on this list, the only discussion which comes out of such a sentence is we should put mp4 on commons or not? really? of course i am exaggeration a little. but galder has a point that wikipedia was disruptive 20 years ago and not so much curently. admitted, it is kind of natural that an innovative company looses the power to innovate over time, this is not necessarily true for volunteer organisations. lodewijk showed it by launching a foto competition which turned out to be the biggest one on this planet. it attracted people who were not in the movement before, with ideas which we did not have in the movement before. with the example in content space, there is no reason to believe that approach would not work for technical innovation as well. money is no problem, hosting is no problem, global reach and glory is not an issue. we could create some "wiki loves new tech" competition, and, say, pout 100 million into a five year program to do this, what you think? use for example the price money to productize stuff, and not care too much if 9 out of 10 ideas fail. one out of ten will be good enough to disrupt.
rupert
wikimedia-l@lists.wikimedia.org