Plain forum topics can handle chat-like discussions already, with features like automatic refresh if new posts are published and being able to see if someone is typing in the same topic.
And then… there is this, which has picked my curiosity since it was announced but haven’t tried it yet.
If there is interest in testing the Discourse Chat beta plugin, enabling it is easy.
If only there was a chat extension for MediaWiki: Extension:MediaWikiChat - MediaWiki
This proposal here is perfectly compatible with the use of a chat extension on Meta-Wiki. The processes are very different, though.
If Meta-Wiki wants to have that extension installed, the promoters of the proposal must get the extension through the technical process so it can be deployed on the Wikimedia wikis. Also, they need to obtain consensus on Meta-Wiki. Related, a Chat client was requested in the last Community Wishlist survey. In the discussion one can see that opinions differ about integrating chat features in MediaWiki.
Sure, both are different, because we are talking about different places.
If the WMF, or a team withing the WMF, thinks that having a chat extension is a good idea, then they should develop it to work inside MediaWiki technology. The technical process for that is responsability of the WMF, and that’s why the WMF has a budget and workers. The money is not for using Discourse, is for making MediaWiki and Wikimedia better. If a chat makes it better, then it’s their job to do it.
Granting consensus at Meta or wherever is also WMF’s responsability. If WMF is not able to sell the virtues of a chat system to Meta then whe WMF communications team have a real problem. But even if they are not able to sell a chat system to Meta, then the WMF can use… the WMF’s own wiki, where they can decide what tools are optimal for communication without dependency on the Meta community.
Furthermore, there was a wish in the wishlist about a chat client but it was rejected WITHOUT DISCUSSION by… yes, the WMF. So the WMF is saying that a chat would be useful, is rejecting the option to develop it even if the community is asking for it, and then is complaining because they can’t develop a chat system using MediaWiki and inside the community discussion places because of the same community.
Let’s be serious, please.
I still see this as a pointless duplication of channels. It’s one thing to introduce a new tool for long-form discussions when it’s clearly superior to all our other long-form discussion tools and fixes important feature gaps, and another to introduce one more real-time chat tool which is inferior to all existing real-time chat tools (well, OK, not IRC) and doesn’t really add any kind of new capability.
Matrix is the way to go for real-time chat IMO. (And I agree MediaWiki integration should be looked at, some time in the future, but obviously that’s no small project. FWIW, (⚓ T149661 Real-time chat and ⚓ T224630 Help panel: measure demand for live chat are some past discussions about MediaWiki chat integration.)
If we need it now, and this have been around for years, then it is WMF’s responsability to assign money (we have milllions of dollars) and do it. And then present it to the community with the best entry point possible.
If we just move to another platform because, well, we haven’t done our homework, then we won’t do this move ever because we are yet in another platform.
Ok, we have three opinions in this short discussion:
From the three options, here and now we only can choose between 1 and 2. @Tgr makes a very compelling point, so I will keep this discussion open a few days more just in case anyone has anything else to say and then close it.
Also, a general comment about the spirit of experimentation. The story of this chat plugin suggestion goes like this:
All this happens in 48 hours through a few comments and actions that take a few minutes to produce. Then here we discuss it here also in a few comments, zero votes, and reach a conclusion in 24 hours: no, we won’t enable this plugin for good reasons.
That’s it. It’s the beauty of experimentation and collaboration where it is ok to share new ideas, also bad ones. Wikipedia and Wikimedia were born precisely thanks to this spirit, and it is important to keep it fresh. Even more in the context of Movement Strategy where experimentation is a necessity. Even more in a community review where the point is to discuss possibilities and try out things.
Actually our only option, as WMF, is the third one. All the other options are the worst kind of procrastination: making our own products obsolete by default, while we have money and staff to solve them.
@Theklan IMHO it would be good to agree with you and move in shared direction and dynamics, but there a quite a few more things to consider…
I am not convinced there is a need to push for single and only option (almost anywhere), but rather for prefered and supported ones (however we should push for open and interoperable standards). This can easily mean we end up with two or more options across different contexts, as specific needs might create urgencies or conviniencies for using sub-optimal tools that work good and good enough *(even if just temporary).
WMF is not super precise and consistent about few things,
nor is the only point of reference in Wikimedia ecosystem
*(regardless of still centralised resources)…
IMHO there is benefit in swarm intelligence and operation
that is greater over just centralised decisions/single direction.
#3 is IMHO medium-long term option I would also support,
while some of us want to do things in next weeks…
Though this is partly true, it is not fully as actually there are other things needed than just staff and money. Also there is *(likely) enough staff and for sure enough money to accomodate execution of short-mid-long term work, so these are not one or the other *(fake binary) choices.
Hope you can accept this feedback as I value your position, just contextualizing it.
Hm…temporarily I will take the positive/good-cop hat here. IMHO:
You know this better than me so I will just point to others that Matrix still has limited adoption rates outside of techy users and its best features are around p2p and self-hosting, which is not urgent need for (to) many Wikimedians. IMHO we need to construct good use cases to be able to onboard more folx.
I think by now (from my replies Theklan and Tgr ) it is clear I would favor of
tests and time+context specific experiments+uses…
…not super clear here if option to enable plugin is only discussed for this forum in general
or it could be time+context specific experiments+uses (that do not need big concensus, but specific advocates, adopters and local-test/temporary-admins)?
@Zblace you make good points as well.
Things that we could do right now:
Can I read somewhere the plan and cost of building a chat system inside MediaWiki?
Just to clarify this: the wishlist proposal was not rejected, but marked as too big for CommTech to take on. It’s definitely still a valid idea.
As for whether it’s worth experimenting with chat here within Discourse, I’m not sure. Personally, I feel like we already have a realtime chat platform in the form of Matrix, and that efforts should be in that direction if they’re anywhere. It wouldn’t be inconceivable to embed Element within MediaWiki (that’s how Nextcloud does it, for example). But it’s a big project!
Just to clarify: the wishlist system is the worst process the WMF has to justify the lack of innovation. It creates scarcity, instead of abudance, and makes the volunteers compete between them for some crumbs, instead of colaborating on making our software the best one. Most of the wishes are never done, and those that get to be done, tend to be sub-optimal. This year it was decided that some of the wishes would be out of scope even before they could be voted and validated. So, voting for them was discouraged by design.
That said, the WMF rejected even the idea to discuss a chat system. And it did it before the voting for the wish even started. Without any technical explanation of why a feature like that is not possible.
Now, some months later, someone thinks that having a chat system would be great, but, evidently, is too late to aknowledge that the proposal was right, and that it should be done some years ago. The lack of planning, of accountability on decisions and internal processes is, again, naked in front of us.
This is a bit off topic here, but I’d say the best thing in the Community Wishlist is that it provides a reality check to community members who have somehow mentally moved onto post-scarcity economics while unfortunately the real world hasn’t. One can debate the exact amount of resources that should be spent on the Wishlist (currently I’d guesstimate it to 1-2% of the total WMF budget, IMO we could do with a couple times higher than that) but compared to the vast universe of things people want to see done, they will always be scarce, and choosing one wish will always mean having to say no on a number of other wishes. Having those wishes compete against each other in some kind of community selection process is a healthier headspace than blaming the evil WMF on not delivering everything we want immediately.
That idea is exactly what scarcity is. On the other hand, only a 25% of those voted are developed, and some of them in a sub-optimal and not practical way.
That said, the WMF is the one who is asking here for a better discusion forum. Do it. But with MediaWiki.
I actually would support this idea and this proposl as a new technical resource for wikipedia. i actually think this might be precisely what we need for certain areas of development.
this is what I have been hoping for somewhat, as well.
I would not disagree, but would really LOVE we start making calculus on what is the cost of mental energy wasted in volunteer community on campaigns and actions like this - where people (in time of pandemic and reduced focus) take time and focus to get informed, coordinate, communicate on local-regional-global scale over something and result is (super) small.