Wikipedia talk:Gather/Moderation Criteria

Comments by TheDJ

I see a lot of very innovative ideas here, but I should tell you that people won't use them. We missed some key concepts again, that seem logical from the en.wp side:

• The way editors monitor and maintain wikipedia, is mostly through recent changes feeds and new page patrol. This is also what gets fed to IRC etc for usage by the bots. On top of these 'feeds' there are a number of mostly custom tools that are used by the editors to take actions and to do messaging, mostly geared towards wikipages. So whatever you build, if it doesn't integrate with default flows like that, people are not very likely to make use of it, because it is 'yet another place the need to visit'. Now that is a problem to solve in my opinion, but let's not solve it at the same time we make Gather.
• Something that requires moderation, requires a fully operable work environment on desktop. That's where our moderation is.
• Special is not a content namespace, but Gather uses it for 'publication'. You could argue that we have many types of public lists in Special, but these all have an administrative or a non-personal context. You wouldn't share their links. Here you do. Since it's also very much 'owned', publication belongs in the user namespace, just like the books.
• Simplify before complicating: we knew people wanted multiple private watch lists, why didn't we deliver that before delivering Gather lists ? We could still have made Gather lists at the same time, but that doesn't mean we need to enable it for everyone before we delivered private watch lists ?

—TheDJ (talk • contribs) 12:31, 15 April 2015 (UTC)

Thank you for your comments, TheDJ. I'll respond to them 1 by 1:

1. we were considering putting changes in recent changes, but based on the conversation on the noticeboard and my recent conversation with Alsee on my mediawiki talkpage, we are not going to be promoting Gather moderation to administrators or editors. If you feel strongly about it, I recommend you discuss with Alsee who feels very strongly about it.
2. my team is focused on mobile web readers, but despite that we were building this out for desktop expressly for this purpose, but please see note above.
3. Regarding the url stuff, I have heard it from others now too. It honestly is something I am still confused by. I understand that within the community there is a meaning, and that is important in and of itself, but I don't think the readers of wikipedia pay any attention to url formatting practices. I know I, a fairly technical person and avid wikipedia reader, never paid attention. I think this is particularly true of readers on mobile web who do not see the url. It is hard for me to imagine the non-wikipedian who will notice there is a 'special:' before the username and think that this lends credibility or how this will impact spam. Okay, that sounds like I am trying to convince you, but I am really just trying to explain how utterly confused I am.  :)
4. my team is focused on mobile web readers, so that is the primary reason...but that being said, we are trying to figure out how we can replicate watchlist functionailty to give you what you want using collections: multiple, shareable watchlists.

Thanks again for your helpful, constructive advice. Let me know if you continue to have concerns. Jkatz (WMF) (talk) 00:51, 17 April 2015 (UTC)

Hi Jkatz. Please pay attention to TheDJ's recommendations here. They are absolutely bang on. And, although Alsee feels strongly about it, he's not your target audience. Your target audience is people who actually deal with new pages through the mechanisms that TheDJ and I have mentioned in a few places. Alsee isn't an administrator, nor is he active in recent changes or new page patrolling on this or any other Wikipedia. (He's otherwise one of tens of thousands of fine Wikipedians.) Simply put, if these pages are made available in all of the usual workflows, they'll be treated just as any other page in those workflows. They'll go through new pages patrol and recent changes patrols, they'll get tagged or deleted if appropriate, they'll get suppressed if needed, and so on. Right now, you can't put them in the workflows though, because they're in the Special:namespace, where neither editors nor administrators can go.

It is unfortunate that you were handed this assignment which is completely outside of your normal scope of responsibility (i.e., mobile), but it is necessary - not just "useful" but necessary - that any features that are built are as functional on the desktop mode as they are on the mobile mode. If you were told otherwise, then your boss did you a serious disservice. The fact that after this many years and this many problems with product development, your group still hasn't drafted the list of tasks that are required before a feature that permits user-created contribution goes live (even in beta mode) is also not your fault, but perhaps your team can take some leadership and start working on those standards now. It is very frustrating that this is at least the fourth time that I have had the same discussion with different product managers (a different one each time), and that the Product department still hasn't figured out that there should be some baseline standards. (Each time I've been told that it will be written up...has yet to happen as far as I can see.) So, while it is entirely reasonable that new features be tested on mobile Beta first before moving to desktop Beta (I do actually get that idea), that does not eliminate the need for any content-adding feature to work equally as well on desktop at its very first release. Risker (talk) 23:07, 17 April 2015 (UTC)

Hi Risker, the dilemma of mobile products is normal: Those are products directed to a different user, who may not even be using desktop at all, yet, at the end, we are working on the same platform/project making it necessary to follow the flow, otherwise we are re-creating the wheel. You are suggesting that the lists should live in User:XYZ/Collections/LMN, making it easier to integrate in the already existing workflow? In addition to unifying the same architecture when the same feature is present for desktop? So, on desktop, we would move watchlists from Special, allowing creating private lists under user space, while adding list grouping, and "make public" features? Am I getting this correct?

It might be easier to agree on maintenance model when a feature is tested on desktop first or at the same time with mobile, but in terms of making the process standard, I am not sure how far feasible this would be with every mobile feature. On another note, how would you feel about allowing anonymous users to create lists as well? Thanks for all your input so far, I hope we are not doing drastically bad and happy to (and should) work more on enhancing the process ;). --Melamrawy (WMF) (talk) 23:28, 18 April 2015 (UTC)

