User blog:Kjnoren/Regarding the rollout of automatically generated Q&As

Some things I reacted to in Brandon's recent staff blog regarding automatic text generation.

Preamble
First overall remark. The Q&A format here is rather similar to the old (as in pre-web) Internet staple: the FAQ. That is a proven and popular format that has fallen out of vogue, but Google has apparently found that the format is still very popular. I'm thus wholly in favour of integrating such a format into fandom.com, provided it is handled well.

Second overall remark: I think this discussion is not only about the Q&A function, or even the use of automatically generated text. It just happens to be its current focus. I think it goes into the core of the perceived relation between the company fandom.com and the wiki communities, and that is partly why it has become so heated and ongoing, eg on the Fandom Discord channels.

All quotes come from Brandon Rhea's blog.

First reaction
"Previous attempts at features that required significant manual content creation generally failed, so we decided that, to achieve the scale needed to have an impact, we would leverage Generative AI to create the initial content."

You know which feature that required significant manual content creation? The wikis themselves. Maps are also a successful example. Fandom.com is literally built on fan labour, that is volunteer manual content creation.

My thought here is thus that it's not the manual content creation that is the problem, as long as it can be made fun and felt worthwhile. Fan labour has always been about creating things in various ways, not simply about consumption. Rather than blame the entire premise on which fandom.com and wikis are built, I think it might have been better to look at what other things differed between those features which failed and those which succeeded.

Second reaction
"Our initial method, “method A,” pulled the questions from Google"

This was really interesting to me. Classical FAQs are not simply written; the questions come out of existing observations and discussions. Without that prior discussion and experience, the questions are basically made up. The FAQ becomes a document divorced from actual human experience. Wikis are not really discussion forums, which I think contributed to the FAQ falling out of favour here.

But using data mining based on extant search queries to generate questions? That's really interesting and something worth exploring.

Third reaction
"“method B,” where both the questions and the answers were generated directly from the wiki pages themselves"

I can understand that the accuracy was improved, but given my discussion on the way classical FAQs were written above, I think method B lost something here. The questions are now generated from a limited corpus; they are not generated out of collective human action or discussion. Method B will basically create another made-up document.

The questions and the answers may appear together, but they are fundamentally very different pieces of content.

Fourth reaction
"Testing and learning is ultimately part of feature development, so it’s not the worst thing in the world that this happened."

On one hand, I agree. On another hand, I disagree. From an engineering or systems development perspective, the above is true. From a psychological or community relation perspective, I think the above is not true. Or perhaps it can be put as that there are some real lessons to be learned not only on the feature itself, but also on the perceived relation between fandom.com and the collective wiki communities on the other, as well as the way this feature was introduced. I'm not sure those lessons have been learned, recognised, or even necessarily seen.

The first such lesson is that trust is essentially a finite resource. It is very slow and hard to build up, and very easy to lose. I'd argue that the most valuable resource that fandom.com has is their base of fan editors, and that requires that there is trust in fandom.com from the fan editors as a collective. Every action that might hurt or damage that trust should be taken or made very carefully.

The second is that there is an implied contract between fandom.com and the fan editors. Fandom.com gets the money and makes sure things work. The fan editors get control over the content (within the limits of the terms of use and the community creation policy, both of which are public).

The third is that this experiment, while somewhat announced at Connect and so on, was essentially made behind the backs of the editor community. Fandom.com presented what was essentially wiki content that they themselves had generated, without any prior input, quality control, notice, or even visibility to the editor communities. Even if the answers had all been correct, I'd view this as a troubling and trust-damaging development, and a deep misunderstanding of what fan labour is.

Fifth reaction
"Admins, thread moderators, content moderators, and users with rollback rights will be able to edit the questions and answers within Quick Answers on a wiki. We chose to add the option for editors with these user rights since, at least for now, we largely consider this a moderator and a content review feature."

I'd disagree on this. Not necessarily on limiting it to select editors in the short term; as a new form of content it's a good idea to start with an experienced group for live testing. But I'd view this very much as first-class content going forward, not something that is only reviewed.

Long-term, I think the goal should be to allow wikis to set their own policies on how to handle developing and writing the answers—the questions are another kettle of fish. Public editing is the norm for wiki pages with locking the exception, and I think this should apply to the answers too. Local wikis should be able to set their own policies here based on need and experience, just as they do now for individual wiki pages.

Taking a wider scope, many wikis and editor communities struggle with an attitude problem on how admins are perceived. The official policy is largely that admins are trusted users with access to certain functions, and it is a policy that I fully value and endorse. But many admins and editors perceive admins as privileged users. Limiting an entire class of important content to those with elevated rights feeds into the latter mindset.

Sixth reaction
"Users who aren’t in those user rights groups will be able to report questions and answers that they think are inaccurate."

Great! Being able to report content in various ways is something I think would be an important addition overall. (That could either be reporting specific pieces on a page or individual diffs, but that's for another discussion.) But why limit reports to specific groups? I think everyone should be able to make reports.

Seventh reaction
"Quick Answers will not be displayed for logged in users on individual article pages"

I think this is a mistake. Preferably, these Q&As will develop into valuable content for readers, not simply for Google. Logged-in users are also more likely to be engaged and thus react to poorly worded or faulty answers, be it through reports or doing changes at once. I think fandom.com should generally try to avoid tiered experiences; the more different admins see pages compared to regular editors, and the two to logged-out users, the more dissonant will their experiences be, and the more will the wiki reading experience be tailored to the admins and editors rather than the readers.

Eighth reaction
"Quick Answers editing history or version control. Text formatting, linking, or inserting any kind of media."

I think most of the above should be considered as core pieces of the wiki experience to start, or necessary for long-term wiki quality control. Inserting media is sort of an exception here, but simple text-level formatting, linking, or version control should not be viewed as add-ons.

My wish here would be that the answers would be implemented as regular wikitext pages, with a limited syntax and living in their own namespace. Thus they would leverage all the robust built-in editing and history tools built into Mediawiki that already are well-known and trusted by the editor community.

My congratulations and thanks for anyone who made it this far.