Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm
Honestly, I find the "not in the annual plan" thing more damning than the actual issue at hand.
The core competency of WMF is supposed to be keeping the site running. WMF does a lot of things, some of them very useful, others less so, but at its core its mission is to keep the site going. Everything else should be secondary to that.
It should be obvious that running a 300 TB+ media store servicing 70 billion requests a month requires occasional investment and maintenance
And yet, this was not only not in this year's annual plan, it has been ignored in the annual plan for many many years. We didn't get to this state by just 1 year of neglect.
Which raises the question - If wmf is not in the business of keeping the Wikimedia sites going, what is it in the business of?
On Tue, Jan 11, 2022 at 6:01 AM Kunal Mehta legoktm@debian.org wrote:
Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
(Speaking in my volunteer capacity) I doubt there is any malicious intent by WMF. I personally think the underlying problem is time. Let me explain.
Fixing a big issue in software takes time (I wrote a long essay about it in this thread) so it makes sense WMF annual planning to focus on issues before they get to a level that hinders community's work. The problem is that an issue doesn't get enough attention if it's not severe enough to affect users so the cycle of frustration continues. For example, I sent an email in February 2021, at the start of annual planning, to one of the directors at product outlining all of the issues of multimedia stack. Because at that point, it wasn't this bad, it didn't make it to FY21-22 plans. Now I feel like a cassandra. We have similar issues in lots of other places that will lead to frustration. Load balancers (pybal), dumps, beta cluster, flagged revs, patrolling tools, etc. etc.
On Tue, Jan 11, 2022 at 8:21 AM bawolff bawolff+wn@gmail.com wrote:
Honestly, I find the "not in the annual plan" thing more damning than the actual issue at hand.
The core competency of WMF is supposed to be keeping the site running. WMF does a lot of things, some of them very useful, others less so, but at its core its mission is to keep the site going. Everything else should be secondary to that.
It should be obvious that running a 300 TB+ media store servicing 70 billion requests a month requires occasional investment and maintenance
And yet, this was not only not in this year's annual plan, it has been ignored in the annual plan for many many years. We didn't get to this state by just 1 year of neglect.
Which raises the question - If wmf is not in the business of keeping the Wikimedia sites going, what is it in the business of?
On Tue, Jan 11, 2022 at 6:01 AM Kunal Mehta legoktm@debian.org wrote:
Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and
the
Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
I agree a bit with both Kunal and Asaf here,
I do not think our goal is to get it done **by paid WMF staff**, but it is also true that today that is the only viable alternative to get major technical work done. I do not think it is entirely fair to state that "status quo can be changed by just about anyone who is motivated to do so (...) just by doing the work". It is not a lack of motivation that hinders our movement technically, but a lack of resources and shared governance. I am not sure if the implication is that the movement should be expecting free (expensive) labor to fix these issues, but even then there is a very high bar for engagement with the technical community in order to have access and a significant bottleneck in both technical review of changes and engagement with technical and other communities for changes that impact them.
It is not only unfair to expect this to be solved by volunteer developers, it is not working. Why should we expect this will change?
Open source and accepting volunteer contributions is nowhere near where our goal should be. We need better governance and distribution of resources and responsibilities to volunteer **and professional** organizations that can bridge the gaps in our technological stack.
How we move from a state where WMF is doing all the technical development and deciding technical choices is a bigger issue. And perhaps it is in that issue that we will find an answer on how to improve the state of our tech ecosystem. How do we get from a WMF-centered development model to a decentralized one?
It is a bit disappointing the lack of emphasis our movement placed in this discussion in our strategy process thus far; and how we have set aside the little that did make to the recommendations in this area since they were published.
Chico Venancio
Em ter., 11 de jan. de 2022 às 03:01, Kunal Mehta legoktm@debian.org escreveu:
Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
It seems to me there are *very few* people who could change status quo, not much more than a handful: the Foundation's executive leadership (in its annual planning work, coming up this first quarter of 2022), and the Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
[1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815
-- Legoktm _______________________________________________ Commons-l mailing list -- commons-l@lists.wikimedia.org To unsubscribe send an email to commons-l-leave@lists.wikimedia.org
On Tue, 11 Jan 2022 at 12:17, Chico Venancio chicocvenancio@gmail.com wrote:
I do not think our goal is to get it done **by paid WMF staff**, but it is also true that today that is the only viable alternative to get major technical work done. I do not think it is entirely fair to state that "status quo can be changed by just about anyone who is motivated to do so (...) just by doing the work". It is not a lack of motivation that hinders our movement technically, but a lack of resources and shared governance.
As someone who has tried to contribute using some of my "Covid time", and who will shortly be going back to real work, it's also deeply frustrating if you cannot meaningfully contribute incrementally, but run into a lack of interest in engaging with issues. If someone has come along with even a half-decent bug report, it's possible that that represents about an hour or so of work: detecting the bug, isolating it, creating a Phab account, writing the report all take time. An hour of time is actually a lot for someone who commutes to a 9 to 5, let alone someone with family.
Now, if that person wants to _fix_ the bug, it took me, very roughly[1], three working days to get to a position where I could even run Mediawiki locally with the right extensions in Docker[2], figure out the code, find out enough about PHP to make a change, actually make the changes, and propose a patch for a simple issue, and respond to the inevitable CI issues because you can't get the tests to work locally. If I had been doing that in the time between getting home from the office and making dinner, that's a month of work, and would replace all my other interests into the bargain. It's _also_ frustrating when you then get the patch -1'd because you tried to follow existing code, but that's actually old and busted and you should use the new hotness that everyone inside the engineering team might know, but is highly non-obvious to a person who only cloned the repo on Monday. Every review response or rebase also takes a good chunk of time, especially if the patch has "gone cold". And then there's a good chance your it just rots on Gerrit anyway until you have moved on with your life.
I think (making stuff up alert) a reason people want the WMF to help here is not just because they collect more than the GDP of Nauru[3] per year on the implication that they it supports the wikis, but also because they actually employ people specifically because they _do_ know how to do this stuff effectively, and what is a month of sacrificed hobbies for one poor sap is half an hour for them. That's a hell of a force multiplier if there was just slack in the engineering to allow it. Teach a man to fish and tomorrow he might help you repair your jetty. Expect a man to figure out how to mine iron for fish hooks on his own and reverse engineer a fishing rod, and he'll be hungry for a good while and your jetty is going to stay broken if he wanders off in search of something other than fish to eat.
Now, sure, you can say "well it's not the WMF's fault that you have a job/family/commute/other hobbies/a herd of depressed pet llamas in constant need of hugs, is it?" and yes, you are right, they don't officially _owe_ anyone anything. However, it's also a shame to completely write off the ability of llama-owners to contribute, unless they're willing to put in more time or effort than very many people have to spare. Honestly, if I hadn't had Covid time, I would have given up on any patch after the first several hours and just walked away[4]. And that would have been a shame for me (I'll let others decide if it would be a shame for the software!)
So I guess the tl;dr here is that actually a relatively small amount of care[5] from the WMF can multiply the effectiveness of outside contributions greatly. Those contributions, in turn, can magnify the ability of the Communities themselves to Get Content Done[6]. And that's the aim here, is it not? We're all on the same side!
--IL
[1] I mean, what did time even mean in 2021, anyway?! [2] Since then, Docker has gotten better, though I still can't get Phan to work with any regularity, and it doesn't really feel like any "staff" developers actually use the method described in CONTRIBUTING.md to run up MediaWiki very often. [3] Yes, really. To be fairrrr, it's a very small island. [4] In fact, before Covid, I tried to do some patches and did exactly that, more than once. [5] Developer Advocacy is a team that exists, but at least in my personal experience, I have never actually encountered it, except for bug wrangling. [6] Perfect example: ProofreadPage is pretty much entirely non-core tech and yet has facilitated almost all work on Wikisource for a decade. I'm not sure such a system could be written and deployed today.
I probably have the best understanding of the thumbnailing system among volunteers at the moment, but I'm not interested in bailing out the WMF on this one.
The fundamental purpose of the WMF is to support the continued operation of the wikis by maintaining technical infrastructure. There is not a single Wikimedia wiki that does not use Thumbor. Nevertheless, maintenance was largely left to a single maintainer working on Thumbor as a side project, in addition to their normal responsibilities. That was a decision made or supported by WMF management. When that single maintainer left the Foundation, there was no one else to maintain the system.
Sure, I or other volunteers could get appropriate access and finish off the Thumbor python3 and Debian migrations. But that just kicks the can down the road instead of actually solving the problem. Maintenance of a critical system would still be dependent on one person (or more optimistically, a few people) working in their spare time with no plan for continuity. That just puts us back to the position we were in a year ago, which we now know is not sustainable.
Critical infrastructure not directly supported by a WMF team, with a plan for continued maintenance if a core maintainer leaves, has been a well-documented risk since before the WMF was created. Yet this is not the first example of WMF management deferring maintenance from production systems. In the case of Wikimedia Maps, a full production outage was necessary before WMF management decided Maps was worth maintaining. DPL echos a similar tale. What else has to fail before WMF management starts taking this seriously?
ACN
On Tue, Jan 11, 2022 at 8:31 AM Inductiveload inductiveload@gmail.com wrote:
On Tue, 11 Jan 2022 at 12:17, Chico Venancio chicocvenancio@gmail.com wrote:
I do not think our goal is to get it done **by paid WMF staff**, but it is also true that today that is the only viable alternative to get major technical work done. I do not think it is entirely fair to state that "status quo can be changed by just about anyone who is motivated to do so (...) just by doing the work". It is not a lack of motivation that hinders our movement technically, but a lack of resources and shared governance.
As someone who has tried to contribute using some of my "Covid time", and who will shortly be going back to real work, it's also deeply frustrating if you cannot meaningfully contribute incrementally, but run into a lack of interest in engaging with issues. If someone has come along with even a half-decent bug report, it's possible that that represents about an hour or so of work: detecting the bug, isolating it, creating a Phab account, writing the report all take time. An hour of time is actually a lot for someone who commutes to a 9 to 5, let alone someone with family.
Now, if that person wants to _fix_ the bug, it took me, very roughly[1], three working days to get to a position where I could even run Mediawiki locally with the right extensions in Docker[2], figure out the code, find out enough about PHP to make a change, actually make the changes, and propose a patch for a simple issue, and respond to the inevitable CI issues because you can't get the tests to work locally. If I had been doing that in the time between getting home from the office and making dinner, that's a month of work, and would replace all my other interests into the bargain. It's _also_ frustrating when you then get the patch -1'd because you tried to follow existing code, but that's actually old and busted and you should use the new hotness that everyone inside the engineering team might know, but is highly non-obvious to a person who only cloned the repo on Monday. Every review response or rebase also takes a good chunk of time, especially if the patch has "gone cold". And then there's a good chance your it just rots on Gerrit anyway until you have moved on with your life.
I think (making stuff up alert) a reason people want the WMF to help here is not just because they collect more than the GDP of Nauru[3] per year on the implication that they it supports the wikis, but also because they actually employ people specifically because they _do_ know how to do this stuff effectively, and what is a month of sacrificed hobbies for one poor sap is half an hour for them. That's a hell of a force multiplier if there was just slack in the engineering to allow it. Teach a man to fish and tomorrow he might help you repair your jetty. Expect a man to figure out how to mine iron for fish hooks on his own and reverse engineer a fishing rod, and he'll be hungry for a good while and your jetty is going to stay broken if he wanders off in search of something other than fish to eat.
Now, sure, you can say "well it's not the WMF's fault that you have a job/family/commute/other hobbies/a herd of depressed pet llamas in constant need of hugs, is it?" and yes, you are right, they don't officially _owe_ anyone anything. However, it's also a shame to completely write off the ability of llama-owners to contribute, unless they're willing to put in more time or effort than very many people have to spare. Honestly, if I hadn't had Covid time, I would have given up on any patch after the first several hours and just walked away[4]. And that would have been a shame for me (I'll let others decide if it would be a shame for the software!)
So I guess the tl;dr here is that actually a relatively small amount of care[5] from the WMF can multiply the effectiveness of outside contributions greatly. Those contributions, in turn, can magnify the ability of the Communities themselves to Get Content Done[6]. And that's the aim here, is it not? We're all on the same side!
--IL
[1] I mean, what did time even mean in 2021, anyway?! [2] Since then, Docker has gotten better, though I still can't get Phan to work with any regularity, and it doesn't really feel like any "staff" developers actually use the method described in CONTRIBUTING.md to run up MediaWiki very often. [3] Yes, really. To be fairrrr, it's a very small island. [4] In fact, before Covid, I tried to do some patches and did exactly that, more than once. [5] Developer Advocacy is a team that exists, but at least in my personal experience, I have never actually encountered it, except for bug wrangling. [6] Perfect example: ProofreadPage is pretty much entirely non-core tech and yet has facilitated almost all work on Wikisource for a decade. I'm not sure such a system could be written and deployed today. _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
On Tue, 2022-01-11 at 13:30 +0000, Inductiveload wrote:
[5] Developer Advocacy is a team that exists, but at least in my personal experience, I have never actually encountered it, except for bug wrangling.
If you're interested in what that (my) team is doing, I recommend checking out https://www.mediawiki.org/wiki/Developer_Advocacy
Spoiler: Improving Small Wiki Toolkits, working on a Developer Portal and improving related technical docs, organizing Outreach Programs, maintaining Community Metrics, sorting out the next Hackathon, helping with the Coolest Tool Award (which happened two weeks ago), etc...
Hope that provides a bit of an impression? :)
Cheers, andre
Hi everyone,
Andre, It is really good to see a major transformation in recent years. Since I am part of this transformation, I can say that it is already really going in a very good direction. But few things to note:
1. *Lack of staff*: WMF's Developer Advocacy has 6 staff for the globe. I had a recent experience with Google India's Developer Relations team. They had 5-8 members, just for a single county. I know comparison should have other factors as well but the gap is too far. Even Mozilla is outnumbering us. Another thing that I also noticed is that some WMF staff are part of multiple teams.
2. *No Wikimedia outreach program*: As far as I know WMF does not run its own outreach program. We are/were the only participant organization in various programs like Outreachy, Google Summer of Code, and Google Code-In. Wikimedia itself is a big name so we can attract many students with Wikimedia internship certificates without any stipend expenses.
3. *No partnership with the external organization*: As far as I know WMF did not collaborate with external organizations regarding technical partnerships and campaigns. Last year, two profit organizations, Intel and DigitalOcean, organized Hacktoberfest, an amazing month of open source love. They got 294,451 accept pull requests for open source projects. Profit organizations are running campaigns for open source software but we can't. (I know they have an advertisement factor but the point is open source campaigns). Why can't we?
I am not blaming anything on the current Developer Advocacy team. I worked with many members very closely as a volunteer. They are already working to their full capacity. But upper management has to break the glass. Otherwise, we will just fix/mingle with current problems within a single bubble.
Regards,
Jay Prakash, Volunteer Developer
On Fri, Jan 28, 2022 at 11:46 PM Andre Klapper aklapper@wikimedia.org wrote:
On Tue, 2022-01-11 at 13:30 +0000, Inductiveload wrote:
[5] Developer Advocacy is a team that exists, but at least in my personal experience, I have never actually encountered it, except for bug wrangling.
If you're interested in what that (my) team is doing, I recommend checking out https://www.mediawiki.org/wiki/Developer_Advocacy
Spoiler: Improving Small Wiki Toolkits, working on a Developer Portal and improving related technical docs, organizing Outreach Programs, maintaining Community Metrics, sorting out the next Hackathon, helping with the Coolest Tool Award (which happened two weeks ago), etc...
Hope that provides a bit of an impression? :)
Cheers, andre -- Andre Klapper (he/him) | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/ _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
While i'm sure there is always more that can be done in terms of attracting new devs, i don't think that's really where we have the problem. We have lots of interested people. Enwiki is basically a huge captive audience of interested people.
I think the problem lies more in the developer experience after people join. It is politically difficult to get stuff merged with long lag times. That's frustrating to people who want to fix bugs as opposed to play politics, and its really difficult for outsiders who don't have the internal social connections, not to mention the time availability to always be responsive as opposed to just being available to contribute a couple hours on the weekend.
-- Bawolff
On Friday, January 28, 2022, Jay prakash 0freerunning@gmail.com wrote:
Hi everyone,
Andre, It is really good to see a major transformation in recent years. Since I am part of this transformation, I can say that it is already really going in a very good direction. But few things to note:
- *Lack of staff*: WMF's Developer Advocacy has 6 staff for the globe. I
had a recent experience with Google India's Developer Relations team. They had 5-8 members, just for a single county. I know comparison should have other factors as well but the gap is too far. Even Mozilla is outnumbering us. Another thing that I also noticed is that some WMF staff are part of multiple teams.
- *No Wikimedia outreach program*: As far as I know WMF does not run its
own outreach program. We are/were the only participant organization in various programs like Outreachy, Google Summer of Code, and Google Code-In. Wikimedia itself is a big name so we can attract many students with Wikimedia internship certificates without any stipend expenses.
- *No partnership with the external organization*: As far as I know WMF
did not collaborate with external organizations regarding technical partnerships and campaigns. Last year, two profit organizations, Intel and DigitalOcean, organized Hacktoberfest, an amazing month of open source love. They got 294,451 accept pull requests for open source projects. Profit organizations are running campaigns for open source software but we can't. (I know they have an advertisement factor but the point is open source campaigns). Why can't we?
I am not blaming anything on the current Developer Advocacy team. I worked with many members very closely as a volunteer. They are already working to their full capacity. But upper management has to break the glass. Otherwise, we will just fix/mingle with current problems within a single bubble.
Regards,
Jay Prakash, Volunteer Developer
On Fri, Jan 28, 2022 at 11:46 PM Andre Klapper aklapper@wikimedia.org wrote:
On Tue, 2022-01-11 at 13:30 +0000, Inductiveload wrote:
[5] Developer Advocacy is a team that exists, but at least in my personal experience, I have never actually encountered it, except for bug wrangling.
If you're interested in what that (my) team is doing, I recommend checking out https://www.mediawiki.org/wiki/Developer_Advocacy
Spoiler: Improving Small Wiki Toolkits, working on a Developer Portal and improving related technical docs, organizing Outreach Programs, maintaining Community Metrics, sorting out the next Hackathon, helping with the Coolest Tool Award (which happened two weeks ago), etc...
Hope that provides a bit of an impression? :)
Cheers, andre -- Andre Klapper (he/him) | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/ _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l. lists.wikimedia.org/
În mar., 11 ian. 2022 la 08:01, Kunal Mehta legoktm@debian.org a scris:
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
Counterexample: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/m... (this was the situation that I quoted in my first email on this thread as the WMF refusing to even do reviews).
Maybe it's just the multimedia part that it's in this desperate situation, but I can totally see volunteer developers getting discouraged quickly if their patches are outright ignored.
Strainu
Hello, I'd like to refer to the original subject of the discussion - tomorrow is the last day for submitting proposals for the Community Wishlist Survey 2022.
Apart from that, everyone is welcome to translate, promote, and discuss proposals: https://diff.wikimedia.org/2022/01/10/what-improvements-in-wikimedia-platfor...
Best wishes,
Szymon Grabarczuk (he/him)
Community Relations Specialist
Wikimedia Foundation
On Wed, Jan 12, 2022 at 2:43 PM Strainu strainu10@gmail.com wrote:
În mar., 11 ian. 2022 la 08:01, Kunal Mehta legoktm@debian.org a scris:
So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly.
Counterexample:
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/m... (this was the situation that I quoted in my first email on this thread as the WMF refusing to even do reviews).
Maybe it's just the multimedia part that it's in this desperate situation, but I can totally see volunteer developers getting discouraged quickly if their patches are outright ignored.
Strainu _______________________________________________ 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
wikitech-l@lists.wikimedia.org