I'm afraid that we seem to be talking past each other. This product really has nothing to do with watchlists; the more I look into it, the more obvious this becomes. It is fundamentally related to the "Books" software, except that needed to be cleaned up, and instead of fixing the existing "mess" this product reinvented the wheel entirely and then pretended to be something else. You're trying to sell mutton dressed as lamb, I'm sorry, but that's what it comes down to.

Anything that permits user-created content has to meet certain fundamental requirements: it must be able to be deleted, it must be able to be edited, it must be able to be suppressed, and it must show up in checkuser, recent changes, and new page logs, at a minimum. This feature permits user-created content; thus, it must meet the requirements for that type of content. The rest of us have figured out that it bears no resemblance to, nor is it in any way dependent on or even similar to watchlists, and it's important that your team stop presenting it as such. Frankly, I don't care one way or the other whether watchlists are user-space features or exist in the Special:namespace (although there may be technical reasons for it to do so). However, I do care that anything users can create can in fact be dealt with as the content that it is.

In short, this software really has nothing to do with mobile; it's just been dumped onto the mobile team because of the theory that it's easier to sneak things in without the community getting upset this way. Well, perhaps there's some truth to that, and intellectually I can see that there will be some things that are important for mobile but not desktop. But this is not a feature that is inherently a mobile feature; it's a fancied-up formulation of an existing desktop feature whose code needed to be fixed up. And just because it's being presented by the mobile team doesn't mean it is exempt from basic requirements. All this content is going onto the same website, whether it's added via the mobile interface or the desktop interface. We don't have two different encyclopedias here (although there are times when I get the impression that the engineering team forgets that). It's all the same project. It still needs to meet standards. It's not meeting those standards now. If it can't meet standards, it shouldn't be running even as beta on a live site - one that is the recipient of literally thousands of cases of vandalism, personal attacks, BLP violations, and other abusive editing on a daily basis. I don't think this product will increase the volume of problem edits; however, there will be problem edits and it is critical that the editing community that is responsible for the curation of this site is able to address these problems. Risker (talk) 23:50, 18 April 2015 (UTC)

Risker Did you check the earlier conversation around watchlist wishlist? This already includes thoughts around overlap between Collections, Books and watchlists. I am afraid I can't find the answer to what I asked about in your reply: Modelling the same functionality for desktop; as in allowing desktop users to create multiple watchlists that could be labelled and made public, in this case watchlists would need to move into user space, because it is becoming a personal non-encyclopedia content? My understanding from your reply, is that even though fundamentally such a content needs to live under user space, however, you would care less about where do those new watchlists live, as long as they could be suppressed, show in recent changes, and new page logs, i.e: are able to be curated and maintained in the normal workflow? I am double triple checking to make sure I clearly understand your stand, because unlike your assumption, we don't want to sneak things, on the contrary we want to use this experiment as a test to its extended desktop functionality :-) Thanks --Melamrawy (WMF) (talk) 10:46, 19 April 2015 (UTC)

Melamrawy (WMF), I'm not particularly concerned about watchlists when discussing Gather because the two are not technically related. You're not going to use the same software to do anything with watchlists; that's become pretty obvious. No, someone's going to rewrite the software (or create a whole new extension) for watchlists. It all depends on what users are actually able to do with watchlists: if they are able to (for example) make them public and give them names or write their own descriptions of the watchlist, then yes, it should be in userspace...and would need to meet the standards for user-created content. Anything that can be seen by another person (whether by sharing an URL or by some other means) and contains any user-created information needs to meet that standard. If someone can write it, then someone else needs to be able to delete it, edit it, suppress it, and their actions need to be logged. Keep in mind that right now the creation and management of user-controlled watchlists is not a logged activity because, aside from selecting the individual pages a user wants to watch, they cannot add anything to the watchlist. They cannot give it a name. They cannot add a description. They cannot add any content at all. It requires a significant change in underlying philosophy to move to such things as shareable watchlists or publicly visible watchlists; with that change in philosophy will come changes in practice. Bottom line, though....this discussion is not about watchlists. It's about Gather, an extension that is not technically related to watchlists. Risker (talk) 14:25, 19 April 2015 (UTC)

Risker, a collection of articles that is made public and is labelled, being a book, a Gather collection, a public watchlist that is yet to come, are all the same thing in terms of maintenance/moderation, no? If we don't take Gather as a chance to agree on basics, then we will loop again in the same discussion when watchlists functionalities are added :). Again, I am trying to clearly understand your point, you earlier mentioned "Frankly, I don't care one way or the other whether watchlists are user-space features or exist in the Special:namespace (although there may be technical reasons for it to do so). However, I do care that anything users can create can in fact be dealt with as the content that it is."and "if they are able to (for example) make them public and give them names or write their own descriptions of the watchlist, then yes, it should be in userspace...and would need to meet the standards for user-created content." So I should assum that this is not a "fundamental" issue, it is all about what functionalities are allowed in each of Special and userspace (wikitext), and how each of them supports content maintenance differently.--Melamrawy (WMF) (talk) 15:45, 19 April 2015 (UTC)

