Talk:Talk pages consultation 2019/Tools in use

Again slightly offtopic, but Stack Overflow has one of the best systems for large-scale discussions that I have seen; I'd encourage everyone to check out Meta Stackoverflow. Large-scale discussions like big RfCs are a pain point in large wikis, and Flow, while it had numerous benefits, would only have made that aspect worse. While the StackOverflow discussion model is very structured, and might not be directly relevant to a wikitext-based discussion system, I think it's worth looking at what kind of problems it faces and how it solves them.

From the POV of communities that believe in voting (i.e., not enwiki), Flow probably would have simplified some of those big RFCs. A specific voting module was planned.

It made tracking and reading through huge discussions less effective, though.

If there's a huge discussion. There are a lot of voters at votes like this one, and a few scattered comments, but there's almost no discussion on that page.

"would only have made that aspect worse" why? What is difference between StackOverflow.com?

I'm not sure what @Tgr would say, but I think that whether Flow would help or hinder depends very much on what you think Flow would have done. With the planned (but never built) voting module, it could have been very helpful for those wikis (such as the German-language Wikipedia) that use voting extensively. Consider Wikipedia:Meinungsbilder/Lemmata von Sportstätten, a vote happening now. More than 150 people have edited that page. Most of them have done nothing except add their signatures.

If, however, you expect 150 people to truly talk to each other, then nothing available on wiki really works.

A voting module is a solution in search of a problem, IMO; voting already works. I'm sure it could be made more convenient, but it is not fundamentally broken; large-scale discussions are. Sane large-scale discussion systems (StackOverflow and Reddit/HackerNews/Slashdot are the two I can think of) all involve some kind of per-comment voting and then presenting the discussion in such a way that the parts that have been judged negatively are hidden or sorted down.

The idea of hiding/voting down comments was discussed at the English Wikipedia during this consultation. It was extremely unpopular, at least among the long-time editors who cared to comment on the subject. The Reddit/HackerNews/Slashdot discussion style seemed to be considered an anti-pattern that was best suited to entertainment purposes. If memory serves, the main concerns were seeing how the conversation developed chronologically, and their experience that the most popular comment isn't necessarily the best one.

Do I need to point out the irony? :)

Do y'all think this page would be a good place to collect the different communication-related gadgets and templates contributors use on talk pages, across different projects?

...I ask in the context of seeking the best place to accumulate responses like these: Talk page templates and gadgets

Why not? If we find a better place in the future, we can always move the information there.

At the risk of being somewhat off-topic (there really should be a "tools other communities use" page but as far as I can see it does not exist yet), someone recently wrote up the discussion/moderation features of Hacker News, which IMO make an interesting read.

@TBolliger (WMF) and @SPoore (WMF) might be interested in some of those. I believe that the ability to collapse sections of very long discussions has been mentioned by a Wikipedia editor, although I can't remember where offhand.

@Whatamidoing (WMF) en:Template:Collapse_top is super helpful, yes.

Hey @Wbm1058, I mreged your latest entry into the one above it, because "structured" means something specific and technical that isn't actually present in the example you gave. If a discussion is "structured" to use that template, then you would have no choice about whether or not to use that template. A structured process for requesting a page move would be look more like a form that you filled out. Instead, what we use is a blank section with no imposed structure.

I particularly want to thank you for posting that very interesting example. I think that it's important to remember that "free-form, used freely" is often not what editors actually want. What enwiki's WP:RM is using right now is technically "free-form, used in a specific way" – ike a typist from the 1960s who always typed three blank lines between the date and the address on a business letter: there's a conventional approach, but there's nothing actually stopping her from typing a letter however she wanted to on that blank page. It would be interesting to build something that changes that fully to a structured system.

No, the format must be structured in a specific way, or my bot will not be able to interpret and process the requests to update WP:RM. I would like to be able to force editors to use that template, as it can be a pain to clean up after those editors who don't. My bot is not highly artificially intelligent so it cannot interpret any old "free form" request. It will spit out error messages when it sees requests that aren't structured the way it expects to find them.

I'm sure that the bot can't handle free-form contents, but page is still free-form. Editors can choose to use that page (or section of it) in a way that happens to be compliant with the bot's requirements, or they can choose to confuse the bot. A structured page would not leave them that choice. Special:CreateAccount is a structured page: you can fill in the blanks, or not, but you can't do whatever you want. This Flow board is a structured page: you can fill in the blanks, or not, but you can't rearrange it. Article talk pages at the English Wikipedia are not "structured". The only "structure" that exists on them is due to manual/voluntary compliance with a set of rules that people agreed to follow. That makes them "unstructured pages".

Maybe its more useful to list mailing list technologies instead of open/closed. Mailman and Google Groups are both used widely within the movement, and I guess OTRS can be called a mailing list with a bit of a stretch. Is there anything else?

Also are there other ways of email communication there are relevant? There is direct mail at least (via MediaWiki's email sender feature, or just people knowing each other's address).

I think it's useful to remind people that private mailing lists exist, as this occasionally surprises less experienced people. I've no objection to anyone adding more details (e.g., Mailman vs Google Groups, names of the biggest or most central mailing lists, links to examples, etc.).

I agree with you that OTRS should be added. Do you think it'd be better to put it with e-mail, or under ==Other==?

I'd put it with email, but either one makes sense.

For example, I would say that Wikimedia Australia primarily communicates with its members via email. But we do have a Facebook page, a twitter account and an Instagram account. AFAIK, we are not using the social media account to communicate among ourselves but to communicate with those external to our community (but since I don't read them, maybe they are trying to communicate with me as member and i just don't know it). Which do you want for the purposes of this survey? ~~~~

My intention is about communicating "among themselves", but to define "themselves" broadly – more like "within the overall Wikimedia movement" than within (or between) individual wiki communities. For example, I'd count your communication with any existing GLAM partner as "within the movement". I would probably not count communication with traditional grantmakers or prospective GLAM partners, but I'm open to being told that I'm wrong here.

Ultimately, I'd like you to Be Bold and add whatever you think might be relevant, informative, or interesting to some people. We can always talk about any specific addition later. (Also, just to be clear, it's okay to add links to public examples.)