Talk:Movement Strategy/Recommendations/Iteration 3/Plan Infrastructure Scalability
- The following discussion is closed. Please do not modify it.
Open, facilitated community conversations have finished. You are welcome to continue commenting and discussing, but the discussions will not be as closely facilitated and documented.
Thank you to everyone who shared their input. To learn about what’s next, visit our FAQ page.
Communication solutions and processes
edit- Invest in communication solutions and processes to support community discussions, participatory decision-making, and consensus-building at scale.
Does this mean we can agree to use the wikis for discussions and decision making, to which the community by definition has access, instead of Facebook, to which many of us don't because we value our privacy, or "Spaces," and mailing lists, which both require divulging email addresses or making new ones, and other non-wiki forums, please? EllenCT (talk) 04:52, 21 January 2020 (UTC)
- Hi @EllenCT! The recommendation is intentionally agnostic about what the best solution would be. Different approaches have different benefits and drawbacks (e.g. wiki talk pages are already familiar to the existing community and well integrated into existing workflows, but it's harder to make them usable for newcomers, and they fragment discussions because the wikis themselves are fragmented). 2020 will be the implementation phase of the strategy process: if the recommendation is accepted, that phase will be the place to research and make decisions on what the best methods are, guided by the early, more verbose draft recommendations from the strategy working groups (in this case that would be Support Community Decision-making which has some thoughts on what should be expected from such a system). --Tgr (talk) 05:04, 21 January 2020 (UTC)
- @Tgr: So this is actually a proposal to build something new that is "accessible, inclusive and multilingual, handles disruption and toxic behavior, allows community self-moderation, supports task management, review, refactoring and summarization and workflows, supports voting and similar formal decision making processes, and nudges participants towards constructive, thoughtful and scalable interaction norms"? EllenCT (talk) 05:08, 21 January 2020 (UTC)
- @EllenCT: in the sense of creating a new discussion space vs. improving an existing one (or many existing ones), the recommendation is agnostic. (There is some related discussion on the talk page of the earlier version of that recommendation. It's a bit of a maze, I know.) Adding such features to wikitext-based talk pages is one possible implementation choice. In the sense of building new software features, yeah, I don't see how it could be accomplished without that. --Tgr (talk) 06:43, 21 January 2020 (UTC)
- @Tgr: are there Phabricator task(s) for this work? And I wonder, which of those criteria do we think wikis are incapable of without modifications? EllenCT (talk) 17:07, 21 January 2020 (UTC)
- @EllenCT: I imagine there are tasks here and there about some such features (e.g. issues with multilingual content in MediaWiki), but nothing systematic. As for your other question, none of these are well-suported currently - talk pages have poor accessibility (try to add text in the middle of a huge discussion using a screen reader), multilingual support is not great (as we have seen right here in these discussions), refactoring is hard enough that it basically never happens, dealing with hostile behavior is hard because it is cumbersome to hide individual comments, there is no way to identify good or popular comments etc. There's a reason more and more discussions are shifting to Facebook and similar external channels, despite those being somewhat in conflict with Wikimedia's values. --Tgr (talk) 07:46, 24 January 2020 (UTC)
- @Tgr: are there Phabricator task(s) for this work? And I wonder, which of those criteria do we think wikis are incapable of without modifications? EllenCT (talk) 17:07, 21 January 2020 (UTC)
- @EllenCT: in the sense of creating a new discussion space vs. improving an existing one (or many existing ones), the recommendation is agnostic. (There is some related discussion on the talk page of the earlier version of that recommendation. It's a bit of a maze, I know.) Adding such features to wikitext-based talk pages is one possible implementation choice. In the sense of building new software features, yeah, I don't see how it could be accomplished without that. --Tgr (talk) 06:43, 21 January 2020 (UTC)
- @Tgr: So this is actually a proposal to build something new that is "accessible, inclusive and multilingual, handles disruption and toxic behavior, allows community self-moderation, supports task management, review, refactoring and summarization and workflows, supports voting and similar formal decision making processes, and nudges participants towards constructive, thoughtful and scalable interaction norms"? EllenCT (talk) 05:08, 21 January 2020 (UTC)
- Once again I'm genuinely concerned that if I support the very vague set of aspirations, I'm going to hear of an unhelpful implementation with the words "as supported by the Community" (etc). I'm sorry that Tgr gets more of a brusque nbb - but it's been a bit of an ongoing theme. @Tgr: - will the discussion stage for implementation be delayed until the Talk Page work has been done? It would be impossible for us to make an informed choice until that set of changes (which should hopefully make TPs much easier for newcomers) has been implemented. Nosebagbear (talk) 11:25, 23 January 2020 (UTC)
- @Nosebagbear: I doubt two different projects for improving discussions would be run in parallel; even if we think wikitext cannot ultimately be used to meet these goals (I personally doubt it could, but then I'm not an expert on the topic), it seems bad for pragmatic reasons: you'd probably want to have the same group of people work on both projects, as they have now built considerable expertise; and it would be confusing to the editors. But then, as with all large-scale consensus processes, anything I say to you beyond what's in the text is just my opinion. I'm just a volunteer; I won't control implementation; I don't think it's even decided yet who will (assuming there will be an implementation).
- In general, I would recommend when you think something could be valuable, but are worried it could be done in a bad way or misused, then instead of worrying too much about a binary support / oppose decision, just write a conditional statement: explain what are the conditions along which you'd support thing. Or don't support at all, just explain your hopes and fears. I imagine that's the kind of feedback that will be most useful when decisions need to be made about what to take forward and how. --Tgr (talk) 07:46, 24 January 2020 (UTC)
Outlining Hegelian epistemology
editI noticed the wikipedia talk pages had little traffic, so I am cross-posting this here. Similar concerns could be expressed among all of the recommendations. Below is an explanation of the issue with the overall outline and the first paragraph:
"What Why How" appears to be a derivative of the so-called Hegelian triad (en:Thesis, antithesis, synthesis). As Hegel's thought was adapted over the centuries there are a variety of applications of this triad, such as en:David Icke#Problem–reaction–solution. If you review that last wikilink, look at reference 151.
The problem with this form of thinking was outlined by en:C. West Churchman in his Inquiring Systems. A more basic illustration is the Dilbert cartoon where the pointy-haired boss and the various staff members frequently talk past each other. The different epistemological frameworks and problem solving systems involved are at least partly to blame for this.
So, my response is, "how would this read if it were not written in Hegelian epistemology?"--Such as, how would this article look if it were written in the Lockean, Lebnitzian, or Kantian forms as outlined by Churchman? (as an aside, there are also other forms of thought he did not analyze in his work)
I'll work through the first paragraph: "Evaluate, Iterate, and Adapt" appears to be a restatement of Piaget's Assimilation and Accommodation (en:Piaget's_theory_of_cognitive_development#Assimilation_and_Accommodation). As Piaget was a philosopher, this was something he took straight out of Hegelian thought current during his time period. How could we discuss these processes in either more neutral terms, or in ways compatible with non-Hegelian traditions?
Now for the paragraph as a whole:
Thesis: "meet the needs of Movement stakeholders and the goal of sustainability"
Antithesis: This is supported by the recommendations ‘Coordinate Across Stakeholders’, ‘Evaluate, Iterate, and Adapt’, Ensure Equity in Decision-Making’, and ‘Innovate in Free Knowledge’.
Synthesis: This recommendation proposes the idea of planning for infrastructure upscaling on a continuous basis
How would this paragraph look like if it were written by say, an engineer? A farmer? A grammaticist? A mathematician? etc. There are different ways of structuring thoughts, and if one wants to avoid talking past the bulk of your audience you need to either
A. structure your content either in the form(s) that other party uses B use some sort of analytical system (such as Churchman's) to negotiate between the different forms of thought C. structure your content, your problem solving, and your methods in a very basic way (this is often not possible) D. structure everything to be read two ways so that everyone can agree to disagree without explicitly admitting as much (this is often not possible)
A good counter-argument to this is that people often due talk past each other, and that maybe the other side should just deal with it. My response to this is that we need to avoid this sort of issue to prevent a Dilbert-like dysfunctional culture, outright schisms, alienation of large groups of people, and the resultant might-makes-right outcome of rampant communication failure.--Epiphyllumlover (talk) 02:17, 3 February 2020 (UTC)
Feedback from Hindi Community members on Plan Infrastructure Scalability recommendation
editFour users supported this recommendation. There was support on more investment in communication solutions and processes to support more inclusion of scaling the community collaboration for decision making on movement projects in a better way. It was commented that more assistance is needed for communication which should be clear and strong for supporting various community projects and initiatives. One user gave more example, global campaigns or events can be made more language and platform inclusive, especially for mobile users. Another user suggested that more resources need to be assigned to make campaigns, such as, Project Tiger and Commons contests to make them more successful. RSharma (WMF) (talk) 19:27, 16 February 2020 (UTC)
Highlights from the Spanish and Catalan/Valencian Conversations - Plan Infrastructure Scalability
editScalability is desirable. It seems more like a statement of principles. We see a kind of "mea culpa" where we believe to understand that things on a global scale (the most are WMF-related) do not work. People in specifically hard situations are upset for the lack of context when WMF asks for certain metrics, they perceive that they don't understand them.
Issues: "How" talks about things we can’t see how they relate to each other. Technology, governability, multilingualism or resource distribution have to do with. But third parties doesn’t seem to fit so much to us.
Specific teams, if it involves paying people, will cause rejection in the Catalan community.
There are parts of the “How” text that could have been the Rationale of the entire document.--FFort (WMF) (talk) 16:45, 21 February 2020 (UTC)
Feedback from the Wikimedians in Residence Exchange Network (WREN)
editGeneral Feedback
editOur group's general feedback for the entire set of recommendations can be found here.
Feedback on “Plan infrastructure scalability”
editGenerally, WREN as a group can serve as a good model for communications and professional peer networks for others. In terms of communications, do we really want boutique communications solutions or more generalized ones? (For example, Wikimedia Space is maybe not a useful solution, while Zoom access may be more generally useful and accessible.) We’re a part of an information ecosystem - we should utilize what’s available to us - not reinvent the wheel -especially when what’s available is more accessible then what’s being created.
The analysis of our infrastructures must include a complex set of criteria, such as resource distribution and legal protection for handling risk in limited geographies, investment in modern and efficient developer tooling to support community and other developer capacities, cutting-edge technologies to build content partnerships, and decisions on whether platform improvements could come from external sources or partners.
- Central pieces of existing infrastructure are socially brittle (this would never be allowed in hardware or software) and this is not really acknowledged. For example, only one person may know how to do something important related to a Wiki system. What happens if that person is not available and/or can’t maintain the tool(s)? We are specifically thinking about Magnus Manske whose tools are essential to our work.
- Additionally, Wikimedians in Residence depend on some critical pieces of software, from OpenRefine, to Quickstatements, to many other utilities. What happens to projects like GLAMwikitoolset that die slowly out of neglect? Can and should the WMF be offering better support to these useful open source projects?
- This recommendation doesn’t mention working with other organisations with the same goals e.g open education, open software etc. The language of the recommendation suggests that WMF exists in a vacuum, and does not mention key/close partners in open education, open software, open culture, etc. and how we work with them. WMF is not the largest open-source software company by miles, although Wikimedia provides an extraordinary amount of open-information. For example, in CY 2018, the Mozilla Corporation generated $435.702 million from royalties, subscriptions and advertising revenue. We are part of a greater ecosystem, with a larger infrastructure, which should be reflected here. Our infrastructure should be more closely integrated into the wider free software / free culture ecosystem.
- This is a similar problem in the same vein as the goal of being ‘the essential infrastructure,’ which seems unrealistic and uncooperative.
third-party partnerships and developers can also support and make way for working on modern technologies, as in Artificial Intelligence, Machine Learning and others, as deemed necessary
- How do we develop and manage partnerships with not-so-like-minded-institutions (for-profit), like Google, Microsoft, etc.? What are the standards and guidelines necessary to ensure ethical relationships that have integrity and benefit the Community? This must be addressed, with the Community providing feedback for standards. Perhaps some sort of community-generated agreement similar to this 2014 document would be appropriate. (It is important to note that WMF is already working with these groups even if the community doesn’t quite know it yet.)
- Any agreement should set boundaries, i.e. if xyz happens, our partnership is withdrawn. Ideally, everyone should be able to have a say (in mind). But maybe it begins with a representative from each corporation, and someone from the Wikimedia foundation or maybe a team from Wikipedia community/Wikimedia foundation.
- We would like to see more mediated discussions between stakeholders and communities, to share input on COI from WREN models
- How do we determine who to partner with, and when it is acceptable?
- How do have more direct and cooperative involvements/interactions with these companies who see our value? How can we have more connections and fewer barriers? How can we build relationships related to vetting reliability of information?
- Cultivating valuable allies is useful, and having diversity in allies is also useful - not just the Googles, not just the GLAMS, not just the Mozillas
make all processes regarding infrastructure development transparent to engage more stakeholders in them
- This seems very general in terms of recommendations, but we acknowledge that this concern may be addressed at another point in the recommendations with the formation of the Technical Committee.
“Great structural support spaces”
- What does this mean? Maybe Wikimedia Space? Concern about technical spaces that are not associated with the Wiki - the answer is not always new platforms, it is in making the existing platforms better.
Feedback from Wikimedia UK
editHow does ‘infrastructure scalability’ relate to the proposed Technology Council as well as other technology strands/clusters?
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.