The key word is "content" - which is anything that an editor can create directly and that is visible to others. All content must be able to be curated by the community - curation being a more accurate and better-understood term than "moderation". Any action related to content must be logged (user contributions, recent changes logs, checkuser logs, and so on). At the end of the day, anything that is (or potentially could be) visible to the public or to other editors (i.e., user-created content) is essentially "community property" and it needs to be able to be curated by the broader community. So it doesn't matter much what extension or name we call the software that allows such creation. What matters is that it is well understood that it belongs to the encyclopedia, not to the person who created it, and others can and will modify it or carry out other actions as appropriate to the nature of the content. It is a core premise of the working of all Wikimedia projects - that anything submitted by a user can be "mercilessly edited" - we've softened it in the current edit window, but look up at the top of the page the next time you click "edit": "Work submitted to Wikipedia can be edited, used, and redistributed—by anyone..." Other languages and projects term it differently, but this is what needs to be borne in mind whenever developing an extension where a user can submit something. Does this help you to understand? It's about content, not about extensions. It's about every keystroke submitted by a user being subject to CC-BY-SA, and about everything being able to be modified on this site. An understanding and accommodation of this fundamental principle is required whenever developing an extension. Risker (talk) 16:23, 19 April 2015 (UTC)

Sigh. I am not that alien to Wikipedia Risker ;) so building on what you have said, do you think, all actions that apply to wikitext need to be performed on a collection of articles grouped by a user? Why do I need to be able to add or remove articles from *every* collection made by someone? In some cases, I want to be the only owner of a list of articles that I created, but I am making it public, because I want to let others know that I will be maintaining or creating this and that, or that I am keeping an eye on those specific articles, and it doesn't help to have others being able to edit *as in add or remove* articles from my collection, however my entire Collection could be deleted, or forked (another editor can take it and built on it), or I could allow others to edit my collection, or in other cases, I choose to make my collection public and collaborative, because it matches another user case, such as a group together creating a list for WikiProject maintaince task, for example. Does that make any sense? you can say no, of course, but give it thought :-) I am trying to define, what exact actions that apply to this specific kind of content and consequently, its creators. On another note, if I understand you correctly, then watchlists require a re-architecture if any functionalities are to be added to those. --Melamrawy (WMF) (talk) 17:32, 19 April 2015 (UTC)

There is a potential overlap between these and watchlists, if these were only available as a private feature then in the same way as a watchlist, we would not care or know what individuals had on their watchlists. But as Risker has pointed out, if these lists are to be made public, then the community has to be able to work with them, and it really matters whether or not they are in userspace. Some of the functionality being developed could be OK if it were in userspace, I haven't yet seen anything that would belong in Mainspace. On a broader note, I get what you are trying to do, on the last couple of occasions when I have started a new article I have then posted that to Facebook, something that encouraged people to do that more might be OK. As for a community opinion on this, would you like us to start an RFC to request that we either change policy to allow this feature or alternatively petition the WMF not to deploy this on EN wiki? ϢereSpielChequers 20:03, 19 April 2015 (UTC)

I just created one, and I have to admit I'm a little mystified at the vehemence of some of the reactions to this feature. A distinction is offered above regarding collections vs. watchlists, but watchlists can be publicly shared too. I could conceivably (at the risk of WP:BEANS) put a bunch of BLPs and the article stupid on a watchlist and share the token with the world, but that isn't inspiring any calls for moderation of user watchlists (which I am absolutely not advocating for here).

I noticed that I was offered the option to create a new public collection, and now that I've created it, I can see no way to set it to private - unless I'm missing something, the only options available are "edit" and "delete". Seems like a lot of the moderation-related angst could be alleviated by simply making them private by default, and exposing that toggle to the user who created the list.

I agree with Risker's comments above that the logical namespace for these is User:Example/Collections/mylist or similar - or alternatively, their own Collections: namespace - and that ideally there would be a feed of incoming new lists integrated into recent changes. One approach might be that any list containing a tagged BLP is prioritized for review, by whatever process we settle on, since that's probably the primary concern about content. Opabinia regalis (talk) 20:36, 19 April 2015 (UTC)

WereSpielChequers We are still in beta, and it has been running for less than a month, given the discussion we have been having, I am also discussing with the team the shift from Special to userspace, so lets see how/what would change, and when, before an RFC--maybe we wouldn't need it, we should reply very shortly. On another note, I am glad you see a clear user case for it :-). Opabinia regalis, given beta, yes, making it private is yet to be deployed in this sprint, just like other missing functionalities. Thanks a lot for bringing another alternative to namespace, as mentioned, we re currently discussing this, and will be communicating updates very shortly. You never know, maybe one day WMF will listen and respond to concerns early ;) Thanks!--Melamrawy (WMF) (talk) 09:50, 20 April 2015 (UTC)

I hadn't thought of this particular loophole by which people can disclose their private watchlists, I'm not aware that many are doing this, I'm not aware of it being a problem, and I don't see it being as much of a problem as this list feature because firstly watchlists are clearly a user feature not part of the pedia - just look at the top line including two words I have bolded: "on your watchlist, not counting talk pages. Pages that have been changed since you last visited them" secondly if someone created an account such as These people are really Nazis they would likely be blocked PDQ. As for why this all matters; A large proportion of my deletions have been per {{G10}}, part of my hobby here on Wikipedia is in deleting attack pages and my perceptions of this new feature have been somewhat influenced by my first quick trawl through the lists finding a list of "Evil Corporations". I'm also jaded by several past experiences of WMF software initiatives. So whilst I appreciate that this initiative is only in Beta, my experience is that that is the stage when it is possible to get change, and both this and our policy would have to change quite a bit for the two to be compatible. That said I'm personally quite relaxed about changing the policy of NOTWEBHOST, I suspect that one of our problems is that the deletion of "Sekrit pages" and similar userspace experiments lost us a group of goodfaith contributors whose default learning style was best served by starting off experimenting in userspace. So I would probably support amending the policy to allow these lists in usesrpace. But I don't see how we can use make use of this feature without overturning that longstanding policy, hence my suggestion that we start that debate now before investing more in the software. ϢereSpielChequers 10:46, 20 April 2015 (UTC)

