User talk:Risker/Risker's checklist for content-creation extensions

Feedback from TNegrin (WMF)

First of all, great work. I'm seriously thinking about putting it on the wall at the WMF. Thank you Risker.

Some thoughts:

1. Although it sounds obvious, it would be useful to have a brief explanation of why moderation is so important to the wiki communities. Also relevant is that most Wikis with an active community have extensive workflows and culture around moderation that are considered very important to the viability of the content.
2. I'd change the phrase "minimum viable product" to something else (minimum feature set?). Minimum viable product refers to a specific product development process.
3. I feel like adding a new content type to a wiki which will add to any moderation activities should be discussed beforehand with that community. We don't want to create work without an agreed upon benefit.
4. I feel like there are additional issues around content-creation that might be addressed here: encyclopedic content, copyright (free/non-free images) as well as moderation. Should these be addressed here?

TNegrin (WMF) (talk) 14:33, 3 February 2016 (UTC)

Great stuff, Risker. I'd suggest making the part about reverting its own section; right now it feels less checklist and more advice than the part above it. Sectioning it off might help the flow.

@TNegrin (WMF): I agree with all of your points, particularly #3. As for #1, for reference is the meatball wiki's HardSecurity essay, on when moderation tools are needed because social structures aren't adequate all the time. My last note is on #4: IMO, the Foundation is theoretically making tools which allows users to better create and curate content, none of our tools should be making the content decisions. If the WMF takes this approach and makes sure to build in moderation tools, the communities can sort those things out. There is always community trouble when the WMF's software meddles directly with content. Keegan (WMF) (talk) 19:28, 3 February 2016 (UTC)

Feedback from ARipstra

Thank you Risker! It is useful to have a clear checklist of minimum requirements for any extensions, and clear reasoning about why the minimum requirements are necessary in a collaborative environment.

I think the section about "Do no harm, and be prepared to reverse implementation" could be one level higher. It is not really a minimum requirement, but an important comment on staged releases being useful for testing and solving problems as they come up before functionality is released into production. This is a topic I like to talk about a lot, and want to encourage product teams to practice more. I realize it sometimes clashes with open software development culture, but still like to urge getting major bugs and problems addressed before release to production.

On a related note, the UX team at WMF is talking about and trying to build a design hub to gather design problems, solutions, and co-design with community more pro actively. The idea is still slowly taking form, but this kind of information would be very welcome by designers. It is the kind of information designers need more of.--ARipstra (WMF) (talk) 01:22, 8 February 2016 (UTC)

Make this part of our process in developing products

I don't have much more to add in gratitude, but I will echo what my peers above have said and say this is great. Has there been any thought around introducing this as part of the WMF product development process? I personally think it would make sense in the early stages, but also at critical checkpoints we should be going, "Hey does this hit the points on the checklist?". CKoerner (WMF) (talk) 15:58, 9 February 2016 (UTC)

Good idea: phab:T126952 (now a blocker of the Concept stage, and maybe others).--Qgil-WMF (talk) 07:16, 15 February 2016 (UTC)

Thanks for all the good feedback

Thanks, Toby, Keegan, ARipstra and CKoerner (WMF) for your well-considered feedback. I've also received some additional comments off-wiki. Please feel free to point your colleagues (both WMF staff and volunteers involved in software development) in this direction; the broader the review, the better the output. I'm going to work on incorporating many of your suggestions on the weekend (Feb 13-14 or so), then I think it might be useful to copy it over to Mediawikiwiki. I'm looking for a better title, open to suggestion. Risker (talk) 04:24, 12 February 2016 (UTC)

I've been asking the WMF to make something like this for years !!! Thank you for showing the way. —TheDJ (talk • contribs) 08:54, 16 February 2016 (UTC)

Feedback from Halfak

Signed inline to help if each item gets its own discussion.

1. Re. deleting content "This is not the same thing as HIDING content, which has never been properly effective on any extension it's been used for." In mediawiki, revdeleting a username/comment/text of a revision *is* hiding the content. The content still exists in the database, but it is not shown via the user-interface. So I'm not clear what distinction is being made between "hiding" and "deleting" here. --Halfak (WMF) (talk) 20:21, 16 February 2016 (UTC)
2. It seems like splitting the advice re. good community software change practices into it's own essay. It seems that the "Do not harm" section discusses concerns that are orthogonal to to the concerns of curating new types of contributions. A software change that does not add a new contribution type can still disrupts Wikipedian activities and should probably be done iteratively as part of a participatory design process. --Halfak (WMF) (talk) 20:21, 16 February 2016 (UTC)
3. Add an intro to the history and work practices around curation of revisions/new page creations. It will help readers understand the context and concerns. It might be nice to have a story if possible. --Halfak (WMF) (talk) 20:21, 16 February 2016 (UTC)

Generally the document looks good. Do we have the equivalent of guidelines for MediaWiki development? If so, it seems like this document belongs and could be extended with example of *how* to incorporate new contributions into the recentchanges feed/watchlists/usercontribs/etc. --Halfak (WMF) (talk) 20:21, 16 February 2016 (UTC)

ContentHandler

It's worth noting that you get pretty much all of this functionality for free if you use MediaWiki's core content system, ContentHandler, instead of trying to reinvent wheels. --Tgr (WMF) (talk) 18:36, 20 February 2016 (UTC)

This is somewhat tied to the development principle/philosophy that everything is a wiki page. --MZMcBride (talk) 02:38, 7 January 2017 (UTC)

Following the checklist in JADE

Hi all (especially Risker)! I'm working on a new content-creation extension called JADE. This checklist and the thoughts around it are incredibly useful for making sure we don't mess up the curation of this new system. See the discussion of suppression we're having. I welcome your contribution to that discussion. We're still a little way out from completing the integration in MediaWiki (recentchanges/logging/etc.), but we're well into thinking about it. --Halfak (WMF) (talk) 15:53, 12 December 2017 (UTC)

More criteria

• Blocked users should not be able to submit content or take any public actions.
• Text content should hook into abuse filter.

Alsee (talk) 04:46, 19 December 2017 (UTC)

A paper about cross-context moderation concerns (Reddit to Discord)

See https://cmci.colorado.edu/idlab/assets/bibliography/pdf/kiene2019-discord-reddit-moderation.pdf

Gist is that in transitioning from one context (Reddit) to another (Discord), community moderators struggled to re-implement the necessary moderation tools. It seems like this document has a lot in common with the paper. In general, the Reddit moderators replicated the infrastructure/functionality they needed when they transitioned to Discord. There likely are some common moderation and quality control concerns between these different contexts. E.g. it seems like this list is missing some notion of a "mod log" -- a list of moderation actions that happened to a user that could be used to make decisions about blocking or other more extreme actions. --EpochFail (talk • contribs) 17:45, 11 November 2019 (UTC)