Creating a "Collection" namespace will conflict with the namespace used for extension Collection. Please avoid more confusion with this terminology...

I agree, you can't have a Collection namespace associated with any extension except Extension:Collection.

In API i call them "List". Would that be good? I don't think we should call the namespace "Gather:" as that makes no sense, and doesn't translate. In the end, I really don't care what we call the namespace - I am more concerned with functionality. Proposals are welcome.

Some wikis store lists in a separated content namespace, instead of in the main namespace. Having "List" reserved for an unrelated extension would not help in that case either. Translators will have a hard time trying to make things not to be confusing...

Also: https://www.mediawiki.org/wiki/Talk:Gather#STOP_NOW

@He7d3r - Ok, seems the List namespace is also bad. Any suggestions? How about favorites - it implies that this is a POV feature.

Looks better with regards to conflicts with existing terminology, but the whole problem will be solved better by providing watchlist grouping (T22444), so that people can have a list of topics they favorited, another for topics where they review any changes to, another one for "read later", and so on

I strongly support moving these out of the "Special" namespace because administrators need to be able to delete them. I personally can foresee these pages being easily abused, and also foresee that creators may wish to no longer keep or maintain some of these personal lists. The survey used to determine the use of the name "collection" was seriously flawed, in that it shouldn't have given the term "collection" as an option (we already have collections). It should be re-run, at least 100 responses received, and then a name can be chosen that is appropriate. And yes, it should have its own wiki page namespace.

I never really wrote my thoughts down on this but these were some of the reasons that we chose to take this path and not model collections as pages. I think these are all solvable problems but will require big architecture changes which right now I don't think we have the bandwidth to carry out, given we are still trying to assess whether our users would use a product such as Gather:

• No easy way of systematically grouping collections e.g. 'my collections', 'jon's collections' - no easy way of saying give me all sub pages within "User:Jdlrobson/MyGatherCollections" e.g. User:Jdlrobson/MyGatherCollections/1, User:Jdlrobson/MyGatherCollections/2
• No way to join items in a collection with other concepts e.g. recent changes to create a watchlist
• No easy way to filter collections e.g. show me all the collections that have the item 'San Francisco' in it, show me all the collections that have more than 2 items. Modeling this separately to pages makes this easier, since pages were not designed for this purpose.
• There is no concept of private pages, so we cannot create private collections (the books extension worked around this by using localStorage which means it doesn't work without JS and data could easily be lost)
• Collections have a single owner. Pages are owned by everyone with the correct rights. It seems we could change the rights on a page to only allow edits from the user associated with the user page but that seems anti-wiki and currently the only way to do that is via a hook which is extremely hacky.
• Collections should only be deleted under extreme circumstances. In most cases hiding a collection suffices. Deleting is extreme and could lead to users losing faith with the feature.
• Some community members have given impression they do not want changes to collections coming up in recent changes. Since collections are personal opinion they should be kept separate.
• Not atomic. It should be possible to fire off 3 edits to a collection at the same time e.g. add item 'San Francisco', add item 'New York' remove item 'London' and result in a collection where all 3 edits are honoured. With wikipages we cannot ensure this due to the storage model and the resulting edit conflicts. This was a big issue in the early version of Gather which uses json blobs as storage.

Possible benefits of modeling collections as pages on the long term:

• Might benefit from allowing users to add categories - to help editors and aid exploration.
• When we want to support collaborative list editing (which is currently not on roadmap) we would benefit from revisions for different states

Wiki page format (ContentHandler) was clearly the way to go: using standard wiki pages gives you all the essential features for free (history, recentchanges, watchlist, moderation, permissions, abuse filters, API, dumps).

However, Gather went too far in the wrong direction and can't come back now. Implementing it the right way is still possible, probably as part of Collection which was the original proposal by users.