• Melamrawy (WMF), sorry for taking a bit to respond; I spent most of yesterday working on time-sensitive tasks elsewhere in the Wikimedia world. With respect to watchlists, their current formulation only permits selection of the pages to be watched, with some ability to filter the results by the nature of the change that is made. It cannot dictate the order that the pages appear on the watchlist (that's driven by changes to the watched page), and it does not permit any user-created contributions such as headings or descriptions of the watchlist. In addition, for performance reasons it only shows changes made in a certain period. So the example given above (watching the page stupidity plus a bunch of BLPs) really doesn't create a problem; it's just a list of article titles with links (current change, history, etc), and unless there's a recent change to any page, they won't even show up in the watchlist.

  Now, I foresee that when improvements are made to watchlists, there may well be an ability to include a description of a particular watchlist. That description would meet the description of user-created content and would need to be able to be curated as any other user-created content. (If the process of naming a supplementary watchlist is up to the user instead of system-generated, then again that is user-created content and would need to be able to be renamed, deleted or have the title suppressed.) But we're not talking about watchlists here, and I don't think it is helpful to go off on this tangent. Let's get back to this specific feature. Risker (talk) 17:19, 20 April 2015 (UTC) EDIT: I should also note that the watchlist token is useless by itself; the token has to be used in conjunction with third-party software (RSS) in order to produce any information at all, and then it would only produce an ongoing stream of recent changes to the articles on the watchlist. Because of this, its "harassment" value is pretty much non-existent. Risker (talk) 21:19, 20 April 2015 (UTC)

Hey Risker apparently we were editing at the same time :). I see your point on watchlists, but I don't think this is the exact description that was requested here. I am not going off-topic, I just think it is logical to unify the architecture and the standard for Collections, and the yet to be public watchlists, instead of modelling different solutions for similar things. It will also save us going through the same discussion again. WereSpielChequers, I see your point on policies, but even without changing any policy, we already have user maintained books which are again, a list of articles collected and labelled..and under userspace? --Melamrawy (WMF) (talk) 23:33, 20 April 2015 (UTC)

I live in fear of this, because I am fairly certain we're going to wind up with exactly the same problem with watchlists that we have now in Gather/Books. That is, two different versions of software doing pretty much the same thing. Neither Books nor Gather has anything to do with watchlists - they are a completely different concept. More importantly, there is an absence of any sign that someone, anyone, is looking at the big picture here. Watchlists are primed for an indepth, thorough review of all of their aspects, now that SUL completion is imminent and the ability to create global watchlists is a big opportunity to build a showcase of "see, WMF engineers really do get it". But no, we're not seeing any indication that there will be a reconsideration of watchlists as a whole. That would be hard, you know. Someone would have to pick apart the tangled code. Better to just build something new that sort of looks like a watchlist but can't do the things a normal watchlist can do, or incorporate the *whole* list of desired features. This is precisely how NOT to build and improve software. And every time we see it happen, our faith is shaken a little bit more. Where are the "architecture" people on this proposal? Do they think it's the greatest idea since sliced bread? Do they think this is a good investment of WMF staff time? (This isn't a hit against the individual developer, I'll add. It's become endemic in the WMF Engineering/Product culture, and it's worrisome that anyone got the go-ahead to recreate an existing feature "for mobile".) Risker (talk) 00:28, 21 April 2015 (UTC)

Melamrawy (WMF), if someone makes a "Book" with a list of their favorite bands:

WE.

DELETE.

IT.

Kthxbai. Alsee (talk) 04:27, 21 April 2015 (UTC)

That's not true, Alsee. And more particularly, I'm not sure where you are getting that idea. Risker (talk) 05:06, 21 April 2015 (UTC)

I got that idea from reading the Wikibook policy pages. Do you think "My favorite bands" would survive at MFD??? Alsee (talk) 06:18, 21 April 2015 (UTC)

More specifically Wikipedia:Proposed_deletion_(books) / Possible reasons for deletions / The book does not comply with existing policies:

All Wikipedia policies apply to books just as they do to articles. Books should be neutral, about notable topics, and should not be created to attack people, make political statements, or promote original research and original synthesis. Any book which violates these policies (or any other) can and probably will be deleted. See also Wikipedia is not a web host and more generally, What Wikipedia is not.

"My favorite bands" is not likely to be a Notable topic, unless you happen to have been elected President of the United States :) Alsee (talk) 07:31, 21 April 2015 (UTC)

Yeah, that's pretty much only ever used for test books or those that aren't actually lists of articles. There are all kinds of books whose purpose is not immediately clear. They're not hurting anything and they're not getting routinely deleted. Heck, I'm supposedly one of the biggest deletionists on Wikipedia and randomly sampling 30 currently existing books I didn't see any I'd even think about deleting. Provided there's no other significant problem, a list of articles in one's userspace will almost never be deleted; that's essentially what books are. The same would more or less hold true for something collected under Gather. Of course, there is the risk of capricious or vengeful deletion requests, but the risk is far lower if the "gather" is in userspace than if it was in a communal space like the special:namespace. I think you considerably exaggerate the likelihood of deletion. Indeed, I've not seen many requests to delete books except for one that was brought to my attention for suppression-deletion. (Which more or less proves my point about the need to be able to curate user-created content.) Risker (talk) 13:07, 21 April 2015 (UTC)

If an active editor also has various bits of stuff in their userspace then we have quite a bit of latitude. But policy changed about a year ago, and if an editor has "few or no" edits outside userspace then sooner or later things such as these lists will be deleted {{Db-u5}}. This is regardless of whether it would have otherwise survived at MFD, and rules out the whole strategy of encouraging readers to interact here by creating an account and starting to curate in userspace in the hope that after months or years we can get them to do stuff in mainspace, or indeed useful stuff elsewhere. I would like to change policy so that we welcome people who start off finding their feet in userspace, but I'm conscious that the best way to work with the community is to work with the grain and get consensus for a policy change before implementing software that would rely on such policy change. If this software was intended to be a nice little extra for existing editors to use in userspace then all we'd need to do would be to move it to userspace and change it so that our existing tools such as deletion and recent changes worked. But this is intended as a feature for readers, who would be welcome to "curate" by creating such lists even if they do nothing else, and there are admins who would summarily delete such stuff per {{Db-u5}} ϢereSpielChequers 06:59, 22 April 2015 (UTC)

I like this argument, WereSpielChequers, I can add something about the shift from reader to contributor, which doesn't always happen by default, and which we (communities and WMF) can support, by sending the right messages to the right user. If I am a person who just created an account on WP through my mobile device, and created a collection, what message would help me further engage, what further mobile features/functionalities that would encourage me to come back and do more stuff, and what community practises would encourage me to stay around a bit longer to try more stuff as I learn about them? I would say policy is one part, practices remain another main part, and it might not be something that would directly change with polices. However, I do already see the pattern you are explaining, of a user whose only contribution was one book, with maybe one article, and those don't seem to have been deleted. Maybe so far? And as already mentioned, we are already discussing the best fit for this kind of content, in terms of where should it live, how it would be treated..etc. Thanks! :-) --Melamrawy (WMF) (talk) 11:49, 23 April 2015 (UTC)

Hi Melamrawy, I spend some of my volunteer time at CAT:SPEEDY, deleting some pages and declining deletions for others. Nowadays I often see pages there such as this, so I'm pretty sure there are lots of these, quite likely thousands per annum. The editor is new today and does have one mainspace edit and a pretty good one at that, however I can't decline the deletion tag on his userpage because it is valid under policy. I'm not going to criticise those who are implementing the policy, instead I suggest that we seek consensus to change the policy. My belief is that one of our problems is that we've got so efficient we've lost the tasks that used to serve as entry levels for new editors, and we need to promote other entry level tasks to readers and new editors, I've been working on a welcome message with some exercises that are intended to do this. I'm aware that the transition from reader to editor doesn't happen by default, only a small proportion of readers ever edit, and only a tiny and declining proportion of new editors persist and become active. My instinct is to work on the latter problem rather than the former, there doesn't seem much point in persuading lots of extra people to make their first edit if that edit is likely to be rejected, better in my view to seek to increase the proportion of those who try editing who persist and become frequent editors. ϢereSpielChequers 12:24, 23 April 2015 (UTC)

MODERATION POLICY

The Gather FAQ declares "The community is responsible for creating moderation rules for the created lists". They recklessly set this live without informing us, obviously without any policy or process in place, and of course abuses are already showing up. We need to resolve this YESTERDAY.

On the developer's talk page. I practically begged the WMF Developer and the MWF Community Liaison, THREE TIMES, to work as partners in setting up a formal discussion to address this moderation issue. Nope nope, and nope. It looks like we have to clean up this mess without their participation.

The WMF's assertion that "The community is responsible for creating moderation rules for the created lists" obviously requires an RFC at Village Pump Policy. I'm thinking the direct question at RFC would be whether we want to establish a page for such a policy (and to develop it there). The followup part of the question would be something to the effect of "and if not, how should we deal with this". If the RFC passes, fine, we go to work on the policy at that page. If not then the first comment in the Oppose section could lay out a proposal to delete/hide all collections without-review (to ensure compliance with LEGAL and cover all other abuse cases), and to seek a bot-operator to automate this. Does anyone have any input on the general idea? Does anyone want to participate in drafting? Alsee (talk) 04:27, 21 April 2015 (UTC)

Alsee. A week before launching the feature on beta experiment, I put an announcement on VP and admins noticeboard, as you can see. It is not secret :-). RFC is fine, but if we are still discussing and changing things, then it might not be the right time. If you checked carefully the conversation above, you will find that the exact points of discussion: How implementation affects moderation, and how existing and similar future features should align. Happy to see your active participation in the topic Alsee. --Melamrawy (WMF) (talk) 16:54, 21 April 2015 (UTC)

Melamrawy (WMF), I apologize for the sloppy "without informing us" comment. I struck it out. I'll have to comment on anything else later - my brain is too fried from a lack of sleep. Chuckle. Alsee (talk) 17:47, 21 April 2015 (UTC)

Alsee's comment on Lila's page and a broader discussion

Not sure why, but Alsee has recreated the discussion on Lila's talk page, without adding references to the conversation here on this talk page and its input. As mentioned there and here, it will be a good opportunity to discuss, broadly, how would this kind of content be best treated?

The concept of grouping articles and labelling them already exists in books maintained by community., as well as the long requested wishlist features of watchlists which also represents the same type of content, but for a different functionality. After the discussion above, there might be no point of discussing collections separately from discussing the community requested watchlist feature, and the already existing book feature. They are all is the same kind of content that serves different user functionality. The good news is that the same code, for collections can serve for watchlists requested features, making implementation easier, if we agreed on content issues. Thanks--Melamrawy (WMF) (talk) 10:19, 1 May 2015 (UTC)

The community has been burned by a long series of WMF initiatives that have gone sour: AFT, MediaViewer, V/E, Indian Education Program and more besides. From past experience the best way to get the WMF to react is to escalate or raise this at a certain "badsite". If the WMF wants the community not to escalate things then it should try resolving concerns when they are raised on Wikipedia. Whilst I wasn't planning to escalate things for a little while longer, I won't criticise others for having less patience. ϢereSpielChequers 16:05, 1 May 2015 (UTC)

Sigh :), we are already in discussion process. Nothing major is planned to happen on the project, and we are not ignoring anyone's concern, on the contrary, I even expanded the conversation to beyond the feature and included watchlists, because it will be easier for all of us to decide on norms for similar things. Alsee, and anyone else is free to post anything anywhere. Everyone's free to speak to Lila, but I felt responsible to give headsup here, because you were also part of the conversation. On the other hand, some products/projects didn't have a fantastic history with WMF, but that doesn't mean we should continue to assume bad faith. In this specific feature, the team is aware of these sensitivities and is really trying to be proactive in communications and is happy to expand it. Try to have 30% faith in WMF this time, you never know...it might work :).--Melamrawy (WMF) (talk) 09:03, 2 May 2015 (UTC)

30%? Actually I granted 90%, which has been rapidly burned down repeating the exact same problems. Zero communication before the project is built, denying us that pain-free opportunity to point out serious problems. And once the project is announced it's a runaway train that keeps barreling forwards while >OUR TOPIC< gets ignored. The topic is zero editor time wasted reviewing Collections, zero editor time wasted on enforcement of legal or other abuses, the topic most likely amounts to scrapping Collections or setting them all private. When your response is community and WMF, decide on how to best grow it, you ignored the topic. You ignored the issues we're raising. You ignored everything we're saying.

We say we don't want a horse, we say we don't want do work shoveling manure out of our workplace. You respond "lets work together to raise MORE horses". That ignores what we said.

You say Try to have 30% faith in WMF this time, you never know...it might work, what do you suggest "work" might mean? Are you saying that maybe we can shoot the horse? Alsee (talk) 14:04, 4 May 2015 (UTC)

Jkatz made a posting near the top of the page on the 17th April, saying amongst other things that the WMF were "not going to be promoting Gather moderation to administrators or editors" and that this feature was intended for readers. Initially I read that as the Foundation was planning to hire moderators for this readership interaction rather than rely on volunteers from the editing community, though now it seems I may have misunderstood, and the plan now is to have an unmoderated public area on Wikipedia. Also I have repeatedly pointed out that people who don't edit other than a few postings in their userspace will find those postings deleted per U5. More than a fortnight has gone by since then, and this still looks like AFT mark 2, a WMF project to interact with readers that assumes the existing community will moderate those reader comments or accept an unmoderated space for vandals to post on Wikipedia. Both core assumptions place the WMF on a repeat AFT style collision course with the community. The community won't accept an unmoderated space within Wikipedia, and it does not want to divert volunteer time from improving Wikipedia to moderating reader comments. You might be able to sell a professionally moderated readership interaction project as merely being the WMF throwing money away without wasting volunteer time, not least because the WMF is responsible for that money, but the community can object to a project that would divert further volunteer time away from improving the pedia. ϢereSpielChequers 19:31, 4 May 2015 (UTC)

First of all, I really thank you for your continous replies and engagement on the matter. Please don't loose faith in the ongoing process, at the end of the day, we are all working towards a similar goal, and WMF is not supposed to break the norms or add burden on admins/editors, and we should together find ways to ensure that this is doesn't happen. Alsee we agreed earlier, that there was already communication before the feature started :), Wikitech-l hosted the very initial communication around the extension, then I posted on English WP in different venues, before enabling in beta, after there was enough information to start the conversation with. Lets retain some faith in the process, and allow me to break down some points from the discussion:

• No admin time should be spent on editing/enhancing personal collections

True. Which is why collections aren't editable at firs place.

• No admin/editor time should be spent on maintaining a personal collections

Currently, a flag button has been added to the lists. Anyone can flag a list, making deletion automatic after 3 flags. Kindly note that the feature is still a work in progress, so we can always change/edit things as we discuss.

• The community won't accept an unmoderated space within Wikipedia

But, we already have user maintained books? WereSpielChequers, Please correct me, if my logic isn't correct on this.

I've just checked that, it isn't unmoderated. Also it is in userspace, so someone could and for all I know already has deleted books by people who haven't otherwise edited. ϢereSpielChequers 14:57, 8 May 2015 (UTC)

So WereSpielChequers the problem with Gather collections is that they aren't rendered in namesapce? Because lists could still be deleted, whether directly by an admin or after user flagging. Or you are suggesting that the lists follow the same exact workflow of books? Please clarify. Thanks--Melamrawy (WMF) (talk) 21:49, 8 May 2015 (UTC)

---On another note, and related to the above, I have repeatedly raised a question that has been ignored around the fact that lists of articles collected and labelled is something that will result from implementing watchlist features how do we want to maintain this type of content, which already exists in userbooks? I am assuming all good faith that through these conversation we can find our way to make sure we are together deciding on what works better for our community and our movement. Thanks again for being active in the discussion :) --Melamrawy (WMF) (talk) 01:11, 8 May 2015 (UTC)

Melamrawy (WMF) I'll break this into chunks:

• Wikitech-l hosted the very initial communication

That's marginally more visible than a discussion in the San Fransisco lunch room. And as I said on Lila's page, the Community needs an opportunity to painlessly raise issues before coding starts.

Talking about a healthy conversation, we can also rephrase the above lines into "It would have been also nicer to include wikis in addition to mailining lists, for better visibility" :). FYI, I work remotely, and over 75% of each mobile product team are remote people. The lunch room conversation doesn't exist, however, you are kind of right, the conversation needed to happen also on Wikis, which happened on mediawiki given relevance. It didn't start on English or on languages. I re-joined the foundation in February 9, and I had this question when I joined: How does the process of involving the community start from day one even before coding? If you have ideas or lesson to learn from, or previous experiences, I am happy to listen Alsee--Melamrawy (WMF) (talk) 17:03, 9 May 2015 (UTC)

• allow me to break down some points from the discussion: No admin time should be spent on editing/enhancing personal collections

Huh? I just re-read the discussions here and at AdminNoticeboard. I couldn't find a single person confused about that. The main discussion from the Community was about editor or admin work policing Collections. Reviewing them, and cleaning up the mess when people post abusive content. We'd be happy to review a hundred thousand collections a year, and deal with legal or other violations, if the WMF sends us a paycheck. If the WMF wants to use us as a volunteer free-labor force then the WMF needs to be respectful not to assign work we don't volunteer for.

I am not sure how to exactly reply to this, because you are including tricky statements and you are speaking for others, who didn't take things the same way you describe it. In any case, when the FAQ mentioned "the community is responsible for creating moderation rules" this was out of respect to the community Alsee, not the opposite. WMF should not come with its invented models. Whatever ideas that are suggested, whether from within the community, or an enthusiast or a staff, should find its ways to blend in the system, without breaking the norms.--Melamrawy (WMF) (talk) 17:03, 9 May 2015 (UTC)

Building the encyclopedia, serious valuable content for the world, is rewarding public service in itself.

Policing the encyclopedia against crap and violations is a rewarding public service defending what we've built.

All of internal-pages work is either directed to the public pages, or in service to the editing community itself.

Perhaps editors are snobbish about content, but stuff like "My favorite bands" is frivolous junk that we're dedicated to combating. It also "belongs" to an individual. An individual who almost certainly isn't an editor. Any work related to it is a private service to that individual, to enable them to post it here. Not only do I not volunteer to serve that individual, it diverts labor from the encyclopedia.

Any reader is a target contributor. We, community or WMF, don't invest time in offering individual private services (as you describe it) that are meaningless to the movement. If a reader, managed to find their first step of engagement through creating a personalized list of something, then be it, and our role here would be to find ways to further engage them and educate them about Wikipedia and make it easy for them to try their first edit. This is on one hand, on the other hand, you keep talking about one single user case, that doesn't seem to be significant through the existing lists so far. Creating a list of articles, is a feature that comes handy with many other uses (WikiProjects maintenance stuff, a list of redlinks of missing articles, a list of articles you want to improve, etc). We can kill every idea once mentioned, there is absolutely nothing easier than that, the challenge is to ask the right questions to move things forward in a direction that best serves the movement, and asking for additions to tweak the feature to expand its use to wider user cases. Did you try creating any list out of testing? --Melamrawy (WMF) (talk) 17:03, 9 May 2015 (UTC)

• Comparison to Books

1. Collections are public-facing. Books are effectively internal-facing. Public facing content needs to be actively patrolled. Public facing content can be seen by large numbers of the general public before an editor sees it. Abusive public-facing content needs to be dealt with immediately by the first editor that spots it. For internal pages passive patrolling is generally sufficient. The first person who stumbles across the problem will almost certainly be an editor, so it gets dealt with by the first person who sees it.

You probably missed it somewhere in the above lines. Flagging mechanisms have been added to collections. Anyone can act immediately. --Melamrawy (WMF) (talk) 17:43, 9 May 2015 (UTC)

1. Collections will predominantly be created by non-editors. Books are predominately made by editors.

Thats a good point, which brings us back to what I mentioned about the reader that can find their first steps towards engagement via this feature. I, of course, am not saying, that Collections will solve all our reader engagement, and editor engagement problems, but providing users with similar basic options might not be a terrible idea.--Melamrawy (WMF) (talk) 17:43, 9 May 2015 (UTC)

1. A: Editors know what would be abusive, and know not to do it. And if an editor is abusive, we'll spot one abuse in a high-visibility place and use their User History to hunt down anything else they've done.

Agree, but we are again focusing on a single possible user case, that doesn't seem trending, and flagging mechanism offers a way for immediate action, by anyone. As a reader, if I spotted abusive content, I can take action.--Melamrawy (WMF) (talk) 17:43, 9 May 2015 (UTC)

1. B: We're willing to cut a productive editor a bit of slack, generally not demanding they justify how every little fragment is part of their work.

2. I skimmed some books, most of what I saw is either serious content or at least plausibly related to article work they may be doing. Collections are utterly useless for work here. If an editor wanted a "Collection" they would just type [[law]] [[religion]] [[science]]. That's vastly easier and infinitely more flexible than making a Gather collection.

I don't know what is the definition of "serious" content. A category is definitely different from a collection of articles. I will give you my own simple user case: I give laser technology workshops, and since collections, I can finally share this list, as a QR code, with attendees for review. It makes life easier for me and them. Any teacher would have a similar scenario. This is just one tiny real life example.--Melamrawy (WMF) (talk) 17:43, 9 May 2015 (UTC)

1. Quantity matters. Limited quantities of borderline content is manageable. Vast quantities of junk is a disruptive drain on volunteer labor.

Again, your statement is tricky, what is junk? If I made a list of "heros in animated characters" to share with kids for "your dream hero" workshop, I would be then accused of creating a junk list, compared to the earlier laser list?--Melamrawy (WMF) (talk) 17:03, 9 May 2015 (UTC)

• You asked me about handling groups-of-articles in general.

Risker nailed it on lots of important issues, earlier on this page.

Anything visible to only a single person is a non-issue. If you vandalize it or post abusive content, no one cares.

Any object that can be vandalized by another person needs a history. Any change-action needs to be recorded in the object's history to allow reversion, AND it needs to be recorded in the User History so we can track down all of a vandal's actions anywhere.

Any user-created-content that is viewable by others might be abusive. That creation-action needs to go in the User History, and the content needs to be deletable.

The creation action showing in recent changes or in user history is something that we can talk about implementing. Content needs to be deleted, nobody will argue about that, which is why we have flagging (for auto deletion) and admins can still delete lists.--Melamrawy (WMF) (talk) 17:03, 9 May 2015 (UTC)

Even after deletion, any seriously abusive content that is still visible to admins needs to be oversightable.

Yes, we are looking for ways to achieve that.--Melamrawy (WMF) (talk) 17:03, 9 May 2015 (UTC)

We have an entire infrastructure built around this stuff. Our entire universe is built out of one thing, wikipages. Article pages = talk pages = central community pages. Anything built on wikipages automatically get that entire infrastructure for free.

This is a whole new argument, that I tried to start earlier, but didn't go anywhere. With your assumption, how do we build new functionalities or expand functionalities for watchlists (Collections are not watchlists, I know), but extending watchlists functionalities would make them bound to different actions, I asked if we can think together of what possible architecture we would like to unify for both, and I don't think I got a clear answer.--Melamrawy (WMF) (talk) 17:03, 9 May 2015 (UTC)

When devs go to Special pages, they're cut free to do whatever they want. It's nice for them. But it also cuts them off from our entire infrastructure. That's a real problem when they put User-controlled-content into Special. They need to replicate all of those requirements from scratch and tie it into the existing systems. That's a lot of work, and it's really hard to get it right. Devs building in Special generally don't get around to building all of those requirements, of if they do try they never get it working quite right. Hell, Flow has MASSIVE development resources behind it and they're STILL struggling to integrate Flow into that infrastructure properly.

This argument also happened before, because it links to the previous concern. There is another question about why build a wikitext page, if you don't need all functionalities of wikitext? In any case, re-architecturing Collection, could happen, if needed, and if there is a logical justification. I am not saying that what you mentioned isn't logical enough, I am just saying this could be a broader conversation, don't get me wrong :)--Melamrawy (WMF) (talk) 17:03, 9 May 2015 (UTC)

If something can possibly be built on top of wikipages, it should be. Putting user created content in Special should be a last resort. People WILL post a child's real name and phone number and address. People WILL put that into the title of a Collection or the title of a shared-watchlist. We need to be able to deal with that.

Totally hear you. Which is why now flagging exists.--Melamrawy (WMF) (talk) 17:03, 9 May 2015 (UTC)

(edited to add more)

• Dealing with persistent problem individuals is extremely costly. Not only can it consume substantial time of multiple admins, if they keep creating new accounts to re-post abusive content we may need to impose an IP-range block. This can result in a block against an entire school, or a block against large residential ISP-neighborhood. Everyone at that IP-range is blocked from IP editing, and blocked from making a new account. It is bad enough when we do this because someone abuses essential edit functions. It would seriously suck to impose a range-block because some idiot was abusing a non-essential gather-app. Alsee (talk) 23:08, 8 May 2015 (UTC)

Well, lets avoid "non-essential" I am a bit sensitive towards making exact judgements and statements on relative issues :). You are right, this might be a concern, but the logic here is like "someone can be abusive, then we would block them, then this would have a larger circle of harm" but simply what you are describing already happens without Collections, because abusive content could be a new strange article, or a user account that includes phone number, or a user page that has abusive offensive content, or an abusive comment on a talk page. Abusive content fans are not waiting for gather to start their activity, they are already out there. I don't have any numbers of abusive content % to "real content" on Wikipedia in general, but, naturally it shouldn't be way more with Gather. Abusive content is a trend, that can manifest itself in any way, it is not waiting for specific feature to explode otherwise the nearly 500 lists created since beta, would have been mostly abusive content.--Melamrawy (WMF) (talk) 17:03, 9 May 2015 (UTC)